Kubernetes: x509-Zertifikatprobleme nach kubeadm init

Erstellt am 1. Juli 2017  ·  28Kommentare  ·  Quelle: kubernetes/kubernetes

FEHLERBERICHT: (glaube ich?)

Was ist passiert :

Ich habe die folgenden Schritte unter Ubuntu 16.04 ausgeführt:

  1. sudo apt-get update
  2. sudo apt-get upgrade
  3. sudo su
  4. kubeadm reset
  5. kubeadm init --token [redacted] --apiserver-advertise-address=192.168.13.1 --pod-network-cidr=10.244.0.0/16
  6. exit
  7. mkdir -p $HOME/.kube
  8. sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  9. sudo chown $(id -u):$(id -g) $HOME/.kube/config
  10. 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 :

  • Kubernetes-Version (verwenden Sie kubectl version ): 1.7
  • Betriebssystem (zB aus /etc/os-release): Ubuntu 16.04.2 LTS
  • Kernel (zB uname -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
arekubeadm sicluster-lifecycle

Hilfreichster Kommentar

Haben Sie $KUBECONFIG das auf /etc/kubernetes/kubelet.conf ?

export KUBECONFIG=/etc/kubernetes/kubelet.conf
kubectl get nodes

Alle 28 Kommentare

@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 NotReady4m v1.8.1

@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

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen