Rozwiązywanie problemów z zarządzaniem platformą Kubernetes i klastrem obciążeń w usłudze AKS Arc

Podczas uruchamiania polecenia Remove-ClusterNode węzeł zostanie wykluczony z klastra trybu failover, ale jeśli polecenie Remove-AksHciNode nie zostanie uruchomione później, węzeł nadal będzie istnieć w usłudze CloudAgent.

Ponieważ węzeł został usunięty z klastra, ale nie z usługi CloudAgent, jeśli używasz dysku VHD do utworzenia nowego węzła, zostanie wyświetlony błąd "Nie znaleziono pliku". Ten problem występuje, ponieważ dysk VHD znajduje się w magazynie udostępnionym, a usunięty węzeł nie ma do niego dostępu.

Aby rozwiązać ten problem, usuń węzeł fizyczny z klastra, a następnie wykonaj następujące kroki:

1. Uruchom polecenie Remove-AksHciNode , aby usunąć rejestrowanie węzła z usługi CloudAgent.
2. Wykonaj rutynową konserwację, taką jak ponowne tworzenie obrazu maszyny.
3. Dodaj węzeł z powrotem do klastra.
4. Uruchom polecenie Add-AksHciNode , aby zarejestrować węzeł w usłudze CloudAgent.

W przypadku dużych klastrów Get-AksHciLogs polecenie może zgłosić wyjątek, nie można wyliczyć węzłów lub nie wygeneruje pliku wyjściowego c:\wssd\wssdlogs.zip.

Dzieje się tak, ponieważ polecenie programu PowerShell w celu spakowania pliku "Compress-Archive" ma limit rozmiaru pliku wyjściowego 2 GB.

Po uaktualnieniu lub przeskalowaniu klastra obciążenia zasobnik odnawiania certyfikatu jest teraz w stanie pętli awaryjnej, ponieważ zasobnik oczekuje pliku YAML tatuażu certyfikatu z lokalizacji /etc/Kubernetes/pkipliku .

Ten problem może być spowodowany plikiem konfiguracji, który znajduje się na maszynach wirtualnych płaszczyzny sterowania, ale nie na maszynach wirtualnych węzła roboczego.

Aby rozwiązać ten problem, ręcznie skopiuj plik YAML tatuażu certyfikatu z węzła płaszczyzny sterowania do wszystkich węzłów procesu roboczego.

1. Skopiuj plik YAML z maszyny wirtualnej płaszczyzny sterowania w klastrze obciążenia do bieżącego katalogu maszyny hosta:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Skopiuj plik YAML z maszyny hosta do maszyny wirtualnej węzła roboczego. Przed skopiowaniem pliku należy zmienić nazwę maszyny w pliku YAML na nazwę węzła, do której kopiujesz (jest to nazwa węzła dla płaszczyzny sterowania klastra obciążenia).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Jeśli informacje o właścicielu i grupie w pliku YAML nie są jeszcze ustawione na katalog główny, ustaw informacje na katalog główny:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Powtórz kroki 2 i 3 dla wszystkich węzłów procesu roboczego.

Polecenia programu PowerShell usługi Aks-Hci nie weryfikują dostępnej pamięci na serwerze hosta przed utworzeniem węzłów kubernetes. Ten problem może prowadzić do wyczerpania pamięci i maszyn wirtualnych, które nie są uruchamiane.

Ta awaria nie jest obecnie obsługiwana pomyślnie, a wdrożenie przestanie odpowiadać bez wyraźnego komunikatu o błędzie. Jeśli masz wdrożenie, które przestaje odpowiadać, otwórz Podgląd zdarzeń i sprawdź komunikat o błędzie związany z funkcją Hyper-V wskazujący, że nie ma wystarczającej ilości pamięci, aby uruchomić maszynę wirtualną.

Podczas uruchamiania polecenia Get-AksHciCluster w celu sprawdzenia stanu instalacji usługi AKS Arc w centrum administracyjnym systemu Windows dane wyjściowe zawierają błąd: "Nie znaleziono wydania z wersją 1.0.3.10818". Jednak podczas uruchamiania polecenia Get-AksHciVersion pokazano, że zainstalowano tę samą wersję. Ten błąd wskazuje, że kompilacja wygasła.

Aby rozwiązać ten problem, uruchom polecenie , a następnie uruchom Uninstall-AksHcinową kompilację usługi AKS Arc.

W przypadku przenoszenia maszyny wirtualnej z jednego węzła (Node A) do innego węzła (węzeł B) w klastrze lokalnym platformy Azure przy użyciu narzędzia administracyjnego klastra maszyna wirtualna może nie uruchomić się w nowym węźle. Po przeniesieniu maszyny wirtualnej z powrotem do oryginalnego węzła nie będzie można tam również uruchomić.

Ten problem występuje, ponieważ logika czyszczenia pierwszej migracji jest uruchamiana asynchronicznie. W związku z tym logika "aktualizuj lokalizację maszyny wirtualnej" usługi Azure Kubernetes Service znajduje maszynę wirtualną na oryginalnej funkcji Hyper-V w węźle A i usuwa ją zamiast wyrejestrować.

Aby obejść ten problem, upewnij się, że maszyna wirtualna została pomyślnie uruchomiona w nowym węźle przed przeniesieniem go z powrotem do oryginalnego węzła.

W przypadku tworzenia klastra ze statycznymi adresami IP przy użyciu programu PowerShell, a następnie próby zwiększenia liczby węzłów roboczych w klastrze obciążenia instalacja jest zablokowana przy "liczbie płaszczyzny sterowania o wartości 2, nadal czekając na żądany stan: 3." Po upływie określonego czasu pojawia się inny komunikat o błędzie: "Błąd: przekroczono limit czasu oczekiwania na warunek".

Po uruchomieniu polecenia Get-AksHciCluster okazało się, że węzły płaszczyzny sterowania zostały utworzone i aprowidowane i były w stanie Gotowe . Jednak po kubectl get nodes uruchomieniu okazało się, że węzły płaszczyzny sterowania zostały utworzone, ale nie zostały aprowidowane i nie były w stanie Gotowe .

Jeśli wystąpi ten błąd, sprawdź, czy adresy IP zostały przypisane do utworzonych węzłów przy użyciu Menedżera funkcji Hyper-V lub programu PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Następnie sprawdź ustawienia sieci, aby upewnić się, że w puli pozostało wystarczające adresy IP, aby utworzyć więcej maszyn wirtualnych.

Polecenia, takie jak Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesi wszystkie interakcje z klastrem zarządzania, mogą zwracać komunikat "Błąd: musisz zalogować się na serwerze (brak autoryzacji)."

Ten błąd może wystąpić, gdy plik kubeconfig wygasł. Aby sprawdzić, czy wygasła, uruchom następujący skrypt:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Jeśli ten skrypt wyświetla datę wcześniejszą niż bieżąca data, plik kubeconfig wygasł.

Aby rozwiązać ten problem, skopiuj plik admin.conf znajdujący się wewnątrz maszyny wirtualnej płaszczyzny sterowania zarządzania do hosta lokalnego platformy Azure:

• Połączenie SSH z maszyną wirtualną płaszczyzny sterowania zarządzania:

  • Uzyskaj adres IP maszyny wirtualnej płaszczyzny sterowania zarządzania:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • Do niego należy zasunąć protokół SSH:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Skopiuj plik do lokalizacji clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Nadaj dostęp użytkownikowi clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Opcjonalnie] Utwórz kopię zapasową pliku kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Skopiuj plik:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Podczas sprawdzania menedżera funkcji Hyper-V można bezpiecznie zignorować wysokie wymagania dotyczące procesora CPU i pamięci dla klastra zarządzania. Są one związane ze wzrostem użycia zasobów obliczeniowych podczas aprowizowania klastrów obciążeń.

Zwiększenie rozmiaru pamięci lub procesora CPU dla klastra zarządzania nie wykazało znacznej poprawy i można je bezpiecznie zignorować.

Ten problem zostanie wyświetlony, jeśli wykonasz następujące kroki:

1. Tworzenie klastra Kubernetes.
2. Przeskaluj klaster na więcej niż dwa węzły.
3. Usuń węzeł, uruchamiając następujące polecenie:

kubectl delete node <node-name>

4. Zwróć listę węzłów, uruchamiając następujące polecenie:

kubectl get nodes

Usunięty węzeł nie jest wymieniony w danych wyjściowych. 5. Otwórz okno programu PowerShell z uprawnieniami administracyjnymi i uruchom następujące polecenie:

get-vm

Usunięty węzeł jest nadal wyświetlany.

Ta awaria powoduje, że system nie rozpozna, że brakuje węzła, a zatem nowy węzeł nie zostanie uruchomiony.

Jeśli nie używasz klastra zarządzania lub obciążenia przez dłużej niż 60 dni, certyfikaty wygasają i należy je odnowić, zanim będzie można uaktualnić usługę AKS Arc. Jeśli klaster usługi AKS nie zostanie uaktualniony w ciągu 60 dni, token wtyczki usługi KMS i certyfikaty wygasają w ciągu 60 dni. Klaster jest nadal funkcjonalny. Jednak ponieważ jest to ponad 60 dni, musisz zadzwonić do działu pomocy technicznej firmy Microsoft, aby przeprowadzić uaktualnienie. Jeśli klaster zostanie uruchomiony ponownie po tym okresie, pozostanie w stanie niefunkcjonalnym.

Aby rozwiązać ten problem, uruchom następujące kroki:

1. Napraw certyfikat klastra zarządzania przez ręczne obracanie tokenu, a następnie ponowne uruchomienie wtyczki i kontenera usługi KMS.
2. Napraw certyfikaty, mocctl uruchamiając polecenie Repair-MocLogin.
3. Napraw certyfikaty klastra obciążenia przez ręczne obracanie tokenu, a następnie ponowne uruchomienie wtyczki i kontenera usługi KMS.

Nie można odnaleźć klastra obciążenia, jeśli pule adresów IP dwóch usług AKS w wdrożeniach lokalnych platformy Azure są takie same lub nakładają się na siebie. Jeśli wdrożysz dwa hosty usługi AKS i użyjesz tej samej AksHciNetworkSetting konfiguracji dla obu tych klasterów, program PowerShell i centrum administracyjne systemu Windows mogą nie znaleźć klastra obciążenia, ponieważ serwer interfejsu API zostanie przypisany do tego samego adresu IP w obu klastrach, co spowoduje konflikt.

Otrzymany komunikat o błędzie będzie wyglądać podobnie do przedstawionego poniżej przykładu.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Wdrożenie dużego klastra może upłynął limit czasu po dwóch godzinach. Jednak jest to statyczny limit czasu.

To wystąpienie limitu czasu można zignorować, ponieważ operacja jest uruchomiona w tle. Użyj polecenia , kubectl get nodes aby uzyskać dostęp do klastra i monitorować postęp.

Podczas próby wywołania usługi AKS w lokalnym wdrożeniu platformy Azure po kilku dniach Kubectl nie wykonano żadnych poleceń. W dzienniku wtyczek usługa zarządzania kluczami (KMS) jest wyświetlany komunikat rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificateso błędzie .

Polecenie cmdlet Repair-AksHciClusterCerts kończy się niepowodzeniem, jeśli serwer interfejsu API nie działa. Jeśli usługa AKS na platformie Azure Lokalna nie została uaktualniona przez 60 lub więcej dni, po próbie ponownego uruchomienia wtyczki KMS nie zostanie uruchomiona. Ten błąd powoduje również niepowodzenie serwera interfejsu API.

Aby rozwiązać ten problem, należy ręcznie obrócić token, a następnie ponownie uruchomić wtyczkę usługi KMS i kontener, aby uzyskać kopię zapasową serwera interfejsu API. Aby to zrobić, wykonaj następujące kroki:

1. Obróć token, uruchamiając następujące polecenie:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Skopiuj token do maszyny wirtualnej przy użyciu następującego polecenia. Ustawienie ip w poniższym poleceniu odnosi się do adresu IP płaszczyzny sterowania hosta usługi AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Uruchom ponownie wtyczkę usługi KMS i kontener.

   Aby uzyskać identyfikator kontenera, uruchom następujące polecenie:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Dane wyjściowe powinny zostać wyświetlone z następującymi polami:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Dane wyjściowe powinny wyglądać podobnie do tego przykładu:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Na koniec uruchom ponownie kontener, uruchamiając następujące polecenie:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

W przypadku instalacji lokalnej usługi AKS na platformie Azure z rozszerzeniem Windows Admin Center w wersji 1.82.0 klaster zarządzania został skonfigurowany przy użyciu programu PowerShell i podjęto próbę wdrożenia klastra obciążenia przy użyciu programu Windows Admin Center. Na jednej z maszyn zainstalowano moduł programu PowerShell w wersji 1.0.2, a inne maszyny miały zainstalowany moduł programu PowerShell 1.1.3. Próba wdrożenia klastra obciążenia nie powiodła się z powodu błędu "Nie można odnaleźć parametru zgodnego z nazwą parametru "nodePoolName". Ten błąd mógł wystąpić z powodu niezgodności wersji. Począwszy od programu PowerShell w wersji 1.1.0, -nodePoolName <String> parametr został dodany do polecenia cmdlet New-AksHciCluster , a zgodnie z projektem ten parametr jest teraz obowiązkowy podczas korzystania z rozszerzenia Windows Admin Center w wersji 1.82.0.

Aby rozwiązać ten problem, wykonaj jedną z następujących czynności:

• Użyj programu PowerShell, aby ręcznie zaktualizować klaster obciążenia do wersji 1.1.0 lub nowszej.
• Użyj programu Windows Admin Center, aby zaktualizować klaster do wersji 1.1.0 lub najnowszej wersji programu PowerShell.

Ten problem nie występuje, jeśli klaster zarządzania jest wdrożony przy użyciu Centrum administracyjnego systemu Windows, ponieważ ma już zainstalowane najnowsze moduły programu PowerShell.

Podczas wdrażania usługi AKS na platformie Azure lokalnie, a następnie uruchamiania kubectl get podszasobników w tym samym węźle są zablokowane w stanie Kończenie. Maszyna odrzuca połączenia SSH, ponieważ węzeł prawdopodobnie ma duże zapotrzebowanie na pamięć. Ten problem występuje, ponieważ węzły systemu Windows są nadmiernie aprowizowane i nie ma rezerwy dla podstawowych składników.

Aby uniknąć takiej sytuacji, dodaj limity zasobów i żądania zasobów dla procesora CPU i pamięci do specyfikacji zasobnika, aby upewnić się, że węzły nie są nadmiernie aprowidowane. Węzły systemu Windows nie obsługują eksmisji na podstawie limitów zasobów, dlatego należy oszacować, ile kontenerów będzie używać, a następnie upewnić się, że węzły mają wystarczającą ilość procesora CPU i pamięci. Więcej informacji można znaleźć w temacie Wymagania systemowe.

Automatyczne skalowanie klastra może zakończyć się niepowodzeniem, jeśli w klastrze zarządzania hostami usługi AKS są używane następujące zasady platformy Azure: "Klastry Kubernetes nie powinny używać domyślnej przestrzeni nazw". Dzieje się tak, ponieważ zasady zaimplementowane w klastrze zarządzania hostami usługi AKS blokują tworzenie profilów skalowania automatycznego w domyślnej przestrzeni nazw. Aby rozwiązać ten problem, wybierz jedną z następujących opcji:

• Odinstaluj rozszerzenie usługi Azure Policy w klastrze zarządzania hostami usługi AKS. Dowiedz się więcej na temat odinstalowywania rozszerzeń usługi Azure Policy tutaj.
• Zmień zakres zasad platformy Azure, aby wykluczyć klastry zarządzania hostami usługi AKS. Dowiedz się więcej o zakresach usługi Azure Policy tutaj.
• Ustaw tryb wymuszania zasad na wartość "Wyłączone" dla klastra zarządzania hostami usługi AKS. Dowiedz się więcej o trybie wymuszania tutaj.

Jest to znany problem z usługą AKS w lokalnej aktualizacji z lipca platformy Azure (wersja 1.0.2.10723). Ten błąd występuje, ponieważ limit czasu usługi CloudAgent podczas dystrybucji maszyn wirtualnych między wieloma udostępnionymi woluminami klastra w systemie.

Aby rozwiązać ten problem, należy uaktualnić usługę AKS do najnowszej wersji lokalnej platformy Azure.

Jeśli aprowizujesz klaster usługi AKS na platformie Azure Lokalnie z zerowym systemem Linux lub węzłami systemu Windows, po uruchomieniu polecenia Get-AksHciCluster dane wyjściowe będą pustym ciągiem lub wartością null.

Wartość null jest oczekiwanym zwrotem dla węzłów zerowych.

Po zamknięciu klastra zarządzania lub obciążenia przez ponad cztery dni certyfikaty wygasają, a klaster jest niedostępny. Certyfikaty wygasają, ponieważ są obracane co 3–4 dni ze względów bezpieczeństwa.

Aby ponownie uruchomić klaster, należy ręcznie naprawić certyfikaty, zanim będzie można wykonać dowolne operacje klastra. Aby naprawić certyfikaty, uruchom następujące polecenie Repair-AksHciClusterCerts :

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Podczas skalowania klastra obciążenia odpowiednie maszyny wirtualne z systemem Linux i Windows zostały dodane jako węzły robocze, ale nie zostały skonfigurowane jako maszyny wirtualne o wysokiej dostępności. Podczas uruchamiania polecenia Get-ClusterGroup nowo utworzona maszyna wirtualna z systemem Linux nie została skonfigurowana jako grupa klastrów.

Jest to znany problem. Po ponownym uruchomieniu możliwość skonfigurowania maszyn wirtualnych jako wysoce dostępnych jest czasami utracona. Bieżące obejście polega na ponownym uruchomieniu wssdagent w każdym z węzłów lokalnych platformy Azure. Działa to tylko w przypadku nowych maszyn wirtualnych generowanych przez utworzenie pul węzłów podczas wykonywania operacji skalowania w poziomie lub podczas tworzenia nowych klastrów Kubernetes po ponownym uruchomieniu wssdagent węzłów w węzłach. Należy jednak ręcznie dodać istniejące maszyny wirtualne do klastra trybu failover.

Podczas skalowania klastra w dół zasoby klastra o wysokiej dostępności są w stanie niepowodzenia podczas usuwania maszyn wirtualnych. Obejściem tego problemu jest ręczne usunięcie nieudanych zasobów.

Klaster usługi AKS wdrożony na maszynie wirtualnej platformy Azure działał wcześniej prawidłowo, ale po wyłączeniu hosta usługi AKS przez kilka dni Kubectl polecenie nie działało. Po uruchomieniu Kubectl get nodes polecenia lub Kubectl get services zostanie wyświetlony następujący komunikat o błędzie: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Ten problem wystąpił, ponieważ host usługi AKS został wyłączony przez dłużej niż cztery dni, co spowodowało wygaśnięcie certyfikatów. Certyfikaty są często obracane w czterodniowym cyklu. Uruchom polecenie Repair-AksHciClusterCerts , aby rozwiązać problem z wygaśnięciem certyfikatu.

W klastrze obciążenia ze statycznymi adresami IP i węzłami systemu Windows wszystkie zasobniki w węźle (w tym daemonset zasobniki) są zablokowane w stanie ContainerCreating . Podczas próby nawiązania połączenia z tym węzłem przy użyciu protokołu SSH połączenie kończy się niepowodzeniem z powodu błędu Connection timed out .

Aby rozwiązać ten problem, użyj Menedżera funkcji Hyper-V lub Menedżera klastra trybu failover, aby wyłączyć maszynę wirtualną tego węzła. Po upływie od 5 do 10 minut węzeł powinien zostać ponownie utworzony z uruchomionymi wszystkimi zasobnikami.

Gdy narzędzie kubelet jest pod ciśnieniem dysku, zbiera nieużywane obrazy kontenerów, które mogą obejmować wstrzymywanie obrazów, a gdy tak się stanie, kontenerD nie może ściągnąć obrazu.

Aby rozwiązać ten problem, uruchom następujące kroki:

1. Połącz się z węzłem, którego dotyczy problem, przy użyciu protokołu SSH i uruchom następujące polecenie:

sudo su

2. Aby ściągnąć obraz, uruchom następujące polecenie:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Następne kroki

• Omówienie rozwiązywania problemów
• Problemy i błędy dotyczące sieci
• znane problemy z magazynem