FEHLERBERICHT: (glaube ich?)
Was ist passiert :
Ich habe die folgenden Schritte unter Ubuntu 16.04 ausgeführt:
sudo apt-get update
sudo apt-get upgrade
sudo su
kubeadm reset
kubeadm init --token [redacted] --apiserver-advertise-address=192.168.13.1 --pod-network-cidr=10.244.0.0/16
exit
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes
Dabei erhalte ich:
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
Ich habe versucht, kubectl
, kubeadm
und kubelet
ein paar Mal zu deinstallieren (sogar mit --purge
) und egal was ich tue, es (kubeadm 1.7 ) erzeugt kein funktionierendes admin.conf
. Ich betreibe jedoch folgendes:
curl --cacert /etc/kubernetes/pki/ca.crt --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt --key /etc/kubernetes/pki/apiserver-kubelet-client.key https://192.168.13.1:6443
und bekomme:
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1beta1",
"/apis/apiregistration.k8s.io",
"/apis/apiregistration.k8s.io/v1beta1",
"/apis/apps",
"/apis/apps/v1beta1",
"/apis/authentication.k8s.io",
"/apis/authentication.k8s.io/v1",
"/apis/authentication.k8s.io/v1beta1",
"/apis/authorization.k8s.io",
"/apis/authorization.k8s.io/v1",
"/apis/authorization.k8s.io/v1beta1",
"/apis/autoscaling",
"/apis/autoscaling/v1",
"/apis/batch",
"/apis/batch/v1",
"/apis/certificates.k8s.io",
"/apis/certificates.k8s.io/v1beta1",
"/apis/extensions",
"/apis/extensions/v1beta1",
"/apis/networking.k8s.io",
"/apis/networking.k8s.io/v1",
"/apis/policy",
"/apis/policy/v1beta1",
"/apis/rbac.authorization.k8s.io",
"/apis/rbac.authorization.k8s.io/v1alpha1",
"/apis/rbac.authorization.k8s.io/v1beta1",
"/apis/settings.k8s.io",
"/apis/settings.k8s.io/v1alpha1",
"/apis/storage.k8s.io",
"/apis/storage.k8s.io/v1",
"/apis/storage.k8s.io/v1beta1",
"/healthz",
"/healthz/autoregister-completion",
"/healthz/ping",
"/healthz/poststarthook/apiservice-registration-controller",
"/healthz/poststarthook/apiservice-status-available-controller",
"/healthz/poststarthook/bootstrap-controller",
"/healthz/poststarthook/ca-registration",
"/healthz/poststarthook/extensions/third-party-resources",
"/healthz/poststarthook/generic-apiserver-start-informers",
"/healthz/poststarthook/kube-apiserver-autoregistration",
"/healthz/poststarthook/rbac/bootstrap-roles",
"/healthz/poststarthook/start-apiextensions-controllers",
"/healthz/poststarthook/start-apiextensions-informers",
"/healthz/poststarthook/start-kube-aggregator-informers",
"/healthz/poststarthook/start-kube-apiserver-informers",
"/logs",
"/metrics",
"/swagger-2.0.0.json",
"/swagger-2.0.0.pb-v1",
"/swagger-2.0.0.pb-v1.gz",
"/swagger.json",
"/swaggerapi",
"/ui",
"/ui/",
"/version"
]
}
Was Sie erwartet haben, zu passieren :
Nachdem ich den Master über kubeadm init
initialisiert hatte, erwartete ich, kubectl
zu können, um ein Netzwerk-Plugin zu installieren; da es x509
, kann ich das nicht tun.
Umgebung :
kubectl version
): 1.7uname -a
): Linux radium-control 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux@carldanley Es gibt keine fügen Sie ein Sign-Label hinzu, indem Sie:
(1) ein Zeichen erwähnen: @kubernetes/sig-<team-name>-misc
zB @kubernetes/sig-api-machinery-*
für API-Maschinen
(2) manuelle Angabe des Etiketts: /sig <label>
zB /sig scalability
für Sig/Skalierbarkeit
_Hinweis: Methode (1) löst eine Benachrichtigung an das Team aus. Die Teamliste findet ihr hier und die Labelliste hier _
/sig-Cluster-Lebenszyklus
Ich bin mir nicht sicher, ob dies hilft, aber ich hatte das gleiche und erkannte, dass ich die alte Setup-Anleitung benutzte, /etc/kubernetes/admin.conf
in ~/.kube/admin.conf
kopierte und $KUBECONFIG=$HOME/.kube/admin.conf
einstellte. Ich habe die Umgebungsvariable gelöscht und kubectl
standardmäßig wieder ~/.kube/config
.
Ich sehe dies auch mit kubeadm v1.7 - es verhindert, dass Knoten dem Cluster beitreten
Gleicher Fehler bei meiner Installation. Versuchen Sie es mit v1.6.5 und 1.6.7, es funktioniert gut.
Selbes Problem hier.
.
( kubeadm init
scheint in Ordnung zu sein)
ns2 ~ # kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.7.3
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks
[preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.03.1-ce. Max validated version: 1.12
[preflight] WARNING: no supported init system detected, skipping checking for services
[preflight] WARNING: no supported init system detected, skipping checking for services
[preflight] WARNING: no supported init system detected, skipping checking for services
[preflight] WARNING: socat not found in system path
[preflight] No supported init system detected, won't ensure kubelet is running.
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [ns2 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 ip_of_my_server]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 36.004283 seconds
[token] Using token: 62af23.9fba33a48799d425
[apiconfig] Created RBAC rules
[addons] Applied essential addon: kube-proxy
[addons] Applied essential addon: kube-dns
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run (as a regular user):
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
http://kubernetes.io/docs/admin/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join --token [some string] [ip_of_my_server]:6443
( kubeadm join
scheint auch in Ordnung zu sein)
h1 ~ # kubeadm join --token [some string] [ip_of_my_server]:6443 --skip-preflight-checks
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[preflight] Skipping pre-flight checks
[discovery] Trying to connect to API Server "192.168.0.254:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.168.0.254:6443"
[discovery] Cluster info signature and contents are valid, will use API Server "https://192.168.0.254:6443"
[discovery] Successfully established connection with API Server "192.168.0.254:6443"
[bootstrap] Detected server version: v1.7.3
[bootstrap] The server supports the Certificates API (certificates.k8s.io/v1beta1)
[csr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request
[csr] Received signed certificate from the API server, generating KubeConfig...
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
Node join complete:
* Certificate signing request sent to master and response
received.
* Kubelet informed of new secure connection details.
Run 'kubectl get nodes' on the master to see this machine join.
(aber kubectl get nodes
schlägt fehl)
byungnam2<strong i="17">@ns2</strong> ~ $ kubectl get nodes
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
Haben Sie $KUBECONFIG
das auf /etc/kubernetes/kubelet.conf
?
export KUBECONFIG=/etc/kubernetes/kubelet.conf
kubectl get nodes
@liggitt Nachdem ich $KUBECONFIG
auf /etc/kubernetes/kubelet.conf
, bekomme ich jetzt einen Timeout-Fehler.
ns2 ~ # ./kubernetes/kubernetes/server/bin/kubectl get nodes
Error from server (ServerTimeout): the server cannot complete the requested operation at this time, try again later (get nodes)
Und jetzt möchte ich wissen, woher die $KUBECONFIG
kommen, weil es in dem Handbuch, auf das ich mich beziehe, keine solche Aussage gibt.
Aus der Ausgabe des Befehls node join:
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
Beim Spielen mit kubeadm ist das gleiche Problem aufgetreten.
Nach kubeadm init
und kubeadm reset
wird die Kommunikation von Kubelet mit dem Apiserver fehlschlagen, da certificate signed by unknown authority
(in Kubelet-Logs) vorliegt. Und auch kubeadm init
Blöcke für immer.
Nachdem Sie /run/kubernetes/
manuell entfernt haben, kommen alle Dinge zurück. Vielleicht gibt es Probleme beim Bereinigen von Zertifikaten, wenn kubeadm reset
?
/area kubeadm
Ich bin auf kubeadm 1.8 und dieses Problem tritt immer noch auf.
ubuntu@ip-172-31-9-157:~$ kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
ubuntu@ip-172-31-9-157:~$
ubuntu@ip-172-31-9-157:~$
ubuntu@ip-172-31-9-157:~$ kubectl get nodes
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
ubuntu@ip-172-31-9-157:~$
ubuntu@ip-172-31-9-157:~$
ubuntu@ip-172-31-9-157:~$
Ich habe /var/run/kubernetes
manuell überprüft. Es wurde gereinigt, als ich kubeadm reset
. Nicht sicher, was das eigentliche Problem ist.
ACHTUNG: "Um Ihren Cluster zu verwenden, müssen Sie ihn ausführen (als normaler Benutzer)"
[ root@master1 ~]# kubectl Get Nodes
Verbindung zum Server nicht möglich: x509: Zertifikat von unbekannter Autorität signiert (möglicherweise wegen "crypto/rsa: Verification error" beim Versuch, das Zertifikat der Kandidaten-Autorität "kubernetes" zu überprüfen)
[ root@master1 ~]# su - regular_user
[ regular_user@master1 ~]$ mkdir -p $HOME/.kube
[ regular_user@master1 ~]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[ regular_user@master1 ~]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
[ regular_user@master1 ~]$ kubectl Get Nodes
NAME STATUS ROLLEN ALTER VERSION
master1.virti.corp NotReady-Master 6m v1.8.1
master2.virti.corp NotReady
@jeffbr13 Danke. Es klappt.
Bitte aktualisieren Sie die Dokumente mit dieser Problemumgehung
Wenn Sie kubeadm reset und dann kubeadm init erneut ausführen und jemals Folgendes als root ausgeführt haben, müssen Sie es erneut (als root) ausführen, um die neue Konfiguration zu erhalten:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Dann können Sie immer noch als Root ausführen.
Wenn Sie feststellen, dass Sie, wenn Sie jemals "sudo kubeadm reset" ausführen möchten, Ihr .kube-Verzeichnis entfernen müssen, um die zwischengespeicherten Verzeichnisse zu löschen.
Danach kannst du @petersonwsantos folgen
oh, stellen Sie sicher, dass Sie KUBECONFIG auf einen beliebigen Namen Ihrer Konfigurationsdatei setzen, z. B. in $HOME/.kube/config
Panzer Freund ints wahr.
Config wie die folgenden Zeilen, _$kubectl get node_ funktioniert:
_root:~/k8s# cat 04-config.sh
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
sudo chmod 777 $HOME/.kube/config
export KUBECONFIG=/etc/kubernetes/kubelet.conf
export KUBECONFIG=/home/ubuntu/.kube/config
kubectl bekommt Knoten
Dies liegt wahrscheinlich daran, dass Sie ein Multi-Master-Setup haben und /etc/kubernetes/pki/ca.*
auf jedem der Master generiert haben. Anstatt sie vom ersten Master zum Rest zu kopieren.
Die Lösung habe ich in der Kubernetes-Dokumentation gefunden
Während Sie der Dokumentation folgen, vergessen Sie nicht, das .kube-Verzeichnis mit diesem Befehl zu erstellen
mkdir -p $HOME/.kube
Denn wenn Sie diesen Befehl benötigen, wird das .kube-Verzeichnis verschoben
mv $HOME/.kube $HOME/.kube.bak
https://kubernetes.io/docs/setup/independent/troubleshooting-kubeadm/
Andere, die dieses Problem haben könnten, sollten versuchen, den Ordner /root/.kube an den Sicherungsspeicherort zu verschieben, falls vorhanden, und es erneut versuchen. Es ist sehr gut möglich, dass eine zwischengespeicherte Root-Version verwendet wird, die nicht mehr gültig ist, da Sie kubeadm als sudo ausführen.
Mein Problem war, dass ich benutzerdefinierte Zertifikate hatte, die ich während des KubeEdge-Leitfadens "Erste Schritte" erstellt hatte. Nicht mit SSL und Kubeedge herumspielen, hat es funktioniert.
ACHTUNG: "Um Ihren Cluster zu verwenden, müssen Sie ihn ausführen (als normaler Benutzer)"
[ root@master1 ~]# kubectl Get Nodes
Verbindung zum Server nicht möglich: x509: Zertifikat von unbekannter Autorität signiert (möglicherweise wegen "crypto/rsa: Verification error" beim Versuch, das Zertifikat der Kandidaten-Autorität "kubernetes" zu überprüfen)[ root@master1 ~]# su - regular_user
[ regular_user@master1 ~]$ mkdir -p $HOME/.kube
[ regular_user@master1 ~]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[ regular_user@master1 ~]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
Das funktioniert. Außer dass ich meine KUBECONFIG neu einstellen musste, da das geändert wurde
export KUBECONFIG=$HOME/.kube/config
[ regular_user@master1 ~]$ kubectl Get Nodes
NAME STATUS ROLLEN ALTER VERSION
master1.virti.corp NotReady-Master 6m v1.8.1
master2.virti.corp NotReady 4m v1.8.1
Haben Sie
$KUBECONFIG
das auf/etc/kubernetes/kubelet.conf
?export KUBECONFIG=/etc/kubernetes/kubelet.conf kubectl get nodes
das funktioniert bei mir, vielen dank.
export KUBECONFIG=/etc/kubernetes/kubelet.conf
kubectl bekommt Knoten
ist Arbeit von mir
ACHTUNG: "Um Ihren Cluster zu verwenden, müssen Sie ihn ausführen (als normaler Benutzer)"
[ root@master1 ~]# kubectl Get Nodes
Verbindung zum Server nicht möglich: x509: Zertifikat von unbekannter Autorität signiert (möglicherweise wegen "crypto/rsa: Verification error" beim Versuch, das Zertifikat der Kandidaten-Autorität "kubernetes" zu überprüfen)[ root@master1 ~]# su - regular_user
[ regular_user@master1 ~]$ mkdir -p $HOME/.kube
[ regular_user@master1 ~]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[ regular_user@master1 ~]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config[ regular_user@master1 ~]$ kubectl Get Nodes
NAME STATUS ROLLEN ALTER VERSION
master1.virti.corp NotReady-Master 6m v1.8.1
master2.virti.corp NotReady 4m v1.8.1
Das hat funktioniert!
Nach kubeadm init
Sie den Ordner $HOME/.kube entfernen und neu erstellen:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Hilfreichster Kommentar
Haben Sie
$KUBECONFIG
das auf/etc/kubernetes/kubelet.conf
?