Kubernetes-felügyeleti és számítási feladatok fürtproblémáinak elhárítása az AKS Arcban

A Remove-ClusterNode parancs futtatásakor a rendszer kizárja a csomópontot a feladatátvevő fürtből, de ha a Remove-AksHciNode nem fut utána, a csomópont továbbra is létezik 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 fordul elő, mert a VHD megosztott tárolóban van, és az eltávolított csomópont nem rendelkezik hozzáféréssel.

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 parancsot Remove-AksHciNode a csomópont CloudAgentből való regisztrációjának törléséhez.
2. Rutinszerű karbantartást végezhet, például újraképezi a gépet.
3. Adja újra a fürthöz a csomópontot.
4. Futtassa a parancsot Add-AksHciNode a csomópont CloudAgenttel való regisztrálásához.

Nagy fürtök esetén előfordulhat, hogy a Get-AksHciLogs parancs kivételt jelez, nem tudja számba adni a csomópontokat, vagy nem hozza létre a c:\wssd\wssdlogs.zip kimeneti fájlt.

Ennek az az oka, hogy a Tömörítő archívum nevű fájl tömörítéséhez használt PowerShell-parancs kimeneti fájlméretkorlátja 2 GB.

A számítási feladatfürt frissítése vagy vertikális felskálázása után a tanúsítványmegújítási pod összeomlási hurok állapotban van, mert a pod a tanúsítványtetováló YAML-fájlt várja a fájl helyéről /etc/Kubernetes/pki.

Ezt a problémát a vezérlősík virtuális gépeiben található konfigurációs fájl okozhatja, de a munkavégző csomópont virtuális gépeiben nem.

A probléma megoldásához másolja manuálisan a tanúsítványtetováló YAML-fájlt a vezérlősík csomópontjáról az összes munkavégző csomópontra.

1. Másolja a YAML-fájlt a számítási feladatfürt vezérlősíkjának virtuális gépéről a gazdagép aktuális könyvtárába:

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. Másolja a YAML-fájlt a gazdagépről a munkavégző csomópont virtuális gépére. A fájl másolása előtt módosítania kell a YAML-fájlban lévő gép nevét arra a csomópontnévre, amelyre a másolást végezni kívánja (ez a számítási feladatfürt vezérlősíkjának csomópontneve).

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

3. Ha a YAML-fájl tulajdonosi és csoportadatai még nincsenek gyökérként beállítva, állítsa az adatokat a gyökérre:

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. Ismételje meg a 2. és a 3. lépést az összes munkavégző csomópont esetében.

Az Aks-Hci PowerShell-parancsok nem ellenőrzik a rendelkezésre álló memóriát a gazdagépkiszolgálón a Kubernetes-csomópontok létrehozása előtt. Ez a probléma memóriakimerüléshez és nem induló virtuális gépekhez vezethet.

Ezt a hibát jelenleg nem kezelik megfelelően, és az üzembe helyezés nem válaszol egyértelmű hibaüzenettel. Ha olyan üzemelő példánya van, amely nem válaszol, nyissa meg a eseménymegtekintő, és keressen egy Hyper-V-vel kapcsolatos hibaüzenetet, amely azt jelzi, hogy nincs elegendő memória a virtuális gép elindításához.

Amikor a Get-AksHciCluster futtatásával ellenőrzi az AKS Arc-telepítés állapotát a Windows Admin Center, a kimenet a következő hibaüzenetet jeleníti meg: "Az 1.0.3.10818-es verziójú kiadás NEM TALÁLHATÓ." A Get-AksHciVersion futtatásakor azonban ugyanazt a verziót telepítette. Ez a hiba azt jelzi, hogy a build lejárt.

A probléma megoldásához futtassa a parancsot Uninstall-AksHci, majd futtasson egy új AKS Arc-buildet.

Ha a fürtfelügyeleti eszközzel áthelyez egy virtuális gépet az egyik csomópontról (A csomópont) 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özteti a virtuális gépet az eredeti csomópontra, ott sem indul el.

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

A probléma megkerüléséhez győződjön meg arról, hogy a virtuális gép sikeresen elindult az új csomóponton, mielőtt visszaáll az eredeti csomópontra.

Ha a PowerShell használatával statikus IP-címekkel rendelkező fürtöt hoz létre, majd megkísérli növelni a munkavégző csomópontok számát a számítási feladatfürtben, a telepítés elakad a "vezérlősíkok száma 2-nél, továbbra is a kívánt állapotra vár: 3". Egy idő elteltével egy másik hibaüzenet jelenik meg: "Hiba: időtúllépés történt a feltételre várva".

A Get-AksHciCluster futtatásakor azt mutatta, hogy a vezérlősík csomópontjai létrehozva és kiépítve lettek, és kész állapotban voltak. A futtatáskor kubectl get nodes azonban azt mutatta, hogy a vezérlősík csomópontjai létrehozva lettek, de nem lettek kiépítve, és nem voltak kész állapotban.

Ha ez a hiba jelenik meg, ellenőrizze, hogy az IP-címek hozzá lettek-e rendelve a létrehozott csomópontokhoz a Hyper-V Kezelő vagy a PowerShell használatával:

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

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

Az olyan parancsok, mint Update-AksHcia , Update-AksHciCertificates, Update-AksHciClusterCertificatesés a felügyeleti fürt minden interakciója, a következőt adhatják vissza: "Hiba: Be kell jelentkeznie a kiszolgálóra (Jogosulatlan)."

Ez a hiba akkor fordulhat elő, ha a kubeconfig fájl lejárt. Annak ellenőrzéséhez, hogy lejárt-e, futtassa a következő szkriptet:

$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

Ha ez a szkript az aktuális dátumnál korábbi dátumot jelenít meg, akkor a kubeconfig fájl lejárt.

A probléma megoldásához másolja a felügyeleti vezérlősík virtuális gépén található admin.conf fájlt a HCI-gazdagépre:

• SSH a felügyeleti vezérlősík virtuális gépéhez:

  • Szerezze be a felügyeleti vezérlősík virtuálisgép-IP-címét:

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

  • SSH-val:

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

• Másolja a fájlt a clouduser helyére:

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

• Hozzáférés biztosítása a clouduserhez:

  sudo chown clouduser:clouduser admin.conf
  

• [Nem kötelező] Hozzon létre egy biztonsági másolatot a kubeconfig fájlról:

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

• Másolja ki a fájlt:

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

A Hyper-V-kezelő ellenőrzésekor a felügyeleti fürt magas processzor- és memóriaigényei biztonságosan figyelmen kívül hagyhatók. Ezek a számítási feladatok fürtjeinek kiépítésekor a számítási erőforrások kihasználtságának kiugró értékével kapcsolatosak.

A felügyeleti fürt memória- vagy PROCESSZORméretének növelése nem mutatott jelentős javulást, és biztonságosan figyelmen kívül hagyható.

A probléma akkor jelenik meg, ha az alábbi lépéseket követi:

1. Hozzon létre egy Kubernetes-fürtöt.
2. Skálázza a fürtöt két csomópontnál több csomópontra.
3. Csomópont törlése 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 Rendszergazdai jogosultságokkal rendelkező PowerShell-ablakot, és futtassa a következő parancsot:

get-vm

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

Ez a hiba miatt a rendszer nem ismeri fel, hogy a csomópont hiányzik, ezért egy új csomópont nem indul el.

Ha 60 napnál hosszabb ideig nem használ felügyeleti vagy számításifeladat-fürtöt, a tanúsítványok lejárnak, és meg kell újítania őket az AKS Arc frissítése előtt. Ha egy AKS-fürt 60 napon belül nem frissül, a KMS beépülő modul jogkivonata és a tanúsítványok is 60 napon belül lejárnak. A fürt továbbra is működőképes. Mivel azonban 60 napnál tovább tart, fel kell hívnia a Microsoft ügyfélszolgálatát a frissítéshez. Ha a fürt ezen időszak után újraindul, az nem funkcionális állapotban marad.

A probléma megoldásához futtassa az alábbi lépéseket:

1. Javítsa ki a felügyeleti fürt tanúsítványát a jogkivonat manuális elforgatásával, majd indítsa újra a KMS beépülő modult és a tárolót.
2. Javítsa ki a tanúsítványokat a mocctl futtatásával Repair-MocLogin.
3. Javítsa ki a számítási feladat fürttanúsítványait a jogkivonat manuális elforgatásával, majd indítsa újra a KMS beépülő modult és a tárolót.

Előfordulhat, hogy a számítási feladatfürt nem található, ha az Azure Stack HCI-üzemelő példányokon két AKS IP-címkészlete azonos vagy átfedésben van. Ha két AKS-gazdagépet helyez üzembe, és ugyanazt AksHciNetworkSetting a konfigurációt használja mindkettőhöz, a PowerShell és a Windows Admin Center valószínűleg nem találja a számítási feladatokat tartalmazó fürtöt, mivel az API-kiszolgáló ugyanazzal az IP-címmel lesz hozzárendelve mindkét fürtben, ami ü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.

A nagy méretű fürtök üzembe helyezése két óra elteltével időtúllépést okozhat. Ez azonban statikus időtúllépés.

Ezt az időtúllépési eseményt figyelmen kívül hagyhatja, mivel a művelet a háttérben fut. kubectl get nodes Az paranccsal érheti el a fürtöt, és figyelheti az előrehaladást.

Amikor néhány nap elteltével megkísérelt létrehozni egy AKS-t az Azure Stack HCI-n, Kubectl nem hajtotta végre egyik parancsát sem. A Key Management Service (KMS) beépülő modul naplója megjeleníti a hibaüzenetet 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 certificates.

A Repair-AksHciClusterCerts parancsmag meghiúsul, ha az API-kiszolgáló leállt. Ha az Azure Stack HCI-n futó AKS-t 60 vagy több napja nem frissítették, a KMS beépülő modul újraindításakor az 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 a KMS beépülő modult és a tárolót az API-kiszolgáló biztonsági mentésének lekéréséhez. Ehhez kövesse az alábbi lépéseket:

1. Forgassa el a jogkivonatot 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 az alábbi paranccsal. Az ip alábbi parancsban megadott beállítás az AKS-gazdagép vezérlősíkjának 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 a KMS beépülő modult és a tárolót.

   A tárolóazonosító lekéréséhez 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 megjelennie:

   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 Azure Stack HCI-n futó AKS-en az Windows Admin Center bővítmény 1.82.0-s verziójával a felügyeleti fürt a PowerShell használatával lett beállítva, és megkísérelték üzembe helyezni a számítási feladatokat tartalmazó fürtöt a Windows Admin Center használatával. Az egyik gépen telepítve volt a PowerShell-modul 1.0.2-es verziója, a többi gépen pedig az 1.1.3-as PowerShell-modul. A számításifeladat-fürt üzembe helyezésére tett kísérlet a következő hibával meghiúsult: "Nem található olyan paraméter, amely megegyezik a nodePoolName paraméternévvel". Ez a hiba a verzióeltérés miatt fordulhatott elő. A PowerShell 1.1.0-s verziójától kezdve a -nodePoolName <String> paraméter hozzá lett adva a New-AksHciCluster parancsmaghoz, és a terv szerint ez a paraméter már kötelező az Windows Admin Center bővítmény 1.82.0-s verziójának használatakor.

A probléma megoldásához tegye a következők valamelyikét:

• A PowerShell használatával manuálisan frissítheti a számítási feladatfürtöt az 1.1.0-s vagy újabb verzióra.
• A Windows Admin Center használatával frissítse a fürtöt az 1.1.0-s verzióra vagy a PowerShell legújabb verziójára.

Ez a probléma nem fordul elő, ha a felügyeleti fürt Windows Admin Center használatával van üzembe helyezve, mivel már telepítve vannak a legújabb PowerShell-modulok.

Amikor üzembe helyezi az AKS-t az Azure Stack HCI-ben, majd futtatja kubectl get pods, az ugyanabban a csomópontban lévő podok leállási állapotba kerülnek. A gép elutasítja az SSH-kapcsolatokat, mert a csomópont valószínűleg nagy memóriaigényt tapasztal. Ez a probléma azért fordul elő, mert a Windows-csomópontok túl vannak kiépítve, és nincs tartalék az alapvető összetevők számára.

A helyzet 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óhoz, hogy a csomópontok ne legyenek túl kiépítve. A Windows-csomópontok nem támogatják az erőforráskorlátok alapján történő kizárást, ezért meg kell becsülnie, hogy a tárolók mennyit fognak használni, majd győződjön meg arról, hogy a csomópontok elegendő processzor- és memóriamennyiséggel rendelkeznek. További információt a rendszerkövetelményekben talál.

A fürt automatikus skálázása meghiúsulhat, ha a következő Azure-szabályzatot használja az AKS-gazdagép-felügyeleti fürtön: "A Kubernetes-fürtök nem használhatják az alapértelmezett névteret." Ennek az az oka, hogy az AKS-gazdagép-felügyeleti fürtön implementált szabályzat letiltja az automatikus skálázási profilok létrehozását az alapértelmezett névtérben. A probléma megoldásához válasszon az alábbi lehetőségek közül:

• Távolítsa el a Azure Policy bővítményt az AKS-gazdagép felügyeleti fürtjén. További információ az Azure Policy bővítmények eltávolításáról itt.
• Módosítsa az Azure-szabályzat hatókörét az AKS-gazdagép-felügyeleti fürtök kizárásához. További információ Azure Policy hatókörökről itt.
• Állítsa a szabályzatkényszerítési módot "Letiltva" értékre az AKS-gazdagép-felügyeleti fürt esetében. További információ a kényszerítési módról itt.

Ez egy ismert probléma az Azure Stack HCI júliusi frissítésében (1.0.2.10723-es verzió). A hiba azért fordul elő, mert a CloudAgent szolgáltatás időtúllépést okoz a virtuális gépek több megosztott fürtkötet közötti elosztása során a rendszerben.

A probléma megoldásához frissítsen az Azure Stack HCI legújabb AKS-kiadására.

Ha az Azure Stack HCI-n nulla Linux- vagy Windows-csomóponttal rendelkező AKS-fürtöt épít ki, a Get-AksHciCluster futtatásakor a kimenet egy üres sztring vagy null érték lesz.

A Null a nulla csomópontok várt eredménye.

Ha négy napnál hosszabb ideig állít le egy felügyeleti vagy számítási feladatokat futtató fürtöt, a tanúsítványok lejárnak, és a fürt nem érhető el. A tanúsítványok azért járnak le, mert biztonsági okokból 3–4 naponta elforgatják őket.

A fürt újraindításához manuálisan kell javítania a tanúsítványokat, mielőtt bármilyen fürtműveletet végrehajthat. A tanúsítványok javításához futtassa a következő Repair-AksHciClusterCerts parancsot:

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

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

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

Amikor leskáláz egy fürtöt, a magas rendelkezésre állású fürterőforrások sikertelen állapotban vannak, miközben a virtuális gépek el lesznek távolítva. A probléma kerülő megoldása a sikertelen erőforrások manuális eltávolítása.

Egy Azure-beli virtuális gépen üzembe helyezett AKS-fürt korábban jól működött, de miután az AKS-gazdagép néhány napig ki lett kapcsolva, a Kubectl parancs nem működött. A vagy Kubectl get services a Kubectl get nodes parancs futtatása után a következő hibaüzenet jelent meg: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Ez a probléma azért fordult elő, mert az AKS-gazdagép négy napnál hosszabb ideig volt kikapcsolva, ami miatt a tanúsítványok lejártak. A tanúsítványok gyakran négynapos ciklusban vannak elforgatva. Futtassa a Repair-AksHciClusterCerts parancsot a tanúsítvány lejáratával kapcsolatos probléma megoldásához.

A statikus IP-címekkel és Windows-csomópontokkal rendelkező számítási feladatfürtökben a csomópont összes podja (beleértve a daemonset podokat is) tárolólétrehozási állapotban van. Amikor SSH használatával próbál csatlakozni a csomóponthoz, a kapcsolat hiba miatt Connection timed out meghiúsul.

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

Ha a kubelet lemezterhelés alatt áll, a nem használt tárolólemezképeket gyűjti össze, amelyek szüneteltető lemezképeket is tartalmazhatnak, és ha ez történik, a ContainerD nem tudja lekérni a lemezképet.

A probléma megoldásához futtassa az alábbi lépéseket:

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

sudo su

2. A rendszerkép lekéréséhez futtassa a következő parancsot:

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

Következő lépések

• Hibaelhárítási áttekintés
• Hálózatkezelési problémák és hibák
• tárterület ismert problémái