Udostępnij za pośrednictwem

Rozwiązywanie problemów z platformą Kubernetes

  • Artykuł

Na tej stronie przedstawiono kilka typowych problemów z konfiguracją, siecią i wdrożeniami platformy Kubernetes.

Napiwek

Zasugeruj element często zadawanych pytań, wysyłając żądanie ściągnięcia do repozytorium dokumentacji.

Ta strona jest podzielona na następujące kategorie:

  1. Ogólne pytania
  2. typowe błędy sieci
  3. typowe błędy systemu Windows
  4. Typowe błędy Kubernetes Mastera

Pytania ogólne

Jak sprawdzić, czy Kubernetes na Windows działa poprawnie?

Powinieneś zobaczyć procesy kubelet, kube-proxy i (jeśli wybrano Flannel jako rozwiązanie sieciowe) procesy agenta hosta flanneld uruchomione w węźle. Oprócz tego węzeł systemu Windows powinien być wymieniony jako "Gotowy" w klastrze Kubernetes.

Czy mogę skonfigurować uruchamianie wszystkich tych elementów w tle?

Począwszy od Kubernetes w wersji 1.11, kubelet & kube-proxy może być uruchamiana jako natywna usługi systemu Windows. Możesz również używać alternatywnych menedżerów usług, takich jak nssm.exe, aby stale uruchamiać te procesy (flanneld, kubelet & kube-proxy) w tle.

Typowe błędy sieci

Moduły równoważenia obciążenia są niespójnie rozmieszczone na węzłach klastra.

W systemie Windows serwer kube-proxy tworzy moduł równoważenia obciążenia HNS dla każdej usługi Kubernetes w klastrze. W domyślnej konfiguracji kube-proxy, węzły w klastrach zawierających wiele (zwykle 100+) równoważników obciążenia mogą napotkać brak dostępnych efemerycznych portów TCP (czyli zakres portów dynamicznych, który domyślnie obejmuje porty od 49152 do 65535). Jest to spowodowane dużą liczbą portów zarezerwowanych w każdym węźle dla każdego modułu równoważenia obciążenia (innego niż DSR). Ten problem może manifestować się za pośrednictwem błędów w serwerze kube-proxy, takich jak:

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

Użytkownicy mogą zidentyfikować ten problem, uruchamiając skrypt CollectLogs.ps1 i konsultując się z plikami *portrange.txt.

CollectLogs.ps1 będzie również naśladować logikę alokacji HNS, aby przetestować dostępność alokacji puli portów w efemerycznym zakresie portów TCP i zgłosić powodzenie/niepowodzenie w reservedports.txt. Skrypt rezerwuje 10 zakresów 64 portów efemerycznych TCP (w celu emulowania zachowania HNS), zlicza sukcesy rezerwacji & błędów, a następnie zwalnia przydzielone zakresy portów. Liczba sukcesów mniejsza niż 10 wskazuje, że w puli efemerycznej kończy się wolne miejsce. Również zostanie wygenerowane heurystyczne podsumowanie liczby dostępnych rezerwacji portów w blokach po 64 w reservedports.txt.

Aby rozwiązać ten problem, można wykonać kilka kroków:

  1. W przypadku stałego rozwiązania równoważenie obciążenia serwera kube-proxy powinno być ustawione na tryb DSR. Tryb DSR jest w pełni zaimplementowany i dostępny tylko w kompilacji Windows Server Insider w wersji 18945 lub nowszej.
  2. Aby obejść ten problem, użytkownicy mogą również zwiększyć domyślną konfigurację portów efemerycznych systemu Windows dostępnych przy użyciu polecenia takiego jak netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. OSTRZEŻENIE: Zastąpienie domyślnego zakresu portów dynamicznych może mieć konsekwencje dla innych procesów/usług na hoście, który opiera się na dostępnych portach TCP z zakresu nie efemerycznego, dlatego ten zakres należy starannie wybrać.
  3. Istnieje rozszerzenie skalowalności modułów równoważenia obciążenia w trybie innym niż DSR przy użyciu inteligentnego udostępniania puli portów zawartego w aktualizacji zbiorczej KB4551853 (i wszystkich nowszych aktualizacji zbiorczych).

Publikowanie HostPort nie działa

Aby użyć funkcji HostPort, upewnij się, że wtyczki CNI są w wersji 0.8.6 lub nowszej oraz że plik konfiguracji CNI ma ustawione portMappings funkcje:

"capabilities": {
    "portMappings":  true
}

Widzę błędy, takie jak "hnsCall nie powiodło się w Win32: Niewłaściwa dyskietka znajduje się na dysku."

Ten błąd może wystąpić podczas wprowadzania niestandardowych modyfikacji obiektów HNS lub instalowania nowej usługi Windows Update, która wprowadza zmiany w usłudze HNS bez usuwania starych obiektów HNS. Wskazuje, że obiekt HNS, który został wcześniej utworzony przed aktualizacją, jest niezgodny z aktualnie zainstalowaną wersją HNS.

W systemie Windows Server 2019 (i starszych wersjach) użytkownicy mogą usuwać obiekty HNS, usuwając plik HNS.data

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

Użytkownicy powinni mieć możliwość bezpośredniego usunięcia wszelkich niezgodnych punktów końcowych lub sieci HNS:

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

Użytkownicy systemu Windows Server w wersji 1903 mogą przejść do następującej lokalizacji rejestru i usunąć wszystkie karty sieciowe rozpoczynające się od nazwy sieciowej (np. vxlan0 lub cbr0):

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

Kontenery na moim wdrożeniu host-gw platformy Flannel na platformie Azure nie mogą uzyskać dostępu do Internetu

Podczas wdrażania platformy Flannel w trybie host-gw na platformie Azure pakiety muszą przechodzić przez przełącznik wirtualny hosta fizycznego platformy Azure. Użytkownicy powinni programować tras zdefiniowanych przez użytkownika typu "urządzenie wirtualne" dla każdej podsieci przypisanej do węzła. Można to zrobić za pośrednictwem witryny Azure Portal (zobacz przykład tutaj) lub za pośrednictwem interfejsu wiersza polecenia platformy Azure az. Oto jeden przykład trasy zdefiniowanej przez użytkownika (UDR) o nazwie "MyRoute" przy użyciu polecenia az dla węzła z adresem IP 10.0.0.4 i odpowiednią podsiecią 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 

Napiwek

Jeśli samodzielnie wdrażasz platformę Kubernetes na platformie Azure lub maszyny wirtualne IaaS od innych dostawców usług w chmurze, możesz również użyć overlay networking.

Moje pody Windows nie mogą pingować zasobów zewnętrznych

Zasobniki systemu Windows nie mają obecnie zaprogramowanych reguł ruchu wychodzącego dla protokołu ICMP. Obsługiwany jest jednak protokół TCP/UDP. Podczas próby zademonstrowania łączności z zasobami spoza klastra zastąp ping <IP> odpowiednimi poleceniami curl <IP>.

Jeśli nadal występują problemy, najprawdopodobniej konfiguracja sieci w cni.conf zasługuje na dodatkową uwagę. Zawsze można edytować ten plik statyczny. Konfiguracja zostanie zastosowana do wszystkich nowo utworzonych zasobów platformy Kubernetes.

Dlaczego? Jednym z wymagań sieciowych platformy Kubernetes (zobacz model Kubernetes ) jest komunikacja w klastrze bez użycia wewnętrznego NAT. W celu spełnienia tego wymagania mamy ExceptionList dla całej komunikacji, gdzie nie chcemy, żeby wystąpił NAT wychodzący. Oznacza to jednak również, że należy wykluczyć zewnętrzny adres IP, który chcesz przesłać zapytanie z listy ExceptionList. Tylko wtedy ruch pochodzący z zasobników systemu Windows będzie poprawnie ustawiony na SNAT, aby otrzymać odpowiedź ze świata zewnętrznego. W tym zakresie twoja lista wyjątków w cni.conf powinna wyglądać następująco:

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

Mój węzeł systemu Windows nie może uzyskać dostępu do usługi NodePort

Dostęp do lokalnego NodePort bezpośrednio z węzła może zakończyć się niepowodzeniem. Jest to znana luka funkcji, która jest rozwiązywana za pomocą aktualizacji zbiorczej KB4571748 (lub nowszej). Dostęp NodePort będzie działał z innych węzłów lub od klientów zewnętrznych.

Mój węzeł systemu Windows przestaje routować przez NodePorts po zmniejszeniu liczby moich zasobników.

Ze względu na ograniczenie projektu musi istnieć co najmniej jeden pod uruchomiony w węźle systemu Windows, aby przekierowanie NodePort działało.

Po pewnym czasie wirtualne karty sieciowe i punkty końcowe HNS kontenerów są usuwane

Ten problem może być spowodowany tym, że parametr hostname-override nie jest przekazywany do kube-proxy. Aby rozwiązać ten problem, użytkownicy muszą przekazać nazwę hosta do serwera kube-proxy w następujący sposób:

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

W trybie Flannel (VXLAN) moje zasobniki mają problemy z łącznością po tym, jak ponownie dołączą do węzła.

Za każdym razem, gdy wcześniej usunięty węzeł jest ponownie przyłączany do klastra, flannelD będzie próbować przypisać nową podsieć dla poda do węzła. Użytkownicy powinni usunąć stare pliki konfiguracji podsieci pod w następujących ścieżkach:

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

Po uruchomieniu platformy Kubernetes platforma Flanneld jest zablokowana w obszarze "Oczekiwanie na utworzenie sieci"

Ten problem należy rozwiązać za pomocą Flannel w wersji 0.12.0 (i nowszych). Jeśli używasz starszej wersji Flanneld, istnieje znany warunek wyścigu, który może spowodować, że adres IP zarządzania siecią flannel nie zostanie ustawiony. Obejściem jest po prostu ręczne ponowne uruchomienie 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

Nie można uruchomić zasobników systemu Windows z powodu braku /run/flannel/subnet.env

Oznacza to, że platforma Flannel nie uruchamiała się poprawnie. Możesz spróbować ponownie uruchomić flanneld.exe lub skopiować pliki ręcznie z /run/flannel/subnet.env na serwerze głównym Kubernetes na C:\run\flannel\subnet.env w węźle roboczym systemu Windows i zmodyfikować wiersz FLANNEL_SUBNET na przypisaną podsieć. Na przykład, jeśli przypisano podsieć węzła 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

Częściej niż nie występuje inny problem, który może powodować ten błąd, który należy zbadać najpierw. Zaleca się pozwolić, aby flanneld.exe wygenerował ten plik dla ciebie.

Łączność między kapsułami na hostach jest przerwana w klastrze Kubernetes uruchomionym w środowisku vSphere

Ponieważ zarówno vSphere, jak i Flannel rezerwują port 4789 (domyślny port VXLAN) dla sieci overlay, pakiety mogą zostać przechwycone. Jeśli platforma vSphere jest używana do sieci nakładkowej, należy ją skonfigurować tak, aby używała innego portu, aby zwolnić port 4789.

Moje punkty końcowe/adresy IP wyciekają

Istnieją 2 obecnie znane problemy, które mogą powodować wyciek punktów końcowych.

  1. Pierwszym znanym problemem jest problem w Kubernetes wersji 1.11. Unikaj korzystania z platformy Kubernetes w wersji 1.11.0 – 1.11.2.
  2. Drugi znany problem, który może spowodować wyciek punktów końcowych, dotyczy problematyki współbieżności w przechowywaniu punktów końcowych. Aby uzyskać poprawkę, należy użyć programu Docker EE 18.09 lub nowszego.

Moje zasobniki nie mogą zostać uruchomione z powodu błędów "network: failed to allocate for range" (nie można przydzielić zakresu dla sieci).

Oznacza to, że przestrzeń adresów IP na twoim węźle jest wyczerpana. Aby wyczyścić wszystkie wyciekłe punkty końcowe , zmigruj zasoby na dotkniętych węzłach & i uruchom następujące polecenia:

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

Mój węzeł systemu Windows nie może uzyskać dostępu do moich usług przy użyciu adresu IP usługi

Jest to znane ograniczenie bieżącego stosu sieciowego w systemie Windows. Zasobniki systemu Windows mogą jednak uzyskiwać dostęp do adresu IP usługi.

Nie można odnaleźć karty sieciowej podczas uruchamiania rozwiązania Kubelet

Aby sieć Kubernetes działała, stos sieci systemu Windows wymaga wirtualnej karty sieciowej. Jeśli następujące polecenia nie zwracają żadnych wyników (w powłoce administracyjnej), tworzenie sieci HNS — co jest niezbędnym warunkiem do działania Kubelet — nie powiodło się:

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

Często warto zmodyfikować parametr InterfaceName skryptu start.ps1, w przypadkach, gdy karta sieciowa hosta nie jest "Ethernet". W przeciwnym razie zapoznaj się z danymi wyjściowymi skryptu start-kubelet.ps1, aby sprawdzić, czy podczas tworzenia sieci wirtualnej występują błędy.

Nadal widzę problemy. Co należy zrobić?

W sieci lub na hostach mogą istnieć dodatkowe ograniczenia uniemożliwiające komunikację między węzłami. Upewnij się, że:

  • wybrana topologia sieci została prawidłowo skonfigurowana (l2bridge lub overlay)
  • ruch, który wygląda, jakby pochodził z zasobników, jest dozwolony
  • Ruch HTTP jest dozwolony, jeśli wdrażasz usługi internetowe
  • Pakiety z różnych protokołów (tj. protokół ICMP a TCP/UDP) nie są porzucane

Napiwek

Aby uzyskać dodatkowe zasoby samodzielnej pomocy, dostępny jest również przewodnik rozwiązywania problemów z siecią Kubernetes dla systemu Windows dostępny tutaj.

Typowe błędy systemu Windows

Moje zasobniki kubernetes są zablokowane w pozycji "ContainerCreating"

Ten problem może mieć wiele przyczyn, ale jednym z najczęstszych jest to, że obraz wstrzymania został nieprawidłowo skonfigurowany. Jest to ogólny objaw następnego problemu.

Podczas wdrażania kontenery platformy Docker są uruchamiane ponownie

Sprawdź, czy obraz wstrzymania jest zgodny z wersją systemu operacyjnego. Platforma Kubernetes zakłada, że zarówno system operacyjny, jak i kontenery mają pasujące numery wersji systemu operacyjnego. Jeśli używasz eksperymentalnej kompilacji systemu Windows, takiej jak kompilacja Insider, musisz odpowiednio dopasować obrazy. Zapoznaj się z repozytorium platformy Docker firmy Microsoft obrazów.

Typowe błędy głównego węzła Kubernetes

Debugowanie głównego serwera Kubernetes dzieli się na trzy główne kategorie (w kolejności prawdopodobieństwa):

  • Wystąpił problem z kontenerami systemu Kubernetes.
  • Coś jest nie tak ze sposobem działania kubelet.
  • Coś jest nie tak z systemem.

Uruchom kubectl get pods -n kube-system, aby zobaczyć zasobniki tworzone przez platformę Kubernetes; Może to dać wgląd w to, które konkretne z nich ulega awarii lub nie uruchamiają się poprawnie. Następnie uruchom docker ps -a, aby wyświetlić wszystkie surowe kontenery, które wspierają te pody. Na koniec uruchom docker logs [ID] na kontenerach, które są podejrzane o wystąpienie problemu, aby zobaczyć nieprzetworzone dane wyjściowe procesów.

Nie można nawiązać połączenia z serwerem interfejsu API w https://[address]:[port]

Częściej niż nie, ten błąd wskazuje problemy z certyfikatem. Upewnij się, że plik konfiguracji został wygenerowany poprawnie, adresy IP w nim zgodne z hostem i skopiowane do katalogu zainstalowanego przez serwer interfejsu API.

Dobre miejsca do znalezienia tego pliku konfiguracji to:

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

W przeciwnym razie zapoznaj się z plikiem manifestu serwera interfejsu API, aby sprawdzić punkty instalacji.