Unable to connect to the server: tls: failed to verify certificate: x509: certificate is valid for 10.96.0.1, 192.168.1.10, not 127.0.0.1

Die Adresslisten stammen aus deinem Zertifikat und deiner kubeconfig. Bei DNS-Namen lautet die Meldung „x509: certificate is valid for kubernetes, kubernetes.default, …, not k8s.example.com“.

kubectl (client-go) — the API server address in the kubeconfig is not among the API server certificate's SANs

Was der Fehler bedeutet

Das Zertifikat des API-Servers ist vertrauenswürdig (seine Kette führt zur Cluster-CA), aber die Adresse in der Server-URL deiner kubeconfig gehört nicht zu den Namen oder IPs in seinen Subject Alternative Names. Go listet die gefundenen IP-SANs und die gesuchte Adresse auf. kubeadm stellt das Zertifikat des API-Servers für die Service-IP, die Knotenadressen und einige DNS-Namen aus; jeder andere Weg, den Server zu erreichen, braucht einen zusätzlichen SAN.

Warum der Fehler auftritt

• Zugriff über einen Load Balancer oder eine öffentliche IP

  häufig

  Ein Load Balancer, eine Floating IP oder eine NAT-Adresse vor der Control Plane, die bei kubeadm init nicht als zusätzlicher SAN übergeben wurde.

• SSH-Tunnel und Port-Forwards

  häufig

  Erreichst du den API-Server über einen Tunnel als https://127.0.0.1:6443, verlangt der Client den Namen 127.0.0.1, den das Zertifikat nicht abdeckt.

• Die IP-Adresse des Knotens hat sich geändert

  gelegentlich

  Cluster mit nur einem Knoten, die ihre Adresse per DHCP beziehen, oder VMs, die in ein anderes Netz verschoben wurden, behalten ein Zertifikat für die alte Adresse.

So behebst du den Fehler

1. 1.

   SANs des Zertifikats auflisten

   Vergleiche sie mit der Server-URL in der kubeconfig.

   # On a control-plane node: the names and addresses the API server certificate covers
   sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -ext subjectAltName

2. 2.

   Zertifikat des API-Servers mit zusätzlichen SANs neu erzeugen

   kubeadm init phase certs apiserver stellt mit --apiserver-cert-extra-sans ein neues Zertifikat aus; vorher muss das alte Paar verschoben werden, und kube-apiserver muss neu gestartet werden, um das neue zu laden.

   # kubeadm: add the missing address/name to the API server certificate
   sudo mv /etc/kubernetes/pki/apiserver.{crt,key} /root/
   sudo kubeadm init phase certs apiserver --apiserver-cert-extra-sans=203.0.113.20,k8s.example.com
   # then restart the kube-apiserver static pod (e.g. move its manifest out of /etc/kubernetes/manifests and back)

3. 3.

   Tunnel: tls-server-name setzen

   Mit tls-server-name verbindet sich kubectl zwar mit der Tunneladresse, prüft aber einen Namen, den das Zertifikat tatsächlich abdeckt – statt insecure-skip-tls-verify zu verwenden.

   # Through a tunnel or port-forward: keep verifying the name the certificate has
   kubectl config set-cluster my-cluster --server=https://127.0.0.1:6443 --tls-server-name=kubernetes

← Gesamte Signaturfehler-Datenbank durchsuchen