Gyakori problémák a Azure Stack HCI-n üzemelő Azure Kubernetes Service

Ez a cikk a problémák néhány gyakori ismert Azure Stack HCI-n üzemelő Azure Kubernetes Service. A Felügyeleti központtal kapcsolatos ismert problémákat, valamint a Windows és a telepítési hibákat is áttekintheti.

A ContainerD nem tudja lehozni a szüneteltetési rendszerképet, mivel a kubelet tévesen gyűjti össze a rendszerképet

Ha a kubelet lemezes nyomás alatt van, a rendszer a nem használt tárolólemezképeket gyűjti, amelyek tartalmazhatnak szüneteltetési lemezképeket, és ha ez történik, a ContainerD nem tudja lehozni a lemezképet.

Az AKS jelenleg Azure Stack HCI ACR Azure Container Registry (ACR) hitelesítést használ áthidaló megoldásként egy ACR-hiba megoldásához. Ezért az ügyfelek számára megadott hitelesítő adatok használhatók az érintett csomópontokon található szüneteltetési képek lekért adataival, például felhasználónévvel: 1516df5a-f1cc-4a6a-856c-03d127b02d05, jelszó: 92684690-48b5-4dce-856d-ef4cccb54f22.

A probléma megoldásához futtassa a következő lépéseket:

  1. Csatlakozás SSH használatával az érintett csomóponthoz, és futtassa a következő parancsot:

    sudo su
    
  2. A rendszerkép lekért futtatásához futtassa a következő parancsot:

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

A Remove-AksHciCluster következő hibát okozza: A"my-workload-cluster" nevű számítási feladatfürt nem található

Ha ez a hiba a Remove-AksHciClusterfuttatásakor jelenik meg, ellenőrizze, hogy a megfelelő információkat használta-e a fürt eltávolításához.

A Remove-AksHciCluster következő hibaüzenetet kap: Hiba: nem lehet törölni a group clustergroup-spdb:... csoportot

A Remove-AksHciClusterfuttatásakor a következő hiba történik, mert holtpont lehet:

Hiba: a group clustergroup-spdb nem törölhető: nem sikerült törölni a clustergroup-spdb csoportot: rpc hiba: code = DeadlineExceeded desc = a környezeti határidő túllépve

A probléma megoldásához indítsa újra a CloudAgentet.

Statikus IP-címet tartalmazó számítási feladatfürtökben a csomóponton található összes pod TárolóLétrehozás állapotban marad

Statikus IP-címmel és Windows fürtökben a csomópont összes podja (a podokat is daemonset beleértve) daemonset állapotban marad. Amikor SSH-val próbál csatlakozni a csomóponthoz, a kapcsolat időkorrel való megszakadása miatt meghiúsul.

A probléma megoldásához használja a Hyper-V kezelője Feladatátvevőfürt-kezelő a csomópont virtuális gépét. 5–10 perc múlva újra létre kellett hozni a csomópontot, és az összes futó podgal.

A nem sikerült jogkivonat lekért hibaüzenet jelenik meg a Set-AksHciRegistration

A Nem sikerült jogkivonat-lekért hiba akkor fordulhat elő, ha több bérlő van az Azure-fiókjában. A $tenantId = (Get-AzContext).Tenant.Id megfelelő bérlő beállításhoz használja a következőt: . Ezután adja meg ezt a bérlőt paraméterként a Set-AksHciRegistration futtatásakor.

A Linux és Windows virtuális gépek nem voltak magas rendelkezésre állású virtuális gépekként konfigurálva a számítási feladatok fürtméretezésekor

Számítási feladatfürtök felméretezésekor a megfelelő Linux és Windows virtuális gépek munkavégző csomópontokként vannak hozzáadva, de nem magas rendelkezésre állású virtuális gépekként voltak konfigurálva. A Get-ClusterGroup parancs futtatásakor az újonnan létrehozott Linux rendszerű virtuális gép nem lett fürtcsoportként konfigurálva.

Ez egy ismert probléma. Az újraindítás után a virtuális gépek magas rendelkezésre állékonyként való konfigurálása néha elveszhet. A jelenlegi áthidaló megoldás az újraindítás az összes Azure Stack HCI wssdagent csomóponton. Vegye figyelembe, hogy ez csak olyan új virtuális gépek esetén működik, amelyek a csomópontkészletek létrehozásával jönnek létre a felskálás művelet végrehajtásakor vagy új Kubernetes-fürtök létrehozásakor a csomópontokon való újraindítás wssdagent után. A meglévő virtuális gépeket azonban manuálisan kell hozzáadnia a feladatátvevő fürthöz.

A fürtök horizontális leskáláskor a magas rendelkezésre állású fürterőforrások hibás állapotban vannak a virtuális gépek eltávolítása közben. A probléma megkerülő megoldása a sikertelen erőforrások manuális eltávolítása.

Az új munkaterhelési fürtök létrehozására tett kísérlet nem sikerült, mert az AKS-gazdagép több napig ki volt kapcsolva

Egy Azure-beli virtuális Azure Stack HCI üzembe helyezett AKS-fürt korábban megfelelően működött, de miután az AKS-gazdagép néhány napig ki volt kapcsolva, a parancs nem Kubectl működött. A vagy a parancs futtatása után a következő hibaüzenet jelent meg: Hiba a Kubectl get nodesKubectl get servicesKubectl get nodesa kiszolgálón ("") található hiba megakadályozta a kérés sikeres működését.

Ez a probléma azért merült fel, mert az AKS-gazdagép négy napnál hosszabb ideig ki volt kapcsolva, ami miatt a tanúsítványok lejártak. A tanúsítványok gyakran négynapos ciklusban vannak elforgatva. Futtassa a Repair-AksHciClusterCerts futtatásával javítsa ki a tanúsítvány lejárati dátumát.

Get-AksHCIClusterNetwork nem mutatja az IP-címek aktuális kiosztását

A Get-AksHciClusterNetwork parancs futtatása az összes virtuális hálózati konfiguráció listáját tartalmazza. A parancs azonban nem mutatja az IP-címek aktuális kiosztását. Az alábbi lépésekkel kideríti, hogy jelenleg milyen IP-címek vannak használatban a virtuális hálózatokban:

  1. A csoport lekért futtatásához futtassa a következő parancsot:

    Get-MocGroup -location MocLocation
    
  2. A jelenleg használatban lévő IP-címek listájának és az elérhető vagy használt virtuális IP-címek listájának lekért listájáért futtassa a következő parancsot:

    Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
    
  3. A jelenleg használatban lévő virtuális IP-címek listájának megtekintéséhez használja a következő parancsot:

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

Az API-kiszolgáló néhány nap után nem válaszol

Amikor néhány nap után megpróbált AKS-t Azure Stack HCI üzembe helyezés után, a nem futtatta Kubectl a parancsokat. A kulcskezelő szolgáltatás (KMS) beépülő modul naplójában a következő hibaüzenet jelenik meg: rpc error:code = Unauthenticated desc = Valid Token Required. Miután futtatta a Repair-AksHciCerts függvényt a probléma megoldásához, egy másik hiba jelent meg: nem sikerült kijavítani a fürttanúsítványokat.

A Repair-AksHciCerts parancsmag meghibásodik, ha az API-kiszolgáló nem működik. Ha a Azure Stack HCI AKS-t 60 vagy több napja nem frissítették, akkor az KMS beépülő modul újraindításakor nem indul el. Ez a hiba az API-kiszolgáló meghibásodását is okozza.

A probléma megoldásához manuálisan kell elforgatnia a jogkivonatot, majd újra kell indítania KMS beépülő modult és tárolót az API-kiszolgáló biztonsági frissítéséhez. Ehhez futtassa a következő lépéseket:

  1. A jogkivonat elforgatása a következő parancs futtatásával:

    $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
    
  2. Másolja a jogkivonatot a virtuális gépre a következő paranccsal. Az alábbi parancsban található beállítás az AKS-gazdagép vezérlősíkja ip IP-címére vonatkozik.

    $ 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. Indítsa újra KMS beépülő modult és a tárolót.

    A tárolóazonosító lekért futtatásához futtassa a következő parancsot:

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

    A kimenetnek a következő mezőkkel kell lennie:

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    

    A kimenetnek az alábbi példához hasonlóan kell kinéznie:

    4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
    
  4. Végül indítsa újra a tárolót a következő parancs futtatásával:

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

Az állandó kötetcímek konfigurálása a következő hibát okozza: Nem sikerült inicializálni az ügynököt. Hiba: mkdir /var/log/agent: engedély megtagadva

Az engedély megtagadva hiba: Nem sikerült inicializálni az ügynököt. Hiba: mkdir /var/log/agent: az engedély megtagadva azt jelzi, hogy az alapértelmezett tárolóosztály nem megfelelő a számítási feladatokhoz, és a Kubernetes 1.19.x vagy újabb verzióján futó Linux számítási feladatokban fordul elő. Az ajánlott biztonsági eljárásokat követve számos Linux számítási feladat határozza meg securityContext fsGroup a podok beállítását. A számítási feladatok nem indulnak el az AKS-on az Azure Stack HCI-ban, mivel az alapértelmezett tárolóosztály nem adja meg a paramétert, így a Kubernetes nem tudja módosítani a fájlok és állandó kötetek tulajdonjogát a számítási feladat által kért fstype (=ext4)fsGroup alapján.

A probléma megoldásához definiáljon egy egyéni tárolóosztályt, amely használható a PVC-k építéshez.

Állandó kötet létrehozásakor a kötet csatlakoztatási kísérlete meghiúsul

Miután töröl egy állandó kötetet vagy állandó kötet jogcímet egy AKS-Azure Stack HCI-környezetben, létrejön egy új állandó kötet, amely leképezi ugyanazt a megosztást. Amikor azonban megpróbálja csatlakoztatni a kötetet, a csatlakoztatás sikertelen lesz, és a pod a következő hibával időzül: NewSmbGlobalMapping sikertelen volt.

Az új kötet csatlakoztatási hibája úgy kerülhető meg, ha SSH-t csatlakoztat a Windows csomóponthoz, és futtatja a(z) futtatását, és adja meg a kötetnek megfelelő Remove-SMBGlobalMapping megosztást. A parancs futtatása után a kötet csatlakoztatási kísérletének sikeresnek kell lennie.

Előfordulhat, hogy a felhőügynök nem indul el sikeresen, ha szóközöket használó elérésiút-neveket használ

Ha a Set-AksHciConfig használatával a , , vagy paramétereket szóköz karaktert (például ) tartalmazó elérési útnévvel adja meg, a felhőügynök fürtszolgáltatása nem fog a következő (vagy hasonló) hibaüzenettel -workingDir-cloudConfigLocation-nodeConfigLocationD:\Cloud Share\AKS HCI kezdődni:

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'

Megkerülő megoldás: Használjon szóközöket nem magában foglaló elérési utat, C:\CloudShare\AKS-HCI például: .

A hálózati proxykiszolgáló blokkolja a HTTP-kéréseket

A platformkonfiguráció alkalmazásakor a hálózati proxykiszolgáló blokkolta a Google Chrome 65 felhasználói ügynök sztringjéről származó HTTP-kéréseket, mert ez a sztring egy elavult felhasználóiügynök-ügyfél.

A felhasználói ügynök a következő kiadásban a Google Chrome 91-re frissül.

Uninstall-AksHciAdAuth [Hiba a kiszolgálóról (NotFound): a "keytab-akshci-scale-reliability" titkos kulcsok nem találhatók]

Ha az Uninstall-AksHciAdAuth a következő hibát jeleníti meg: [Error from server (NotFound): secrets "keytab-akshci-scale-reliability" not found]. Ezt a hibát most hagyja figyelmen kívül, mivel a probléma megoldva lesz.

Uninstall-AksHCI nem tisztítja meg a fürterőforrásokat ( ownergroup ca-<GUID> )

A Active Directory engedélyei hiánya miatt az Uninstall-AksHci nem tudta eltávolítani a fürterőforrás-objektumokat a Active Directory-ban, ami a későbbi telepítések során meghibásodáshoz vezethet. A probléma megoldásához győződjön meg arról, hogy a telepítést végző felhasználó teljes hozzáféréssel rendelkezik Active Directory-objektumok létrehozásához/módosításához/eltávolításához abban a Active Directory-tárolóban, amelybe a kiszolgáló és a szolgáltatásobjektumok létre vannak hozva.

Hiba akkor fordul elő, Uninstall-AksHci és az AKS Azure Stack HCI nincs telepítve

Ha akkor futtatja az Uninstall-AksHci függvényt, amikor az AKS nincs telepítve az Azure Stack HCI-on, a következő hibaüzenet jelenik meg: Cannot bind argument to parameter 'Path' because it is null. Nyugodtan figyelmen kívül hagyhatja a hibaüzenetet, mivel ez nincs hatással a működésre.

Egy Arc-kompatibilis számítási feladatfürt létrehozásakor a Nem lehet null tömbbe indexelni hibaüzenetet

A Nem indexelhető null tömbbe hiba jelenik meg, amikor a PowerShell-ről Windows Felügyeleti központba egy Arc-kompatibilis számítási feladatfürt létrehozásához. Ezt a hibát nyugodtan figyelmen kívül hagyhatja, mivel az az ellenőrzési lépés része, és a fürt már létrejött.

Set-AksHciConfig WinRM-hibákkal meghiúsul, de azt mutatja, hogy a WinRM megfelelően van konfigurálva

A Set-AksHciConfig futtatásakora következő hiba jelenhet meg:

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.

Ez a hiba általában a felhasználó biztonsági jogkivonatának (a csoporttagság módosítása miatt), jelszóváltozásnak vagy lejárt jelszónak az eredménye. A legtöbb esetben a probléma úgy orvosolható, ha kijelentkezik a számítógépről, majd újra bejelentkezik. Ha ez a probléma továbbra is sikertelen, az AKS HCI GitHub problémáknál jelentheti bea problémát.

Ha a kubectl használatával töröl egy csomópontot, előfordulhat, hogy a társított virtuális gép nem törlődik

Ez a probléma akkor lép fel, ha követi az alábbi lépéseket:

  1. Kubernetes-fürt létrehozása.

  2. Skálázja a fürtöt több mint két csomópontra.

  3. Töröljön egy csomópontot a következő parancs futtatásával:

    kubectl delete node <node-name>
    
  4. Adja vissza a csomópontok listáját a következő parancs futtatásával:

    kubectl get nodes
    

    Az eltávolított csomópont nem szerepel a kimenetben.

  5. Nyisson meg egy PowerShellt rendszergazdai jogosultságokkal, és futtassa a következő parancsot:

    get-vm
    

Az eltávolított csomópont továbbra is megjelenik a listában.

Ez a hiba azt okozza, hogy a rendszer nem ismeri fel, hogy a csomópont hiányzik, ezért nem fog új csomópontot elforgatni.

A számítási feladat fürt nem található

Előfordulhat, hogy a számítási feladatfürt nem található meg, ha két AKS IP-címkészlete azonos vagy átfedésben van Azure Stack HCI üzemelő példányokban. Ha két AKS-gazdagépet helyez üzembe, és ugyanazt a konfigurációt használja mindkettőhöz, a PowerShell és az Windows Felügyeleti központ esetleg nem találja a számítási feladat fürtöt, mivel az API-kiszolgáló ugyanazt az IP-címet rendeli hozzá mindkét fürthöz, ami AksHciNetworkSetting ütközést eredményez.

A kapott hibaüzenet az alábbi példához hasonlóan fog kinézni.

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.

Megjegyzés

A fürt neve eltérő lesz.

A Hyper-V kezelője magas processzor- és/vagy memóriaigényt mutat a felügyeleti fürt számára

A Hyper-V kezelője esetén a felügyeleti fürt magas processzor- és memóriaigényét nyugodtan figyelmen kívül hagyhatja. Ezek általában a számításierőforrás-használat kiugróan magas kihasználtságával kapcsolatosak a számítási feladatok fürtjeinek kiépítésekor. A felügyeleti fürt memória- vagy CPU-méretének növelése nem mutatott jelentős javulást, és biztonságosan figyelmen kívül hagyható.

Speciális Active Directory engedélyek szükségesek a tartományhoz Azure Stack HCI csomópontokhoz

A Azure Stack HCI-n üzemelő Azure Kubernetes Service üzembe helyező és konfiguráló felhasználóknak "Teljes hozzáférés" engedéllyel kell rendelkezniük ahhoz, hogy AD-objektumokat hozzanak létre abban a Active Directory-tárolóban, amelyben a kiszolgáló és a szolgáltatásobjektumok létrejönnek.

A virtuális gépek fürtcsomópontok Azure Stack HCI közötti mozgatása gyorsan indítási hibákhoz vezet

Ha a fürtfelügyeleti eszközzel áthelyez egy virtuális gépet az egyik csomópontról (A csomópontról) egy másik csomópontra (B csomópont) az Azure Stack HCI-fürtben, előfordulhat, hogy a virtuális gép nem indul el az új csomóponton. Miután visszaköltözti a virtuális gépet az eredeti csomópontra, ott sem fog elindulni.

Ez a probléma azért fordul elő, mert az első áttelepítés megtisztító logikája aszinkron módon fut. Ennek eredményeképpen a Azure Kubernetes Service "virtuális gép helyének frissítése" logikája megkeresi a virtuális gépet az eredeti Hyper-V-en az A csomóponton, és törli a regisztráció törlése helyett.

A probléma megoldásához győződjön meg arról, hogy a virtuális gép sikeresen elindult az új csomóponton, mielőtt visszaköltözne az eredeti csomópontra.

Az Azure Stack HCI AKS a következő hibával meghiúsul: az msft.sme.aks nem tölthető be

Ha az msft.sme.aks nem tudott betöltési hibát kapni, és a hibaüzenet azt is jelzi, hogy az adattömbök betöltése sikertelen volt, használja az Microsoft Edge vagy a Google Chrome legújabb verzióját, és próbálkozzon újra.

New-AksHciCluster AKS-fürt 200 csomóponttal való létrehozásakor időkorrekta

Egy nagy fürt üzembe helyezése két óra után időkorrektálhat, ez azonban statikus időkorrekta. Ezt az időkorrekciót figyelmen kívül hagyhatja, mivel a művelet a háttérben fut. Az kubectl get nodes paranccsal férhet hozzá a fürthöz, és figyelheti a folyamat előrehaladását.

A terheléselosztási Azure Kubernetes Service DHCP-foglalást igényel

A terheléselosztási megoldás a Azure Stack HCI-n üzemelő Azure Kubernetes Service DHCP használatával rendeli hozzá az IP-címeket a szolgáltatásvégponthoz. Ha a szolgáltatás újraindítása miatt megváltozik a szolgáltatásvégpont IP-címe, a DHCP-címbérlet rövid lejárati idő miatt lejár. Ezért a szolgáltatás elérhetetlenné válik, mert a Kubernetes-konfigurációban az IP-cím eltér a végponton található ip-címtől. Ez ahhoz vezethet, hogy a Kubernetes-fürt elérhetetlenné válik. A probléma megoldásához használjon MAC-címkészletet az elosztott terhelésű szolgáltatásvégponthoz, és foglalhat le meghatározott IP-címeket a készlet minden MAC-címére.

Nagy fürtök használata esetén a Get-AksHciLogs parancs kivétellel meghiúsulhat

Nagy fürtök esetén a parancs kivételt okozhat, nem tudja enumerálni a csomópontokat, vagy nem hozza létre a c:\wssd\wssdlogs.zip Get-AksHciLogs kimeneti fájlt. Ennek az az oka, hogy a tömörített fájlt tömörítő PowerShell-parancs kimeneti fájlméretkorlátja 2 GB.

A hasonló konfigurációval konfigurált virtuális hálózatok létrehozása átfedési problémákat okoz

Ha a és a PowerShell-parancsmagok használatával átfedésben lévő hálózati objektumokat hoz new-akshcinetworksettingnew-akshciclusternetwork létre, problémák léphetnek fel. Ez például olyan esetekben fordulhat elő, amikor két virtuális hálózati konfiguráció majdnem azonos.

A Windows linuxos csomópontok száma nem látható a Get-AksHciCluster futtatásakor

Ha nulla Linux- vagy Windows-csomóponttal hoz létre egy AKS-fürtöt a Azure Stack HCI-ban, a Get-AksHciClusterfuttatásakor egy üres sztringet vagy null értéket kap kimenetként.

A munkavégző csomópontok számának növelésére tett kísérlet meghiúsul

Amikor a PowerShell használatával statikus IP-címmel hoz létre fürtöt, majd megpróbálja növelni a munkaterhelési fürt munkavégző csomópontjainak számát, a telepítés 2-es értéknél elakadt, és továbbra is a kívánt állapotra vár: 3. Egy idő után egy másik hibaüzenet jelenik meg: Hiba: időkorreklott a feltételre való várakozáskor.

A Get-AksHciCluster futtatásakor kiderült, hogy a vezérlősík csomópontjai létrejöttek és ki vannak építve, és Kész állapotban vannak. A futtatáskor azonban kiderült, hogy a vezérlősík csomópontjai létrejöttek, de nem voltak kiépítve, és nem kubectl get nodes voltak kubectl get nodes

Ha ezt a hibaüzenetet kap, ellenőrizze, hogy az IP-címek hozzá vannak-e rendelve a létrehozott csomópontokhoz a Hyper-V kezelője vagy a PowerShell használatával:

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

Ezután ellenőrizze a hálózati beállításokat, és győződjön meg arról, hogy elegendő IP-cím maradt a készletben további virtuális gépek létrehozásához.

Ha Távoli asztal a felügyeleti fürthöz való csatlakozáshoz, az kapcsolódási hibát jelez

Ha Távoli asztal-fürt egyik csomópontját rd Azure Stack HCI P-kapcsolattal futtatja, majd futtatja a Get-AksHciClustert,egy hibaüzenet jelenik meg, amely szerint a kapcsolat meghiúsult, mert a gazdagép nem válaszolt.

A kapcsolódási hiba oka az, hogy egyes PowerShell-parancsok az alábbihoz hasonló hibával kubeconfig-mgmt meghiúsulnak:

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.

A kube-vip pod két okból leállhat:

  • A rendszer memórianyomása lelassíthatja a rendszert, ami végül hatással etcd lesz a etcd
  • A kube-apiserver nem érhető el.

A probléma megoldásához próbálja meg újraindítani a gépet. Előfordulhat azonban, hogy a memória nyomásának lassulása vissza fog térni.

A kubectl get podok futtatásakora podok lezáró állapotban ragadtak

Ha az AKS-t Azure Stack HCI üzembe, majd futtatja a et, az ugyanabban a csomópontban található podok lezáró kubectl get podskubectl get pods A gép elutasítja az SSH-kapcsolatokat, mert a csomópont valószínűleg nagy memóriaigényt tapasztalt. Ez a probléma azért merül fel, Windows csomópontok túl vannak építve, és nincs tartalék az alapvető összetevők számára.

Ennek elkerülése érdekében adja hozzá a processzorra és a memóriára vonatkozó erőforráskorlátokat és erőforrás-kérelmeket a pod specifikációjába, hogy a csomópontok ne legyen túl kiépítve. Windows csomópontok nem támogatják az erőforráskorlátokon alapuló kilakoltatást, ezért meg kell becsülni, hogy a tárolók mennyi erőforrást fognak használni, majd gondoskodni kell arról, hogy a csomópontok elegendő processzor- és memóriamennyiségtel rendelkeznek. További információt a rendszerkövetelmények között talál.

A Remove-ClusterNode parancs futtatásakor a rendszer kiveszi a csomópontot a feladatátvevő fürtből, de a csomópont továbbra is létezik

A Remove-ClusterNode parancs futtatásakor a csomópont ki lesz távolítva a feladatátvevő fürtből, de ha ezt követően nem futtatja a Remove-AksHciNode csomópontot, a csomópont továbbra is létezni fog a CloudAgentben.

Mivel a csomópont el lett távolítva a fürtből, de a CloudAgentből nem, ha a VHD használatával hoz létre új csomópontot, a Fájl nem található hibaüzenet jelenik meg. Ez a probléma azért merül fel, mert a VHD megosztott tárolóban van, és a kihelyelt csomópontnak nincs hozzáférése hozzá.

A probléma megoldásához távolítsa el a fizikai csomópontot a fürtből, majd kövesse az alábbi lépéseket:

  1. Futtassa a következőt a csomópont a Remove-AksHciNode CloudAgentben való regisztrációjának a delegáltatáshoz: .
  2. Rutinkarbantartás végrehajtása, például a gép újraképezése.
  3. Adja újra a fürthöz a csomópontot.
  4. A Add-AksHciNode csomópont CloudAgentben való regisztráláshoz futtassa a következőt: .

Container Storage-illesztő podja ContainerCreating állapotban elakadt

Létrejött egy új Kubernetes számítási feladatfürt a Kubernetes 1.16.10-es verziójával, majd frissítve lett az 1.16.15-ös verzióra. A frissítés után a pod a ContainerCreating (Tároló létrehozása) állapotban maradt, a pod pedig Lezárás állapotban maradt, ahogy az alábbi csi-msk8scsi-node-9x47mcsi-msk8scsi-node-9x47mkube-proxy-qqnkr kimenetben látható: kube-proxy-qqnkr

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  

Mivel a kubelet rossz állapotba ért, és már nem tud beszélni az API-kiszolgálóval, az egyetlen megoldás a kubelet szolgáltatás újraindítása. Az újraindítás után a fürt futó állapotba kerül.

Következő lépések

Ha továbbra is problémákba merül fel a Azure Stack HCI-n üzemelő Azure Kubernetes Service használata esetén, a következővel GitHub.