Kubelet poort 10250 fouten op Ubuntu oplossen

Wat poort 10250 is

Poort 10250 is de kubelet API, en elke foutmelding die deze poort noemt, wijst op een van twee tegengestelde problemen. Ofwel iets anders gebruikt de poort al, waardoor kubeadm init weigert te starten. Ofwel niets kan de poort bereiken, waardoor kubectl logs en kubectl exec falen bij een node die verder volledig gezond lijkt.

De kubelet is de agent die Kubernetes op elke node uitvoert. Deze start containers en rapporteert hun status terug aan het control plane. De kubelet luistert ook op TCP 10250 en biedt een HTTPS API aan die door het control plane wordt aangeroepen. De API-server opent een verbinding met die poort wanneer u kubectl logs, kubectl exec, kubectl attach of kubectl port-forward uitvoert. metrics-server haalt gegevens op via /metrics/resource op dezelfde poort, wat ervoor zorgt dat kubectl top node werkt.

Die API is geauthenticeerd. kubeadm schakelt anonieme toegang uit en wijst de kubelet naar de cluster CA (certificate authority), waardoor een verzoek zonder inloggegevens wordt beantwoord met Unauthorized in plaats van met een shell in een van uw containers. Onthoud dit detail, want het is ook de snelste manier om te controleren of de poort bereikbaar is. Als poorten in het algemeen nieuw voor u zijn, behandelt wat een poort op Linux daadwerkelijk is het model waarvan deze handleiding uitgaat.

Beide faalmodi vloeien voort uit één vereiste. Poort 10250 moet vrij zijn voordat de kubelet start, en bereikbaar zijn vanaf het control plane zodra deze actief is.

Welk van de twee problemen heeft u

Voer deze commando's uit op de betreffende node. Elk onderstaand commando voert u zelf uit op uw eigen server.

sudo ss -lntp | grep 10250
sudo systemctl status kubelet --no-pager

ss -lntp toont luisterende TCP-sockets met het bijbehorende proces. -l staat voor luisteren, -n houdt poorten numeriek, -t beperkt de uitvoer tot TCP, -p toont het eigenaar-proces. Voor die laatste vlag is root-toegang vereist; zonder deze rechten blijft de proceskolom leeg en vergaart u geen informatie.

Een regel die eindigt op users:(("kubelet",pid=1043,fd=23)) betekent dat de kubelet actief is en de poort bezet houdt. Als u verwachtte dat de poort vrij zou zijn, dan is dit uw antwoord. Als ss helemaal niets weergeeft en de control plane de node nog steeds niet kan bereiken, dan is er nog geen sprake van een firewall, aangezien er simpelweg niets op de poort luistert. Achterhaal waarom de kubelet niet draait voordat u wijzigingen aanbrengt in de regels.

systemctl status kubelet geeft de andere kant van het beeld. active (running) met een starttijd van enkele minuten geleden is normaal. Een kubelet die elke paar seconden herstart voordat u kubeadm init of kubeadm join heeft uitgevoerd, is eveneens normaal: de meegeleverde unit start bij installatie, vindt geen configuratie en sluit af. Volgens de officiële documentatie is deze crash loop verwacht gedrag terwijl de kubelet wacht op instructies van kubeadm. Als u niet bekend bent met het herstartgedrag van systemd, biedt hoe systemd service-types en restart-policies werken de achtergrondinformatie voor deze sectie.

Waarom is poort 10250 al in gebruik wanneer kubeadm init wordt uitgevoerd

kubeadm init voert preflight-checks uit voordat er gegevens naar de schijf worden geschreven. Een van deze checks probeert elke poort te binden die het control plane nodig heeft. Wanneer deze bind-actie mislukt, stopt het proces met een foutmelding die poort 10250 noemt. Dit is geen bug. Het is kubeadm dat weigert een tweede cluster te bouwen bovenop de restanten van een eerste.

In de praktijk wordt dit door vier zaken veroorzaakt:

• Een eerdere kubeadm init of kubeadm join die halverwege is mislukt. De kubelet heeft al een configuratie ontvangen, draait dus al en houdt de poort bezet.
• Een kubeadm reset die wel is gestart, maar niet is voltooid. Reset stopt de kubelet, maar schakelt de unit niet uit, waardoor de listener na een reboot weer actief wordt.
• k3s of een andere Kubernetes-distributie die op dezelfde server is geïnstalleerd. k3s bevat een ingebouwde kubelet, en deze kubelet bindt eveneens poort 10250.
• Het kubelet-pakket dat door apt is binnengehaald en door zijn eigen systemd-unit is gestart, op een systeem waar u kubeadm nog niet heeft uitgevoerd.

Stel vast welke situatie van toepassing is voordat u wijzigingen aanbrengt:

sudo ss -lntp 'sport = :10250'
systemctl list-units --type=service --state=running | grep -Ei 'kubelet|k3s|k0s'

Als de listener toebehoort aan k3s, stop dan en bepaal welk cluster u daadwerkelijk wilt gebruiken. k3s en kubeadm kunnen niet op dezelfde server draaien, omdat ze dezelfde poorten en dezelfde CNI-directory (container network interface) opeisen. Het installatieprogramma van k3s plaatst een verwijderingsscript op /usr/local/bin/k3s-uninstall.sh op een server-node, en k3s-agent-uninstall.sh op een agent-node.

Waarom het beëindigen van de kubelet de poort niet vrijgeeft

sudo pkill kubelet maakt poort 10250 voor ongeveer tien seconden vrij. De meegeleverde unit bevat een herstartbeleid, waardoor systemd een nieuwe kubelet start die de poort direct weer in gebruik neemt. U kunt dit beleid zelf inzien:

systemctl show kubelet -p Restart -p RestartSec
sudo systemctl stop kubelet
sudo ss -lntp | grep 10250

Restart=always met RestartSec=10 is de standaardconfiguratie van de unit, en dat is precies de reden waarom kill lijkt te werken en vervolgens toch niet het gewenste resultaat geeft. systemctl stop is de juiste manier om de poort vrij te maken, omdat systemd stopt met het herstarten van een unit die u expliciet heeft gestopt.

Een vrije poort is nog niet voldoende op een node die een deel van een cluster draagt. /var/lib/kubelet/config.yaml, de certificaten onder /etc/kubernetes/pki en eventuele static pod manifests in /etc/kubernetes/manifests zijn allemaal nog aanwezig. Latere preflight-controles lopen vast op deze bestanden, en het forceren van deze controles resulteert in een cluster waarvan de certificaten niet overeenkomen met de configuratie. Voer in plaats daarvan een correcte reset van de node uit.

De node op een schone manier resetten

sudo kubeadm reset -f
sudo rm -rf /etc/cni/net.d
rm -rf $HOME/.kube
sudo systemctl stop kubelet
sudo ss -lntp | grep -E '10250|6443|2379'

-f slaat de bevestigingsprompt over. Reset probeert de acties van init of join zo goed mogelijk ongedaan te maken. Het verwijdert de lokale bestanden en configuratie, verwijdert het lokale etcd-lid op een control plane-node, wist de certificaten in /etc/kubernetes/pki en verwijdert de kubelet-configuratie en manifests.

De documentatie is expliciet over wat reset achterlaat, en elk punt zorgt regelmatig voor problemen. Het wist /etc/cni/net.d niet, waardoor de oude CNI-pluginconfiguratie behouden blijft en uw nieuwe cluster deze inleest. Het wist geen iptables-, nftables- of IPVS-regels die kube-proxy op de host heeft toegepast. Het raakt $HOME/.kube niet aan, waardoor kubectl blijft communiceren met een cluster dat niet meer bestaat en certificaatfouten geeft die lijken op een nieuw probleem.

De achtergebleven pakketregels zijn het lastigste punt. Het handmatig legen van de tabellen wist ook de regels die ufw heeft geïnstalleerd, omdat ufw op Ubuntu via dezelfde backend schrijft. Dit laat de server ongefilterd totdat u sudo ufw reload uitvoert. Op een node die u toch opnieuw opbouwt, kunt u het beste herstarten na de reset. Een herstart wist de runtime-regels die kube-proxy heeft toegevoegd en kost minder tijd dan het ontwarren van een half geleegde regelset. Waarom iptables-regels en nftables-regels in elkaars output verschijnen legt uit wat er op de achtergrond gebeurt.

Het laatste ss-commando zou niets moeten weergeven. Geen listener op 10250, 6443 of 2379 betekent dat de node klaar is voor een nieuwe kubeadm init.

Waarom kubectl logs en kubectl exec een time-out geven op poort 10250

Dit is de tegenovergestelde klacht, en deze kondigt zichzelf niet aan als een poortprobleem. Het cluster komt op. Nodes zijn Ready. Pods draaien. Vervolgens faalt één commando:

Error from server: Get "https://10.0.0.12:10250/containerLogs/default/web-0/web": dial tcp 10.0.0.12:10250: i/o timeout

Lees dat bericht vanaf het einde. De API server probeerde een TCP-verbinding te openen naar de node op poort 10250 en kreeg geen antwoord. i/o timeout betekent dat de pakketten stilletjes werden gedropt, dus iets filtert ze: de host-firewall op de node, of de afzonderlijke netwerk-firewall van uw provider in het configuratiescherm. connect: connection refused op dezelfde positie betekent het tegenovergestelde. Het pakket kwam aan en er luisterde niets, dus de kubelet is down. Dat is hetzelfde paar oorzaken als beschreven in connection refused versus connection timed out, lees hier over een andere poort.

Nodes blijven Ready gedurende dit alles omdat de node-status de andere kant op reist. De kubelet maakt verbinding naar buiten met de API server op poort 6443 en verstuurt zijn eigen heartbeat, en daarvoor is niets inkomends op 10250 nodig. Een geblokkeerde 10250 resulteert dus in een cluster dat pods normaal inplant en alleen faalt bij logs, exec, port-forward en metrics.

kubectl top node die error: Metrics API not available beantwoordt is dezelfde fout gezien via metrics-server, waarvan het logbestand de node en de poort benoemt:

unable to fully scrape metrics from node worker-1: unable to fetch metrics from node worker-1: Get "https://10.0.0.12:10250/metrics/resource": dial tcp 10.0.0.12:10250: i/o timeout

Test het pad voordat u firewallregels wijzigt

Voer dit uit vanaf een control plane-node, gericht op het adres van de worker:

nc -zv 10.0.0.12 10250
curl -sk -o /dev/null -w '%{http_code}\n' https://10.0.0.12:10250/healthz

nc -z opent een verbinding, sluit deze weer en toont succeeded! wanneer de poort de verbinding accepteert. De curl-regel is de betere test, omdat deze aantoont dat de kubelet daadwerkelijk reageert in plaats van alleen te bevestigen dat een poort openstaat. Deze toont 401. Dat is het gezonde resultaat: de TLS (transport layer security) handshake is voltooid, waarna de kubelet een niet-geauthenticeerd verzoek heeft afgewezen; dit is precies het verwachte gedrag. -k slaat de certificaatcontrole over, wat acceptabel is omdat u het pad test en niet de vertrouwensketen.

Een lange pauze die eindigt in een timeout betekent dat pakketten worden geweigerd. Wanneer curl: (7) Failed to connect direct wordt geretourneerd, betekent dit dat de poort gesloten is op een bereikbare host. Test vanaf de control plane-node en niet vanaf uw laptop, aangezien de control plane de enige machine is waarvan de toegang hier relevant is.

Welke poorten een control plane en een worker elk nodig hebben

Dit zijn de inkomende poorten die upstream worden vermeld. Op een control plane-node is TCP 6443 voor de API server vereist, open voor alles wat kubectl uitvoert. TCP 2379 tot 2380 zijn voor de etcd client en peer API, gebruikt door de API server en etcd zelf. TCP 10250 is voor de kubelet API, gebruikt door de node zelf en de control plane. TCP 10259 is voor kube-scheduler en TCP 10257 voor kube-controller-manager; beide worden alleen door de node zelf gebruikt.

Op een worker-node is TCP 10250 voor de kubelet API, gebruikt door de node zelf en de control plane. TCP 10256 is voor kube-proxy, gebruikt door de node zelf en door load balancers die health checks uitvoeren. TCP en UDP 30000 tot 32767 zijn voor NodePort-services; dit is het standaardbereik en is bereikbaar voor iedereen die die services nodig heeft.

Uw CNI-plugin voegt daar bovenop eigen poorten toe die niet in deze lijst staan. Flannel en Calico in VXLAN-modus vereisen UDP 4789 tussen nodes. Calico met BGP vereist TCP 179. Raadpleeg de documentatie van uw plugin en open deze poorten tussen nodes, anders kunnen pods op verschillende nodes niet met elkaar communiceren, zelfs als alle poorten in deze sectie openstaan.

Open poort 10250 zonder deze bloot te stellen aan het internet

De kubelet API kan een proces starten binnen elke container op die node. Beschouw een open poort 10250 als root-toegang tot de node en beperk deze op basis van bronadres. Sta dit nooit toe vanaf willekeurige locaties.

sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp comment 'kubelet API'
sudo ufw allow from 10.0.0.0/24 to any port 10256 proto tcp comment 'kube-proxy'
sudo ufw status numbered

Vervang 10.0.0.0/24 door het netwerk dat uw nodes delen. ufw status numbered toont de actieve regels met een index, zodat u een onjuiste regel kunt verwijderen met sudo ufw delete <number>. De basis van ufw voor een VPS behandelt de volgorde van regels die bepaalt welke van uw invoeren daadwerkelijk van toepassing is.

Eén ufw-instelling verstoort Kubernetes op zichzelf. Pod-verkeer dat de node passeert wordt doorgestuurd en niet lokaal afgeleverd, terwijl ufw doorgestuurde pakketten standaard blokkeert. Stel DEFAULT_FORWARD_POLICY="ACCEPT" in binnen /etc/default/ufw en voer sudo ufw reload uit. Zonder deze instelling kan poort 10250 wijd openstaan terwijl verkeer tussen pods op verschillende nodes alsnog faalt.

Controleer ook de firewall van uw provider. De meeste VPS-panelen beschikken over een firewall op netwerkniveau die zich voor de server bevindt en onzichtbaar is voor ufw status. Een regel die u op de node toevoegt, heeft geen effect als het pakket de server nooit bereikt.

Wanneer de poort bereikbaar is maar het verzoek toch faalt

Sommige 10250-fouten worden direct geretourneerd in plaats van dat ze blijven hangen; dit geeft aan dat de verbinding is geslaagd en het verzoek is afgewezen. x509: certificate signed by unknown authority in het metrics-server log betekent dat de kubelet een zelfondertekend certificaat aanbiedt dat de scraper niet vertrouwt. De gebruikelijke oplossingen zijn het inschakelen van kubelet serving certificate rotation zodat de cluster-CA het certificaat ondertekent en vervolgens het goedkeuren van de certificate signing request, of het accepteren van het risico in een lab-cluster door metrics-server uit te voeren met --kubelet-insecure-tls.

Een bericht dat Forbidden bevat in combinatie met nodes/proxy of nodes/metrics duidt op een RBAC-fout (role based access control). De aanroeper heeft de kubelet bereikt, de kubelet heeft aan de API-server gevraagd of die identiteit de subresource mag gebruiken, en het antwoord was nee. Corrigeer de ClusterRole van de aanroeper. Een wijziging in de firewall helpt hier niet, omdat er niets werd geblokkeerd.

Als u slechts één klein cluster wilt

Als u deze foutmeldingen krijgt terwijl u voor de eerste keer kubeadm op een enkele VPS opzet, overweeg dan of u kubeadm überhaupt nodig heeft. Een single-node k3s-cluster op een VPS levert u met één commando een werkende Kubernetes API op, waarbij de kubelet, kube-proxy en een CNI al zijn geconfigureerd. Poort 10250 bestaat daar nog steeds en dezelfde regels zijn daarop van toepassing, maar u hoeft het control plane niet langer zelf samen te stellen.

FAQ

Waar wordt poort 10250 voor gebruikt in Kubernetes?

Dit is de geauthenticeerde HTTPS API van de kubelet op elke node, zowel in het control plane als op worker-nodes. De API-server maakt verbinding met deze poort voor kubectl logs, kubectl exec, kubectl attach en kubectl port-forward, en de metrics-server leest /metrics/resource uit op deze poort om kubectl top te leveren. De status van een node gebruikt deze poort niet, omdat de kubelet zijn heartbeat uitgaand naar de API-server verstuurt op poort 6443. Daarom tonen nodes de status Ready wanneer poort 10250 geblokkeerd is, terwijl logs en exec-commando's falen.

Hoe vind ik welk proces luistert op poort 10250?

Voer sudo ss -lntp | grep 10250 uit op de node. Het veld users:((...)) aan het einde van de regel toont de naam van het proces en het bijbehorende PID. sudo is hierbij van belang, omdat de kolom met procesnamen leeg blijft zonder root-rechten. Als de eigenaar de kubelet is, vertelt sudo systemctl status kubelet --no-pager u of het een gezonde kubelet betreft of een kubelet die in een herstart-loop zit. Als de eigenaar k3s is, heeft u twee Kubernetes-distributies op één server geïnstalleerd en moet u er één verwijderen.

Moet ik poort 10250 openen in mijn firewall?

Ja, tussen uw nodes onderling. Het control plane moet poort 10250 op elke node kunnen bereiken, inclusief op zichzelf, anders werken logs, exec, port-forward en metrics niet. Beperk de toegang op basis van het bron-IP tot het netwerk dat uw nodes delen, bijvoorbeeld sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp. Stel deze poort niet open naar het internet: iedereen die kan authenticeren op deze poort, kan processen uitvoeren in elke container op de node.

Waarom falen kubectl logs voor pods op slechts één specifieke node?

Omdat de blokkade per node geldt en de API-server verbinding maakt met de specifieke node waar de pod op draait. Lees de foutmelding: deze bevat het IP-adres van de node die de API-server probeerde te bereiken. Voer vervolgens nc -zv <node-ip> 10250 uit vanaf een control plane-node. Een timeout wijst op de firewall op die node of op de netwerkfirewall van uw provider. connection refused wijst op een kubelet die daar niet draait; controleer in dat geval systemctl status kubelet op die specifieke node.