Dela via

Felsöka Kubernetes

  • Artikel

Den här sidan går igenom flera vanliga problem med Kubernetes-konfiguration, nätverk och distributioner.

Tips

Föreslå ett objekt med vanliga frågor och svar genom att höja en PR för att vår dokumentationslagringsplats.

Den här sidan är indelad i följande kategorier:

  1. Allmänna frågor
  2. Vanliga nätverksfel
  3. Vanliga Windows-fel
  4. Vanliga Kubernetes-huvudfel

Allmänna frågor

Hur vet jag att Kubernetes i Windows har slutförts?

Du bör se kubelet, kube-proxy och (om du valde Flannel som nätverkslösning) flanneld värdagentprocesser som körs på noden. Utöver detta bör din Windows-nod anges som "Klar" i kubernetes-klustret.

Kan jag konfigurera att köra allt detta i bakgrunden?

Från och med Kubernetes version 1.11 kan kubelet & kube-proxy köras som intern Windows Services-. Du kan också alltid använda alternativa tjänsthanterare som nssm.exe för att alltid köra dessa processer (flanneld, kubelet & kube-proxy) i bakgrunden åt dig.

Vanliga nätverksfel

Lastbalanserarna är inkonsekvent konfigurerade i klustrets noder.

I Windows skapar kube-proxy en HNS-lastbalanserare för varje Kubernetes-tjänst i klustret. I kube-proxykonfigurationen (standard) kan noder i kluster som innehåller många (vanligtvis 100+) lastbalanserare få slut på tillgängliga tillfälliga TCP-portar (t.ex. dynamiskt portintervall, som som standard omfattar portarna 49152 till 65535). Detta beror på det stora antalet portar som är reserverade på varje nod för varje lastbalanserare (ej DSR). Det här problemet kan visa sig genom fel i kube-proxy, till exempel:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Användare kan identifiera det här problemet genom att köra CollectLogs.ps1 skript och konsultera *portrange.txt-filerna.

CollectLogs.ps1 efterliknar även HNS:s allokeringslogik för att testa tillgänglighet för portallokering i det tillfälliga TCP-portintervallet och rapporterar framgång/misslyckande i reservedports.txt. Skriptet reserverar 10 omfång med 64 flyktiga TCP-portar (för att emulera HNS-beteende), räknar antalet lyckade reservationer och & misslyckanden, och släpper sedan de allokerade portomfången. Ett lyckat tal som är mindre än 10 anger att den tillfälliga poolen håller på att få slut på ledigt utrymme. En heuristisk sammanfattning av hur många portreservationer med 64 block som är ungefär tillgängliga genereras också i reservedports.txt.

För att lösa det här problemet kan några steg vidtas:

  1. För en permanent lösning ska kube-proxy-belastningsutjämning ställas in på DSR-läge. DSR-läget är fullständigt implementerat och tillgängligt endast på Windows Server Insider build 18945 eller senare.
  2. Som en lösning kan användarna också öka standardkonfigurationen för Windows för tillfälliga portar som är tillgängliga med hjälp av ett kommando som netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. VARNING: Att åsidosätta det dynamiska portintervallet kan få konsekvenser för andra processer/tjänster på värdenheten som förlitar sig på tillgängliga TCP-portar från det icke-tillfälliga intervallet, så detta intervall bör väljas noggrant.
  3. Det finns en skalbarhetsförbättring för lastbalanserare i icke-DSR-läge med hjälp av intelligent delning av portpooler som ingår i kumulativ uppdatering KB4551853 (och alla nyare kumulativa uppdateringar).

HostPort-publicering fungerar inte

Om du vill använda HostPort-funktionen kontrollerar du att dina CNI-plugin-program är v0.8.6 version eller senare och att CNI-konfigurationsfilen har portMappings funktioner inställda:

"capabilities": {
    "portMappings":  true
}

Jag ser fel som "hnsCall misslyckades i Win32: Fel diskett finns i enheten."

Det här felet kan inträffa när du gör anpassade ändringar av HNS-objekt eller installerar en ny Windows Update som introducerar ändringar i HNS utan att ta bort gamla HNS-objekt. Det anger att ett HNS-objekt som tidigare skapades innan en uppdatering är inkompatibelt med den HNS-version som är installerad.

På Windows Server 2019 (och tidigare) kan användare ta bort HNS-objekt genom att ta bort HNS.data-filen

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Användare bör kunna ta bort alla inkompatibla HNS-slutpunkter eller nätverk direkt:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Användare på Windows Server, version 1903, kan gå till följande registerplats och ta bort alla nätverkskort som börjar med nätverksnamnet (t.ex. vxlan0 eller cbr0):

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Containrar på min Flannel host-gw-distribution i Azure kan inte nå Internet

När du distribuerar Flannel i värd-gw-läge på Azure måste paketen gå igenom Azures fysiska värd-vSwitch. Användare bör programmera användardefinierade rutter av typen "virtuell enhet" för varje undernät som tilldelats en nod. Detta kan göras via Azure-portalen (se ett exempel här) eller via az Azure CLI. Här är ett exempel på UDR med namnet "MyRoute" med az-kommandon för en nod med IP 10.0.0.4 och respektive poddundernät 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Tips

Om du distribuerar Kubernetes på virtuella Azure- eller IaaS-datorer från andra molnleverantörer själv kan du också använda overlay networking i stället.

Mina Windows-poddar kan inte pinga externa resurser

Windows-poddar har inte utgående regler programmerade för ICMP-protokollet i dag. TCP/UDP stöds dock. När du försöker visa anslutningen till resurser utanför klustret ersätter du ping <IP> med motsvarande curl <IP> kommandon.

Om du fortfarande har problem förtjänar förmodligen din nätverkskonfiguration i cni.conf lite extra uppmärksamhet. Du kan alltid redigera den här statiska filen. Konfigurationen tillämpas på alla nyligen skapade Kubernetes-resurser.

Varför? Ett av Kubernetes-nätverkskraven (se Kubernetes-modell) är att klusterkommunikation ska ske utan NAT internt. För att uppfylla det här kravet har vi en ExceptionList- för all kommunikation där vi inte vill att utgående NAT ska ske. Men det innebär också att du måste undanta den externa IP-adress som du försöker köra frågor mot från ExceptionList. Först då kommer trafiken från dina Windows-poddar att SNAT:as korrekt så att den får svar utifrån. I det här avseendet bör din ExceptionList i cni.conf se ut så här:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Min Windows-nod kan inte komma åt en NodePort-tjänst

Lokal NodePort-åtkomst från själva noden kan misslyckas. Det här är ett känt funktionsgap som åtgärdas med kumulativ uppdatering KB4571748 (eller senare). NodePort-åtkomst fungerar från andra noder eller externa klienter.

Min Windows-nod slutar att dirigera trafik genom NodePorts när jag har skalat ned mina poddar

På grund av en designbegränsning måste det finnas minst en podd som körs på Windows-noden för att NodePort-vidarebefordran ska fungera.

Efter en tid tas virtuella nätverkskort och HNS-slutpunkter för containrar bort

Det här problemet kan orsakas när parametern hostname-override inte skickas till kube-proxy. För att lösa det måste användarna skicka värdnamnet till kube-proxy på följande sätt:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

I flanellläge (vxlan) har mina poddar anslutningsproblem när de har anslutit till noden igen

När en tidigare borttagen nod återansluts till klustret försöker flannelD tilldela noden ett nytt poddundernät. Användarna bör ta bort de gamla poddundernätskonfigurationsfilerna i följande sökvägar:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Efter att ha startat Kubernetes fastnar Flanneld i "Väntar på att nätverket ska skapas"

Det här problemet bör åtgärdas med Flannel v0.12.0 (och senare). Om du använder en äldre version av Flanneld, finns det ett känt problem med konkurrens som kan leda till att hanterings-IP-adressen för flanellnätverket inte anges. En lösning är att helt enkelt starta om FlannelD manuellt.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Mina Windows-poddar kan inte starta på grund av att /run/flannel/subnet.env saknas

Detta indikerar att Flannel inte startade korrekt. Du kan antingen försöka starta om flanneld.exe eller så kan du kopiera filerna manuellt från /run/flannel/subnet.env på Kubernetes-huvudservern för att C:\run\flannel\subnet.env på Windows-arbetsnoden och ändra raden FLANNEL_SUBNET till det tilldelade undernätet. Om nodundernätet 10.244.4.1/24 till exempel tilldelades:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Oftast finns det ett annat problem som kan orsaka det här felet som måste undersökas först. Vi rekommenderar att du låter flanneld.exe generera den här filen åt dig.

Pod till pod-anslutning mellan värdar är avbruten på mitt Kubernetes-kluster som körs på vSphere

Eftersom både vSphere och Flannel reserverar port 4789 (standard-VXLAN-port) för överläggsnätverk, kan paketen bli avlyssnade. Om vSphere används för överläggsnätverk bör det konfigureras att använda en annan port för att frigöra 4789.

Mina IP-adresser och slutpunkter läcker ut

Det finns två kända problem som kan orsaka att slutpunkter läcker.

  1. Det första kända problemet är ett problem i Kubernetes version 1.11. Undvik att använda Kubernetes version 1.11.0– 1.11.2.
  2. Det andra kända problemet som kan orsaka att slutpunkter läcker ut är ett samtidighetsproblem i hur slutpunkter lagras. För att få korrigeringen måste du använda Docker EE 18.09 eller senare.

Det går inte att starta mina poddar på grund av "nätverk: kunde inte allokera för ett visst område."

Detta anger att IP-adressutrymmet på noden är förbrukat. Om du vill rensa alla läckta slutpunktermigrerar du alla resurser på berörda noder & köra följande kommandon:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Min Windows-nod kan inte komma åt mina tjänster med hjälp av tjänstens IP-adress

Det här är en känd begränsning för den aktuella nätverksstacken i Windows. Windows poddarkan dock komma åt tjänstens IP-adress.

Det går inte att hitta något nätverkskort när Kubelet startas

Windows-nätverksstacken behöver ett virtuellt kort för att Kubernetes-nätverk ska fungera. Om följande kommandon inte returnerar några resultat (i ett administratörsgränssnitt) har HNS-nätverket – en nödvändig förutsättning för kubelet att fungera – misslyckats:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Det är ofta värt att ändra parametern InterfaceName för skriptet start.ps1, i de fall där värdens nätverkskort inte är "Ethernet". I annat fall läser du utdata från skriptet start-kubelet.ps1 för att se om det finns fel när det virtuella nätverket skapas.

Jag ser fortfarande problem. Vad ska jag göra?

Det kan finnas ytterligare begränsningar i nätverket eller på värdar som förhindrar vissa typer av kommunikation mellan noder. Se till att:

  • du har konfigurerat den valda nätverkstopologin korrekt (l2bridge eller overlay)
  • trafik som ser ut att komma från poddar tillåts
  • HTTP-trafik tillåts om du distribuerar webbtjänster
  • Paket från olika protokoll (dvs. ICMP jämfört med TCP/UDP) tas inte bort

Tips

För ytterligare självhjälpsresurser finns det också en felsökningsguide för Kubernetes-nätverk för Windows som finns här.

Vanliga Windows-fel

Mina Kubernetes-poddar har fastnat i "ContainerCreating"

Det här problemet kan ha många orsaker, men en av de vanligaste är att pausbilden var felkonfigurerad. Det här är ett högnivåsymptom för nästa problem.

När du distribuerar fortsätter Docker-containrar att startas om

Kontrollera att pausavbildningen är kompatibel med operativsystemets version. Kubernetes förutsätter att både operativsystemet och containrarna har matchande operativsystemversionsnummer. Om du använder en experimentell version av Windows, till exempel en Insider-version, måste du justera avbildningarna i enlighet med detta. Se Microsofts Docker-lagringsplats för avbildningar.

Vanliga Kubernetes-huvudfel

Felsökning av Kubernetes-mastern ingår i tre huvudkategorier (i sannolikhetsordning):

  • Något är fel med Kubernetes-systemcontainrarna.
  • Något är fel med hur kubelet fungerar.
  • Något är fel med systemet.

Kör kubectl get pods -n kube-system för att se poddarna som skapas av Kubernetes. Detta kan ge viss insikt i vilka specifika som kraschar eller inte startar korrekt. Kör sedan docker ps -a för att se alla råcontainrar som stöder dessa poddar. Kör slutligen docker logs [ID] på de containrar som misstänks orsaka problemet för att se råutdata från processerna.

Det går inte att ansluta till API-servern på https://[address]:[port]

Oftast indikerar det här felet certifikatproblem. Kontrollera att du har genererat konfigurationsfilen korrekt, att de IP-adresser som anges i den matchar med värdens, och att du har kopierat den till den katalog som monteras av API-servern.

Bra platser för att hitta den här konfigurationsfilen är:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

I annat fall går du till API-serverns manifestfil för att kontrollera monteringspunkterna.