Řešení potíží s Kubernetes

Tato stránka vás provede několika běžnými problémy s nastavením, sítěmi a nasazeními Kubernetes.

Spropitné

Navrhněte položku s nejčastějšími dotazy zasláním pull requestu do našeho úložiště dokumentace .

Tato stránka je rozdělená do následujících kategorií:

1. obecné dotazy
2. běžné chyby sítě
3. běžné chyby Windows
4. běžné hlavní chyby Kubernetes

Obecné dotazy

Jak poznám, že se Kubernetes ve Windows úspěšně dokončilo?

Měli byste vidět kubelet, kube-proxy a (pokud jste jako síťové řešení zvolili Flannel) procesy agenta hostitele spuštěné na vašem uzlu. Kromě toho by váš uzel Windows měl být v clusteru Kubernetes uvedený jako Připraveno.

Můžu nakonfigurovat, aby všechno běželo na pozadí?

Počínaje Kubernetes verze 1.11 lze kubelet & kube-proxy spustit jako nativní windows Services. Alternativní správce služeb, jako je nssm.exe, můžete také vždy používat ke spouštění těchto procesů (flanneld, kubelet & kube-proxy) na pozadí za vás.

Běžné chyby sítí

Nástroje pro vyrovnávání zatížení jsou nekonzistentně integrované napříč uzly clustru.

Ve Windows vytvoří kube-proxy nástroj pro vyrovnávání zatížení HNS pro každou službu Kubernetes v clusteru. V (výchozí) konfiguraci kube-proxy mohou na uzlech v clusterech obsahujících mnoho (obvykle 100+) vyrovnávačů zatížení dojít dostupné dočasné TCP porty (tj. dynamický rozsah portů, který ve výchozím nastavení pokrývá porty 49152 až 65535). Důvodem je vysoký počet portů vyhrazených na každém uzlu pro každý vyrovnávač zatížení (mimo DSR). Tento problém se může projevit prostřednictvím chyb v kube-proxy, například:

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

Uživatelé můžou tento problém identifikovat spuštěním skriptu CollectLogs.ps1 a konzultacem se soubory *portrange.txt.

CollectLogs.ps1 také simuluje logiku přidělování HNS pro testování dostupnosti alokace fondu portů v dočasném rozsahu portů TCP a v reservedports.txtnahlásí úspěch či selhání. Skript si vyhrazuje 10 rozsahů po 64 dočasných portech TCP (k emulaci chování HNS), počítá počet úspěšných rezervací a neúspěchů &, a poté uvolní přidělené rozsahy portů. Číslo úspěšnosti menší než 10 indikující vyčerpávání dostupného prostoru v efemérním fondu. Heuristický souhrn toho, kolik rezervací portů po 64 blocích je přibližně k dispozici, se také vygeneruje v reservedports.txt.

Pokud chcete tento problém vyřešit, můžete provést několik kroků:

1. Pro permanentní řešení by mělo být vyrovnávání zatížení kube-proxy nastaveno na režim DSR. Režim DSR je plně implementovaný a dostupný pouze v buildu Windows Server Insider 18945 nebo novějším.
2. Jako alternativní řešení můžou uživatelé také zvýšit výchozí konfiguraci dočasných portů systému Windows, které jsou k dispozici pomocí příkazu, jako je netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. UPOZORNĚNÍ: Přepsání výchozího dynamického rozsahu portů může mít důsledky na jiné procesy nebo služby na hostiteli, které spoléhají na dostupné TCP porty z neefemérního rozsahu, takže je třeba tento rozsah pečlivě vybrat.
3. Vylepšení škálovatelnosti pro nástroje pro vyrovnávání zatížení bez režimu DSR pomocí inteligentního sdílení fondu portů, které je součástí kumulativní aktualizace KB4551853 (a všech novějších kumulativních aktualizací).

Publikování v hostPortu nefunguje

Pokud chcete použít funkci HostPort, ujistěte se, že jsou moduly plug-in CNI verze 0.8.6 nebo novější a že konfigurační soubor CNI má nastavené možnosti portMappings:

"capabilities": {
    "portMappings":  true
}

Zobrazují se mi chyby typu "hnsCall selhal ve Win32: Na jednotce je chybná disketa".

K této chybě může dojít při provádění vlastních úprav objektů HNS nebo instalaci nové služby Windows Update, která zavádí změny v HNS, aniž by se rušily staré objekty HNS. Označuje, že objekt HNS, který byl dříve vytvořen před aktualizací, není kompatibilní s aktuálně nainstalovanou verzí HNS.

Ve Windows Serveru 2019 (a starších) můžou uživatelé odstranit objekty HNS odstraněním datového souboru HNS.data.

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

Uživatelé by měli být schopni přímo odstranit všechny nekompatibilní koncové body nebo sítě HNS:

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

Uživatelé windows Serveru verze 1903 můžou přejít do následujícího umístění registru a odstranit všechny síťové karty začínající názvem sítě (např. vxlan0 nebo cbr0):

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

Kontejnery v nasazení Flannel host-gw v Azure se nemůžou připojit k internetu.

Při nasazování Flannelu v režimu host-gw v Azure musí pakety procházet přes virtuální přepínač fyzického hostitele Azure. Uživatelé by měli programovat trasy definované uživatelem typu "virtuální zařízení" pro každou podsíť přiřazenou k uzlu. Můžete to provést prostřednictvím webu Azure Portal (viz příklad tady) nebo prostřednictvím az Azure CLI. Tady je příklad UDR s názvem "MyRoute" pomocí příkazů az pro uzel s IP 10.0.0.4 a příslušnou podsí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 

Spropitné

Pokud nasazujete Kubernetes na virtuální počítače Azure nebo IaaS od jiných poskytovatelů cloudu sami, můžete místo toho použít overlay networking.

Mé Windows pody nemohou pingovat externí prostředky.

Pody Windows dnes nemají naprogramovaná pravidla odchozích přenosů pro protokol ICMP. Podporuje se však protokol TCP/UDP. Při pokusu o předvedení připojení k prostředkům mimo cluster nahraďte ping <IP> odpovídajícími příkazy curl <IP>.

Pokud stále dochází k problémům, pravděpodobně vaše konfigurace sítě v cni.conf si zaslouží zvláštní pozornost. Tento statický soubor můžete kdykoli upravit. Konfigurace se použije u všech nově vytvořených prostředků Kubernetes.

Proč? Jedním z požadavků na síť Kubernetes (viz modelu Kubernetes) je, aby interně komunikace clusteru probíhala bez NAT. Pro splnění tohoto požadavku máme ExceptionList pro veškerou komunikaci, ve které nechceme, aby došlo k odchozímu překladu adres (NAT - Network Address Translation). To ale také znamená, že potřebujete vyloučit externí IP adresu, kterou se pokoušíte dotazovat z exceptionListu. Teprve potom bude provoz pocházející z vašich podů Windows správně SNATován, aby mohl přijímat odpovědi z vnějšího světa. V tomto ohledu by měl váš seznam ExceptionList v cni.conf vypadat takto:

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

Uzel Windows nemůže získat přístup ke službě NodePort

Místní přístup NodePort z samotného uzlu může selhat. Jedná se o známou mezeru funkcí, kterou řeší kumulativní aktualizace KB4571748 (nebo novější). Přístup NodePort bude fungovat z jiných uzlů nebo externích klientů.

Uzel Windows zastaví směrování přes NodePorts po snížení počtu podů.

Vzhledem k omezení návrhu musí být na uzlu Windows spuštěn alespoň jeden pod, aby přesměrování NodePort fungovalo.

Po nějaké době se koncové body virtuálních síťových adaptérů a HNS kontejnerů odstraňují.

K tomuto problému může dojít v případě, že parametr hostname-override není předán kube-proxy . Pokud ho chcete vyřešit, musí uživatelé předat název hostitele kube-proxy následujícím způsobem:

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

V režimu Flannel (vxlan) mají pody problémy s připojením po opětovném připojení k uzlu

Při každém opětovném připojení dříve odstraněného uzlu ke clusteru se flannelD pokusí přiřadit k uzlu novou podsíť. Uživatelé by měli odebrat staré konfigurační soubory podsítě pod ve následujících cestách:

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

Po spuštění Kubernetes se Flanneld zasekne v části Čekání na vytvoření sítě.

Tento problém by se měl vyřešit Flannel v0.12.0 (a vyššími verzemi). Pokud používáte starší verzi Flanneld, existuje známá závodní podmínka, která může nastat, kdy není nastavena IP adresa správy sítě Flannel. Alternativním řešením je jednoduše ručně spustit FlannelD.

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

Pody Windows se nedají spustit kvůli chybějícímu souboru /run/flannel/subnet.env

To znamená, že se Flannel nespustil správně. Můžete se pokusit restartovat flanneld.exe nebo můžete soubory zkopírovat ručně z /run/flannel/subnet.env na hlavním serveru Kubernetes a C:\run\flannel\subnet.env na pracovním uzlu Windows a upravit řádek FLANNEL_SUBNET na přiřazenou podsíť. Pokud byla například přiřazena podsíť uzlu 10.244.4.1/24:

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

Častěji než ne, existuje další problém, který může způsobovat tuto chybu, kterou je potřeba nejprve prošetřit. Doporučujeme, abyste flanneld.exe tento soubor vygeneroval za vás.

V mém clusteru Kubernetes, který běží na vSphere, došlo k přerušení připojení mezi pody na hostitelích.

Vzhledem k tomu, že vSphere i Flannel si vyhrazuje port 4789 (výchozí port VXLAN) pro překryvné sítě, může dojít k zachycování paketů. Pokud se vSphere používá pro překryvné sítě, měli byste ho nakonfigurovat tak, aby používal jiný port a uvolnil port 4789.

Moje koncové body/IP adresy unikají

V současné době existují 2 známé problémy, které můžou způsobit únik koncových bodů.

1. První známý problém je problém ve verzi 1.11 Kubernetes. Nepoužívejte Kubernetes verze 1.11.0 – 1.11.2.
2. Druhý známý problém, který může způsobit únik koncových bodů, je problém souběžnosti v úložišti koncových bodů. Pokud chcete získat opravu, musíte použít Docker EE 18.09 nebo vyšší.

Moje pody nejdou spustit kvůli chybám sítě: Nepodařilo se přidělit pro rozsah

To znamená, že IP adresní prostor na vašem uzlu je vyčerpaný. Pokud chcete vyčistit všechny nevracené koncové body, migrujte všechny prostředky na ovlivněné uzly & spusťte následující příkazy:

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

Můj Windows uzel nemůže získat přístup k mým službám pomocí IP adresy služby

Jedná se o známé omezení aktuální síťové vrstvy ve Windows. Pody Windows mají přístup k IP adrese služby.

Při spuštění kubeletu se nenašel žádný síťový adaptér.

Síťový zásobník Windows potřebuje virtuální adaptér, aby síť Kubernetes fungovala. Pokud následující příkazy nevrátí žádné výsledky (v prostředí pro správu), vytvoření sítě HNS – nezbytný předpoklad pro fungování Kubeletu – selhalo:

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

Často je vhodné upravit parametr InterfaceName skriptu start.ps1 v případech, kdy síťový adaptér hostitele není "Ethernet". V opačném případě se podívejte na výstup skriptu start-kubelet.ps1 a zjistěte, jestli při vytváření virtuální sítě nedošlo k chybám.

Stále dochází k problémům. Co mám dělat?

V síti nebo na hostitelích mohou existovat další omezení, která brání určitým typům komunikace mezi uzly. Zajistit:

• jste správně nakonfigurovali zvolenou síťovou topologii (l2bridge nebo overlay).
• provoz, který vypadá, že pochází z výpočetních jednotek (podů), je povolený
• Pokud nasazujete webové služby, je povolený provoz HTTP.
• Pakety z různých protokolů (tj. ICMP vs. TCP/UDP) se nezahazují

Spropitné

Další zdroje nápovědy najdete v průvodci odstraňováním potíží se sítěmi Kubernetes pro Windows , který je k dispozici zde.

Běžné chyby Windows

Pody Kubernetes uvízly ve fázi "Vytváření kontejneru"

Tento problém může mít mnoho příčin, ale jednou z nejběžnějších příčin je, že image pozastavení byla chybně nakonfigurovaná. Toto je příznak dalšího problému vysoké úrovně.

Při nasazování se kontejnery Dockeru pořád restartují.

Zkontrolujte, jestli je image pozastavení kompatibilní s vaší verzí operačního systému. Kubernetes předpokládá, že operační systém i kontejnery mají odpovídající čísla verzí operačního systému. Pokud používáte experimentální build Windows, například build Insider, budete muset odpovídajícím způsobem upravit image. Informace o obrazech najdete v úložišti Dockeru Microsoftu .

Běžné hlavní chyby Kubernetes

Ladění hlavního serveru Kubernetes spadá do tří hlavních kategorií (v pořadí podle pravděpodobnosti):

• V kontejnerech systému Kubernetes se něco nepovedlo.
• Něco není v pořádku se způsobem, jakým kubelet běží.
• Něco je v systému špatně.

Spusťte kubectl get pods -n kube-system pro zobrazení Podů vytvořených Kubernetes; to může poskytnout přehled o tom, které konkrétní z nich se chybně ukončují nebo nezačínají správně. Potom spusťte docker ps -a, abyste viděli všechny nezpracované kontejnery, které tyto pody zálohují. Nakonec spusťte docker logs [ID] na kontejnerech, u kterých je podezření, že příčinou problému je zobrazení nezpracovaného výstupu procesů.

Nejde se připojit k serveru rozhraní API v https://[address]:[port]

Častěji než ne, tato chyba značí problémy s certifikáty. Ujistěte se, že jste konfigurační soubor vygenerovali správně, že IP adresy v něm odpovídají vašemu hostiteli a že jste ho zkopírovali do adresáře, který je připojený serverem rozhraní API.

Dobrým místem k vyhledání tohoto konfiguračního souboru jsou:

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

V opačném případě se podívejte na soubor manifestu serveru rozhraní API a zkontrolujte přípojné body.