kubectl connection refused 6443: der API-Server antwortet nicht

TL;DR

The connection to the server …:6443 was refused heißt: auf diesem Port nimmt niemand die Verbindung an. kubectl ist nicht bis zur Authentifizierung gekommen. Pods, Deployments und Logs können Sie in diesem Zustand nicht lesen. Zuerst die URL, die kubectl wirklich benutzt:

kubectl config view --minify
kubectl cluster-info

server: muss der API-Endpunkt dieses Clusters sein, nicht localhost, außer die Control Plane liegt auf derselben Maschine. Die Pod-Weiche gilt erst, wenn kubectl wieder antwortet: Pod startet nicht.

Die vier Stellen, in dieser Reihenfolge

Falscher Kontext. kubectl config current-context zeigt, wohin die Befehle gehen. Ein alter Eintrag auf https://127.0.0.1:6443 bleibt liegen, nachdem der Cluster woanders läuft. kubectl config get-contexts und dann use-context auf den Cluster, den Sie meinen. Viele „6443 refused“ sind ein Laptop, der den lokalen kubeadm-Cluster sucht, der nicht mehr läuft.

API-Prozess ist unten. Auf einem self-managed Node mit Control Plane: der kube-apiserver ist ein statisches Pod oder ein Prozess. crictl ps oder systemctl status kubelet auf diesem Node. Das Kubelet muss laufen, damit der statische Pod neu entsteht. Ein Node, der nur Worker ist, hat keinen API-Server. Dort ist refused auf localhost erwartet.

Netz und Firewall. Der Port 6443 ist von Ihrer IP aus nicht offen. Security Group, internes VPN, oder der Endpunkt ist private und Sie sind nicht im VPC. nc -vz HOST 6443 oder curl -k https://HOST:6443/readyz von derselben Maschine wie kubectl. Timeout ist eine andere Meldung als refused. Timeout heißt: Pakete verschwinden. Refused heißt: ein Host antwortet mit RST, dort lauscht nichts, oder ein Proxy lehnt ab.

Zertifikat und Name, aber erst nach dem TCP. x509 oder certificate signed by unknown authority ist nicht refused. Die TCP-Verbindung stand. Dann kubeconfig certificate-authority-data und den Hostnamen in server: prüfen. Wer beides in einen Topf wirft, öffnet die Firewall für einen Fehler, der schon vorbei ist.

Managed Cluster

AKS, EKS und GKE haben keinen API-Server auf Ihrem Laptop und meist keinen auf den Worker-Nodes. Die URL steht im kubeconfig, das az aks get-credentials, aws eks update-kubeconfig oder gcloud container clusters get-credentials geschrieben hat. Ein neues kubeconfig nach einer Endpunkt-Änderung (privat/öffentlich) ersetzt die alte URL. Die alte Datei weiter zu benutzen produziert refused oder Timeout auf eine Adresse, die es nicht mehr gibt.

Ein gerade gestarteter Cluster braucht ein paar Minuten, bis readyz 200 liefert. Refused direkt nach dem Anlegen kann vorübergehen. Refused am nächsten Tag nicht.

Was es nicht ist

Forbidden setzt voraus, dass der API-Server geantwortet hat. ImagePull, CrashLoop und Pending auch. Solange 6443 refused bleibt, ist jede Änderung am Deployment unsichtbar, weil sie den API-Server nie erreicht.

Quellen

• kubeconfig und Zugriff auf den API-Server
• API-Server-Port