Běžné problémy při používání služby Azure Kubernetes v Azure Stack HCI

Tento článek popisuje některé běžné známé problémy se službou Azure Kubernetes v Azure Stack HCI. můžete si také přečíst známé problémy s centrem pro správu Windows a problémy s instalací a chybami.

Kontejner je neschopen načíst obrázek pozastavení, protože kubelet omylem shromažďuje obrázek.

Když je kubelet na disku, shromažďuje nepoužívané image kontejnerů, které mohou obsahovat pozastavení imagí, a v případě, že k tomu dojde, kontejner nedokáže vyžádat image.

V současné době AKS Azure Stack HCI používá Azure Container Registry (ACR) pouze s ověřováním, které je jako alternativní řešení pro ACR chybu zakázané. Proto by se stejné přihlašovací údaje dodané zákazníkům daly použít k vyžádání imagí pozastavení na ovlivněných uzlech, například username: 1516df5a-f1cc-4A6A-856c-03d127b02d05, Password: 92684690-48b5-4dce-856d-ef4cccb54f22.

Chcete-li tento problém vyřešit, spusťte následující postup:

  1. Připojení k ovlivněnému uzlu pomocí protokolu SSH a spusťte následující příkaz:

    sudo su
    
  2. Pokud chcete načíst image, spusťte následující příkaz:

    crictl pull --creds aaa:bbb ecpacr.azurecr.io/pause:3.2
    

Při spuštění Remove-AksHciCluster dojde k chybě: cluster úloh s názvem "moje úloha-cluster" nebyl nalezen .

Pokud k této chybě dojde při spuštění Remove-AksHciCluster, měli byste zkontrolovat, zda jste použili správné informace pro odebrání clusteru.

Při spuštění Remove-AksHciCluster dojde k chybě: Chyba: skupinu clusterů nelze odstranit – SPDB:...

Při spuštění Remove-AksHciClusterdojde k následující chybě, protože může dojít k zablokování:

Chyba: skupinu clusterů nelze odstranit – SPDB: Nepodařilo se odstranit skupinu clusterů-SPDB: Chyba RPC: Code = DeadlineExceeded DESC = byl překročen konečný termín kontextu.

Pokud chcete tento problém vyřešit, restartujte CloudAgent.

V clusteru úloh se statickou IP adresou se všechny lusky v uzlu zablokují ve stavu ContainerCreating .

v clusteru úloh se statickými IP a Windows uzly jsou všechny lusky v uzlu (včetně daemonset lusků) zablokované ve stavu daemonset . Při pokusu o připojení k tomuto uzlu pomocí protokolu SSH dojde k chybě při vypršení časového limitu připojení .

Tento problém vyřešíte tak, že pomocí Správce technologie Hyper-V nebo Správce clusteru s podporou převzetí služeb při selhání vypnete virtuální počítač tohoto uzlu. Po pěti až deseti minutách by se měl uzel znovu vytvořit a se všemi běžícími lusky.

Při spuštění Set-AksHciRegistration se zobrazí chyba, že se nepovedlo získat token .

Pokud máte ve svém účtu Azure více tenantů, může dojít k chybě získání tokenu . Použijte $tenantId = (Get-AzContext).Tenant.Id k nastavení správného tenanta. Pak tento tenant zahrňte jako parametr při spuštění set-AksHciRegistration.

virtuální počítače Linux a Windows se při škálování clusteru úloh nenakonfigurovaly jako virtuální počítače s vysokou dostupností.

při horizontálním navýšení kapacity clusteru úloh byly odpovídající virtuální počítače se systémem Linux a Windows přidány jako pracovní uzly, ale nebyly konfigurovány jako virtuální počítače s vysokou dostupností. Při spuštění příkazu Get-cluster Group se nově vytvořený virtuální počítač se systémem Linux nenakonfiguroval jako skupina clusterů.

Jedná se o známý problém. Po restartování bude možnost konfigurovat virtuální počítače jako vysoce dostupná, někdy ztracena. Aktuální řešení je potřeba restartovat wssdagent v každém z Azure Stackch uzlů HCI. Všimněte si, že to funguje jenom pro nové virtuální počítače, které se generují při vytváření fondů uzlů při provádění operace horizontálního navýšení nebo při vytváření nových clusterů Kubernetes po restartování wssdagent uzlu. Do clusteru s podporou převzetí služeb při selhání ale budete muset přidat existující virtuální počítače ručně.

Při horizontálním navýšení kapacity clusteru jsou prostředky clusteru s vysokou dostupností v neúspěšném stavu, ale virtuální počítače se odeberou. Alternativním řešením tohoto problému je ruční odebrání prostředků, které selhaly.

Pokus o vytvoření nových clusterů úloh se nezdařil, protože hostitel AKS byl pro několik dní vypnutý.

AKS na Azure Stack v clusteru HCI nasazeném na virtuálním počítači Azure dříve pracovala správně, ale po vypnutí hostitele AKS po dobu několika dní Kubectl příkaz nefungoval. Po spuštění Kubectl get nodesKubectl get services příkazu nebo se zobrazí tato chybová zpráva: Kubectl get nodes.

K tomuto problému dochází, protože hostitel AKS byl vypnutý po dobu delší než čtyři dny, což způsobilo vypršení platnosti certifikátů. Certifikáty se v průběhu čtyř dnů často otáčejí. Opravte problém vypršení platnosti certifikátu spuštěním rutiny Repair-AksHciClusterCerts .

Get-AksHCIClusterNetwork nezobrazuje aktuální přidělení IP adres

Spuštěním příkazu Get-AksHciClusterNetwork získáte seznam všech konfigurací virtuální sítě. Příkaz ale nezobrazuje aktuální přidělení IP adres. Pokud chcete zjistit, jaké IP adresy se aktuálně používají ve virtuální síti, použijte následující postup:

  1. Chcete-li získat skupinu, spusťte následující příkaz:

    Get-MocGroup -location MocLocation
    
  2. Chcete-li získat seznam IP adres, které jsou právě používány, a seznam dostupných nebo použitých virtuálních IP adres, spusťte následující příkaz:

    Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
    
  3. K zobrazení seznamu virtuálních IP adres, které se aktuálně používají, použijte následující příkaz:

    Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10
    

Po několika dnech Server API nereaguje.

Při pokusu o uvedení Azure Stack AKS nasazení rozhraní HCI po několika dnech neproběhl Kubectl žádný z jeho příkazů. v protokolu modulu plug-in Služba správy klíčů (Služba správy klíčů) se zobrazila chybová zpráva chyba rpc: code = neověřený desc = je vyžadován neplatný Token. Po spuštění funkce Repair-AksHciCerts k pokusu o vyřešení problému se objevila odlišná Chyba: nepovedlo se opravit certifikáty clusteru.

Repair-AksHciCertsRutina se nezdařila, pokud je Server API mimo provoz. pokud se AKS na Azure Stack HCI neupgradoval na 60 nebo více dní, při pokusu o restartování Služba správy klíčů modulu plug-in se nespustí. Tato chyba také způsobí selhání serveru rozhraní API.

chcete-li tento problém vyřešit, je nutné ručně otočit token a poté restartovat modul plug-in a kontejner Služba správy klíčů a získat tak zálohování serveru rozhraní API. Provedete to spuštěním následujících kroků:

  1. Otočte token spuštěním následujícího příkazu:

    $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
    
  2. Pomocí následujícího příkazu zkopírujte token do virtuálního počítače. ipNastavení v následujícím příkazu odkazuje na IP adresu řídicí plochy hostitele 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. restartujte modul plug-in Služba správy klíčů a kontejner.

    Chcete-li získat ID kontejneru, spusťte následující příkaz:

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

    Výstup by měl mít následující pole:

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    

    Výstup by měl vypadat podobně jako v tomto příkladu:

    4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
    
  4. Nakonec restartujte kontejner spuštěním následujícího příkazu:

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

Při konfiguraci deklarací trvalých svazků dojde k chybě: nepodařilo se inicializovat agenta. Chyba: mkdir/var/log/agent: oprávnění odepřeno

Chyba odepření oprávnění, nelze inicializovat agenta. Chyba: mkdir/var/log/agent: oprávnění odepřeno znamená, že výchozí třída úložiště nemusí být vhodná pro vaše úlohy a probíhá v úlohách systému Linux běžících na Kubernetes verze 1.19. x nebo novější. Následující osvědčené postupy zabezpečení určují mnoho úloh pro Linux nastavení v poli securityContext fsGroup pod. Úlohy se nedaří spustit na AKS ve Azure Stack HCI, protože výchozí třída úložiště neurčuje fstype (=ext4) parametr, takže Kubernetes nemění vlastnictví souborů a trvalých svazků na základě fsGroup požadavku úlohy.

Pokud chcete tento problém vyřešit, Definujte vlastní třídu úložiště , kterou můžete použít k zřízení trvalého okruhu.

Při vytváření trvalého svazku se pokus o připojení svazku nezdaří.

Po odstranění trvalého svazku nebo deklarace identity trvalého svazku v AKS ve Azure Stack prostředí HCI se vytvoří nový trvalý svazek, který se namapuje na stejnou sdílenou složku. Při pokusu o připojení svazku se ale připojení nezdaří a v době, kdy došlo k chybě, se NewSmbGlobalMapping nepovedlo.

pokud chcete obejít selhání připojení nového svazku, můžete SSH do uzlu Windows a spustit Remove-SMBGlobalMapping a zadat sdílenou složku, která odpovídá danému svazku. Po spuštění tohoto příkazu se pokusy o připojení svazku musí podařit.

Při použití názvů cest s mezerami v nich nemusí být cloudového agenta úspěšné spuštění

Při použití set-AksHciConfig k určení -workingDir parametrů,, -cloudConfigLocation nebo -nodeConfigLocation s názvem cesty, který obsahuje znak mezery, například D:\Cloud Share\AKS HCI , se služba Cluster agenta Cloud agent nespustí s následující (nebo podobnou) chybovou zprávou:

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Alternativní řešení: použijte cestu, která nezahrnuje mezery, například C:\CloudShare\AKS-HCI .

Síťové proxy server blokují požadavky HTTP

Když použijete konfiguraci platformy, síťové proxy server zablokované požadavky HTTP pocházející z řetězce uživatelského agenta Google Chrome 65 , protože tento řetězec je neaktuální klient agenta uživatele.

V příští verzi se uživatelský agent aktualizuje na Google Chrome 91 .

Uninstall-AksHciAdAuth se nezdařila s chybou [Chyba ze serveru (NotFound): tajné klíče "keytab-akshci-Scale-spolehlivost" nenalezeny]

Pokud Uninstall-AksHciAdAuth zobrazí chybu, [Chyba ze serveru (NotFound): tajných kódů "keytab-akshci-Scale-spolehlivost" Nenalezeno]. Tuto chybu byste teď měli ignorovat, protože tento problém bude vyřešen.

Uninstall-AksHCI neprovádí čištění prostředků clusteru ( ownergroup ca-<GUID> )

Z důvodu nedostatečných oprávnění ve službě Active Directory funkce Uninstall-AksHci nemohla odebrat objekty prostředků clusteru ve službě Active Directory, což může vést k chybám v následných nasazeních. Chcete-li tento problém vyřešit, ujistěte se, že uživatel, který provádí instalaci, má oprávnění Úplné řízení k vytváření a úpravám nebo odebírání objektů služby Active Directory v kontejneru služby Active Directory, ve kterém jsou vytvořeny objekty serveru a služby.

Dojde k chybě při spuštění Uninstall-AksHci a AKS v Azure Stack HCI není nainstalovaná.

Pokud spustíte rutinu Uninstall-AksHci , když není nainstalovaná AKS na Azure Stack HCL, zobrazí se chybová zpráva: nejde vytvořit vazby argumentu pro parametr Path, protože je null. Chybovou zprávu můžete bezpečně ignorovat, protože neexistuje žádný vliv na funkčnost.

Při vytvoření clusteru úloh s povoleným obloukem se chyba nemůže indexovat do pole s hodnotou null .

chyba se nedá indexovat do pole s hodnotou null , která se při přechodu z powershellu do centra pro správu Windows k vytvoření clusteru úloh s povoleným obloukem. Tuto chybu můžete bezpečně ignorovat, protože je součástí kroku ověření a cluster už je vytvořený.

Set-AksHciConfig se nezdařila s chybami WinRM, ale zobrazuje, že služba WinRM je nakonfigurována správně

Při spuštění set-AksHciConfigmůže dojít k následující chybě:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

Většinou k této chybě dochází v důsledku změny tokenu zabezpečení uživatele (z důvodu změny členství ve skupinách), změny hesla nebo hesla s vypršenou platností. Ve většině případů je možné problém opravit odhlášením z počítače a opětovným přihlášením. pokud se to pořád nepovede, můžete problém vyřešit GitHub AKS hcl.

Při použití kubectl k odstranění uzlu se nemusí přidružený virtuální počítač odstranit.

Tento problém se zobrazí, pokud budete postupovat podle těchto kroků:

  1. Vytvořte cluster Kubernetes.

  2. Škálovat cluster na více než dva uzly.

  3. Odstraňte uzel spuštěním následujícího příkazu:

    kubectl delete node <node-name>
    
  4. Spuštěním následujícího příkazu vraťte seznam uzlů:

    kubectl get nodes
    

    Odebraný uzel není uveden ve výstupu.

  5. Otevřete PowerShell s oprávněními správce a spusťte následující příkaz:

    get-vm
    

Odebraný uzel je stále uveden v seznamu.

Příčinou této chyby je, že systém nerozpoznal, že uzel chybí, a proto se nový uzel netočí.

Cluster úloh se nenašel.

Cluster úloh se nemusí najít, pokud jsou fondy IP adres dvou AKS na Azure Stack s nasazením HCI stejné nebo překrývají. pokud nasadíte dva hostitele AKS a použijete stejnou AksHciNetworkSetting konfiguraci pro prostředí PowerShell a centrum pro správu Windows, může se stát, že se cluster úloh nepodaří najít, protože k serveru rozhraní API se přiřadí stejná IP adresa v obou clusterech v důsledku konfliktu.

Chybová zpráva, která se zobrazí, bude vypadat podobně jako v příkladu uvedeném níže.

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.

Poznámka

Název clusteru se bude lišit.

Správce technologie Hyper-V zobrazuje vysoké nároky na procesor nebo paměť pro cluster pro správu.

Po kontrole Správce technologie Hyper-V je možné ignorovat vysoké nároky na procesor a paměť pro cluster pro správu. Při zřizování clusterů úloh obvykle souvisí s špičkami při využití výpočetních prostředků. Zvýšení paměti nebo velikosti procesoru pro cluster pro správu se neukázalo výrazným vylepšením a je možné je bezpečně ignorovat.

Pro připojené k doméně Azure Stackch uzlů HCI se vyžadují speciální oprávnění služby Active Directory.

Uživatelé, kteří nasazují a konfigurují službu Azure Kubernetes v Azure Stack HCI, musí mít oprávnění "úplné řízení" pro vytváření objektů služby AD v kontejneru služby Active Directory, ve kterém jsou vytvořeny objekty serveru a služby.

Přesun virtuálních počítačů mezi uzly clusteru Azure Stack HCI rychle vede k selháním při spuštění virtuálních počítačů.

Když pomocí nástroje pro správu clusteru přesunete virtuální počítač z jednoho uzlu (Node A) do jiného uzlu (uzel B) v clusteru Azure Stack HCI, nemusí se virtuální počítač na novém uzlu spustit. Po přesunu virtuálního počítače zpátky do původního uzlu se nepodaří spustit i jeho spuštění.

K tomuto problému dochází, protože logika pro vyčištění první migrace se spouští asynchronně. Výsledkem je, že logika "umístění virtuálního počítače služby Azure Kubernetes" vyhledá virtuální počítač v původním Hyper-V na uzlu A a odstraní ho místo zrušení registrace.

Pokud chcete tento problém obejít, ujistěte se, že se virtuální počítač úspěšně začal na novém uzlu, a potom ho přemístěte zpátky na původní uzel.

Balíček AKS pro stažení Azure Stack HCI se nezdařil s chybou: MSFT. msp. AKS se nepovedlo načíst .

pokud se vám zobrazí zpráva msft. msp. aks se nepovedlo načíst a chybová zpráva taky indikuje, že selhalo načítání bloků dat, měli byste použít nejnovější verzi Microsoft Edge nebo Google Chrome a zkusit to znovu.

Vyprší New-AksHciCluster při vytváření clusteru AKS s uzly 200.

Nasazení velkého clusteru může trvat déle než dvě hodiny, ale jedná se o statický časový limit. Tento časový limit můžete ignorovat, protože operace je spuštěná na pozadí. Použijte kubectl get nodes příkaz pro přístup ke clusteru a sledujte průběh.

Load Balancer ve službě Azure Kubernetes vyžaduje rezervaci DHCP.

Řešení vyrovnávání zatížení ve službě Azure Kubernetes v Azure Stack HCI používá protokol DHCP k přiřazování IP adres koncovým bodům služby. Pokud se IP adresa pro koncový bod služby změní kvůli restartování služby, zapůjčení DHCP vyprší kvůli krátké době vypršení platnosti. Služba proto nebude přístupná, protože IP adresa v konfiguraci Kubernetes se liší od toho, co je na koncovém bodu. To může způsobit, že cluster Kubernetes nebude k dispozici. Pokud se chcete tomuto problému vyhnout, použijte pro koncové body služby Vyrovnávání zatížení fond adres MAC a pro každou adresu MAC ve fondu rezervujte konkrétní IP adresy.

Při použití velkých clusterů může příkaz Get-AksHciLogs selhat s výjimkou.

U velkých clusterů Get-AksHciLogs může příkaz vyvolat výjimku, selže při vytváření výčtu uzlů nebo negeneruje výstupní soubor c:\wssd\wssdlogs.zip. Důvodem je to, že příkaz prostředí PowerShell pro soubor zip, komprimovaný do archivu má omezení velikosti výstupních souborů na 2 GB.

Vytváření virtuálních sítí s podobnými příčinami konfigurace překrývající problémy

Při vytváření překrývajících se síťových objektů new-akshcinetworksetting pomocí new-akshciclusternetwork rutin PowerShellu a můžou nastat problémy. K tomu může dojít například ve scénářích, kdy jsou dvě konfigurace virtuální sítě skoro stejné.

při spuštění Get-AksHciCluster nelze zobrazit počet uzlů Windows nebo Linux.

pokud zřídíte cluster AKS na Azure Stack hcl s nulovým nebo Windowsm uzlem, při spuštění rutiny get-AksHciClusterse jako výstup zobrazí prázdný řetězec nebo hodnota null.

Pokus o zvýšení počtu neúspěšných pracovních uzlů

Když pomocí PowerShellu vytvoříte cluster se statickou IP adresou a pak se pokusíte zvýšit počet pracovních uzlů v clusteru úloh, instalace se zablokuje na úrovni řídicích roviny ve 2 a stále čeká na požadovaný stav: 3. Po určité době se zobrazí další chybová zpráva: Chyba: vypršel časovýlimit při čekání na podmínku.

Po spuštění rutiny Get-AksHciCluster se ukázalo, že se vytvořily a zřídily uzly řídicí plochy a byly ve stavu připraveno . Při kubectl get nodes spuštění se ale ukázalo, že se vytvořily uzly řídicí plochy, ale nezřídily se a nedostaly se do kubectl get nodes stavu.

Pokud se zobrazí tato chyba, ověřte, že se IP adresy přiřadily k vytvořeným uzlům pomocí Správce technologie Hyper-V nebo PowerShellu:

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

Pak ověřte nastavení sítě a zajistěte, aby ve fondu zůstala dostatečná IP adresa pro vytvoření dalších virtuálních počítačů.

Použití vzdálené plochy pro připojení k clusteru pro správu vytvoří chybu připojení.

Při použití vzdálené plochy (RDP) pro připojení k jednomu z uzlů v clusteru Azure Stack HCI a následném spuštění Get-AksHciClusterse zobrazí chyba a zpráva o připojení se nezdařila, protože hostitel nedokázal odpovědět.

Důvodem selhání připojení je, že některé příkazy PowerShellu, které se nepoužívají, jsou v důsledku kubeconfig-mgmt chyby podobné následujícímu:

Unable to connect to the server: d ial tcp 172.168.10.0:6443, where 172.168.10.0 is the IP of the control plane.

Kube-VIP pod může přejít ze dvou důvodů:

  • Tlak paměti v systému může zpomalit etcd , což končí ovlivnění etcd.
  • Kube-apiserver není k dispozici.

Abyste mohli tento problém vyřešit, zkuste restartovat počítač. Problém s zpomalením zatížení paměti ale může vracet.

Při spuštění kubectlu získátev případě ukončujícího stavu lusky.

Když nasadíte AKS na Azure Stack HCI a pak běží kubectl get pods , lusky ve stejném uzlu se zablokují ve stavu kubectl get pods . Počítač odmítne připojení SSH, protože uzel pravděpodobně vykazuje hodně požadavků na paměť. k tomuto problému dochází, protože uzly Windows jsou předem zřízené a pro základní součásti není k dispozici žádná rezerva.

Abyste se vyhnuli této situaci, přidejte omezení prostředků a požadavky na prostředky pro procesor a paměť do specifikace pod, aby se zajistilo, že se uzly nezřídí. uzly Windows nepodporují vyřazení na základě limitů prostředků, takže byste měli odhadnout, kolik kontejnerů bude používat, a pak zajistit, aby uzly měly dostatečné nároky na procesor a paměť. Další informace najdete v požadavcích na systém.

Spuštění příkazu Remove-ClusterNode vyřadí uzel z clusteru s podporou převzetí služeb při selhání, ale uzel stále existuje.

Při spuštění příkazu Remove-ClusterNode je uzel vyřazen z clusteru s podporou převzetí služeb při selhání, ale pokud rutinu Remove-AksHciNode nespustí, bude uzel stále existovat v CloudAgent.

Vzhledem k tomu, že uzel byl odebrán z clusteru, ale nikoli z CloudAgent, pokud použijete k vytvoření nového uzlu virtuální pevný disk, zobrazí se chyba soubor nenalezen . K tomuto problému dochází, protože virtuální pevný disk je ve sdíleném úložišti a vyřazený uzel nemá k němu přístup.

Pokud chcete tento problém vyřešit, odeberte z clusteru fyzický uzel a pak postupujte podle následujících kroků:

  1. Spusťte příkaz Remove-AksHciNode ke zrušení registrace uzlu z CloudAgent.
  2. Proveďte rutinní údržbu, jako je třeba opakované vytvoření bitové kopie počítače.
  3. Přidejte uzel zpátky do clusteru.
  4. Spusťte Add-AksHciNode pro registraci uzlu pomocí CloudAgent.

Rozhraní kontejneru úložiště pod zablokované ve stavu ContainerCreating

Vytvořil se nový cluster úloh Kubernetes s Kubernetes verze 1.16.10 a pak se aktualizoval na 1.16.15. Po aktualizaci se csi-msk8scsi-node-9x47m pod ním zablokuje ve stavu csi-msk8scsi-node-9x47m a v kube-proxy-qqnkrkube-proxy-qqnkr stavu, jak je znázorněno na výstupu níže, se zablokuje.

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Vzhledem k tomu, že služba kubelet skončila v chybném stavu a již nemůže komunikovat se serverem API, jediným řešením je restartování služby kubelet . Po restartování přejde cluster do běžícího stavu.

Další kroky

Pokud budete při používání služby Azure Kubernetes v Azure Stack HCI nadále pracovat s problémy, můžete do souboru pomocí GitHubzaprotokolovat chyby.