Szerkesztés

Megosztás a következőn keresztül:


Az AKS Arc frissítésével kapcsolatos problémák megoldása

Ez a cikk azokat az ismert problémákat és hibákat ismerteti, amelyekkel Azure Kubernetes Service (AKS) Arc-üzemelő példányok legújabb kiadásra való frissítése során találkozhat. A Windows Admin Center és az AKS Azure Stack HCI-n való telepítésekor is áttekintheti az ismert problémákat.

A sikeres frissítés után a PowerShell régebbi verziói nem lesznek eltávolítva

A PowerShell régebbi verziói nem törlődnek.

A probléma megoldásához futtassa ezt a szkriptet a régebbi PowerShell-verziók eltávolításához.

A tanúsítványmegújítási pod összeomlási hurok állapotban van

A célfü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. Egy cert tattoo yaml fájlt vár az útvonalról /etc/Kubernetes/pki. A konfigurációs fájl megtalálható a vezérlősík-csomópont virtuális gépeiben, a munkavégző csomópont virtuális gépeinél azonban nem.

Megjegyzés

Ezt a problémát a 2022. áprilisi kiadás után javítottuk.

A probléma megoldásához másolja manuálisan a cert tattoo fájlt a vezérlősík csomópontjáról az egyes munkavégző csomópontokra.

  1. Másolja a fájlt a vezérlősík 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 works)
    scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
    
  2. Másolja a fájlt a gazdagépről a munkavégző csomópont virtuális gépére.

    scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
    
  3. Állítsa vissza a fájl tulajdonosi és csoportadatait root értékre, ha még nincs root értékre állítva.

    ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
    sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the cert file to 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 egyes munkavégző csomópontok esetében.

Kiszivárgott csomóponti portok, ha lejárt jogkivonat miatt nem lehet csatlakozni a cloudagenthez, ha a fürt 60 napnál tovább nem frissült

Ha egy fürtöt 60 napnál tovább nem frissítettek, a csomópontügynök a jogkivonat lejárata miatt nem indul el a csomópontügynök újraindítása során. Ez a hiba miatt az ügynökök a kezdő fázisban lesznek. A cloudagenthez való folyamatos csatlakozási kísérletek kimeríthetik a gazdagép portjainak kínálatát. A következő parancs állapota Indítás.

Get-Service wssdagent | Select-Object -Property Name, Status

Várt viselkedés: A csomópontügynöknek a kezdő fázisban kell lennie, amely folyamatosan megpróbál csatlakozni a felhőügynökhöz, és kimeríti a portokat.

A probléma megoldásához állítsa le a wssdagent futtatását. Mivel a szolgáltatás a kezdeti fázisban van, megakadályozhatja a szolgáltatás leállítását. Ha igen, állítsa le a folyamatot, mielőtt megkísérli leállítani a szolgáltatást.

  1. Ellenőrizze, hogy a wssdagent kezdő fázisban van-e.

    Get-Service wssdagent | Select-Object -Property Name, Status
    
  2. A folyamat leállítása.

    kill -Name wssdagent -Force
    
  3. Állítsa le a szolgáltatást.

    Stop-Service wssdagent -Force
    

Megjegyzés

A wssdagent folyamat a szolgáltatás leállítása után is néhány másodpercen belül elindul, mielőtt leáll. Mielőtt továbblép a következő lépésre, győződjön meg arról, hogy a következő parancs hibát ad vissza az összes csomóponton.

Get-Process -Name wssdagent
PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand
  1. Ismételje meg az 1., 2. és 3. lépést a HCI-fürt minden olyan csomópontján, amelynél ez a probléma merült fel.

  2. Miután meggyőződett arról, hogy a wssdagent nem fut, indítsa el a cloudagentet, ha nem fut.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName
  1. Ellenőrizze, hogy a cloudagent működik-e.

    Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
    
  2. Futtassa a következő parancsot a wssdagent javításához:

    Repair-Moc
    
  3. A parancs befejeződése után a wssdagentnek futó állapotban kell lennie.

    Get-Service wssdagent | Select-Object -Property Name, Status
    

Az MOC-ügynökök nem indulnak el frissítési hiba után

Ha az AKS-HCI nem frissít a májusi kiadásról a júniusi kiadásra, az AKS-HCI-nek vissza kell térnie a májusi kiadásra, és továbbra is működnie kell. Az MOC-ügynököket azonban leállított állapotban hagyja, és az ügynök elindítására tett manuális kísérletek nem aktiválják őket.

Megjegyzés

Ez a probléma csak akkor releváns, ha a májusi kiadásról a júniusi kiadásra frissít.

A reprodukálás lépései

  1. Telepítse az AKS-HCI PowerShell-modul 1.1.36-os verzióját.
  2. Frissítse az AKS-HCI-t. Ha a frissítés sikertelen, az AKS-HCI májusra esik vissza, de az MOC-ügynökök leállnak.

Várható viselkedés

Ha a Aks-Hci frissítés sikertelen, az elvárás az, hogy az AksHci visszatér az előző kiadásra, és probléma nélkül továbbra is működni fog.

Hibajelenségek

Eltérés a Aks-Hci és az MOC-verzió között

  • Get-AksHciVersion: 1.0.10.10513
  • Get-MocVersion: 1.0.11.10707

Eltérés Get-MocVersion és wssdcloudagent.exe verziója között

Get-MocVersion azt jelzi, hogy a júniusi build telepítve van, míg a wssdcloudagent.exe verzió azt jelzi, hogy a májusi build telepítve van.

Az MOC-ügynökszolgáltatás rendszerképének elérési útja üzembehelyezési azonosító paraméterrel rendelkezik

Futtassa a következő parancsot a felhőügynök képútvonalának megjelenítéséhez:

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

Példakimenet

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

A következő paranccsal jelenítheti meg a csomópontügynök rendszerképének elérési útját: reg lekérdezés : "HKLM\System\CurrentControlSet\Services\wssdagent"

Példakimenet

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

A probléma megoldásához futtassa a következő PowerShell-parancsmagokat:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

A frissítés során elvesznek az egyéni csomópontok, szerepkörök és címkék

Frissítéskor elveszítheti a munkavégző csomópontokhoz hozzáadott összes egyéni fertőzöttet, szerepkört és címkét. Mivel az AKS egy felügyelt szolgáltatás, a megadott PowerShell-parancsmagokon vagy Windows Admin Center kívül végzett egyéni fertőzöttségeket, címkéket és szerepköröket nem lehet hozzáadni.

A probléma megkerüléséhez futtassa a New-AksHciNodePool parancsmagot, hogy megfelelően hozzon létre egy csomópontkészletet, amely fertőzött a munkavégző csomópontokhoz.

Az AKS Arc szabályzaton kívüli lesz, ha egy számításifeladat-fürt 60 nap alatt nem lett létrehozva

Ha létrehozott egy felügyeleti fürtöt, de az első 60 napban nem helyezett üzembe számításifeladat-fürtöt, a rendszer letiltja a létrehozást, mert az már szabályzaton kívüli. Ebben az esetben az Update-AksHci futtatásakor a frissítési folyamat le lesz tiltva az "AksHci számlázási operátor" üzembe helyezésre való várakozás hibával. Ha a Sync-AksHciBilling parancsot futtatja, az sikeres kimenetet ad vissza. Ha azonban a Get-AksHciBillingStatus parancsot futtatja, a kapcsolat állapota OutofPolicy.

Ha 60 napja nem telepített számításifeladat-fürtöt, a számlázás nem lesz érvényes.

A probléma megoldásának egyetlen módja a tiszta telepítéssel történő ismételt üzembe helyezés.

A virtuális hálózati adapter a gép újraindítása után eltűnik

Megjegyzés

Ezt a problémát a 2022. májusi és újabb kiadásokban javítottuk.

Ha az Azure Stack HCI-csomópontok egymás után újraindulnak, egyes virtuális gépek elveszítik a hozzájuk csatolt virtuális hálózati adaptereket. A virtuális hálózati adapterek elvesztése miatt a virtuális gépek elveszítik a hálózati kapcsolatot, és a fürt rossz állapotba kerül.

Reprodukálás

  1. Indítsa újra az egyik Azure Stack HCI-csomópontot.
  2. Várja meg, amíg a csomópont befejezi az újraindítást. A csomópontot meg kell jelölni Up a feladatátvevő fürtben.
  3. Indítsa újra a többi csomópontot.
  4. Ismételje meg.

Várt viselkedés A fürt állapotának kifogástalannak kell lennie. Minden virtuális géphez hálózati adaptereket kell csatlakoztatni.

A probléma megoldásához az MOC-parancsokkal adja hozzá a virtuális hálózati adaptert a virtuális géphez.

  1. Kérje le a virtuális gép virtuális hálózati adapterének nevét.
(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

vagy

mocctl.exe compute vm get --name <vmname> --group <group>
  1. Csatlakoztassa a virtuális hálózati adaptert a virtuális géphez.
Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

vagy

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>
  1. Ha a vNIC connect parancsa sikertelen, próbálkozzon a kapcsolat bontásával, és csatlakozzon újra. A vNIC leválasztását az alábbi parancs követi.
Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

vagy

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Az üzemelő példányok frissítésekor előfordulhat, hogy egyes podok elakadnak a "statikus podok kész állapotra való várakozásánál"

A podok elakadtak, amikor arra vártak, hogy a statikus podok kész állapotba lépjenek.

A podok felszabadításához és a probléma megoldásához indítsa újra a kubeletet. A NotReady csomópont statikus podokkal való megtekintéséhez futtassa a következő parancsot:

kubectl get nodes -o wide

A hibás csomópontra vonatkozó további információkért futtassa a következő parancsot:

kubectl describe node <IP of the node>

Az SSH használatával jelentkezzen be a NotReady csomópontba a következő parancs futtatásával:

ssh -i <path of the private key file> administrator@<IP of the node>

Ezután a kubelet újraindításához futtassa a következő parancsot:

/etc/.../kubelet restart

Frissítés futtatásakor a következő hibaüzenet jelenik meg: "Hiba történt a platformfrissítési információk lekérése közben"

Frissítés futtatásakor Windows Admin Center a következő hiba történt:

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

Ez a hibaüzenet általában akkor fordul elő, ha az Azure Stack HCI-n futó AKS egy proxyval konfigurált környezetben van üzembe helyezve. Jelenleg Windows Admin Center nem támogatja a modulok proxykörnyezetben való telepítését.

A hiba elhárításához állítsa be az AKS-t az Azure Stack HCI-ben a proxy PowerShell-paranccsal.

Amikor egy Kubernetes-fürtöt open policy-ügynökkel frissít, a frissítési folyamat lefagy

Amikor a Kubernetes-fürtöket open Policy Agent (OPA) használatával frissíti, például az OPA GateKeeperrel, előfordulhat, hogy a folyamat lefagy, és nem fejeződik be. Ez a probléma azért fordulhat elő, mert a szabályzatügynök úgy van konfigurálva, hogy megakadályozza a tárolórendszerképek magánregisztrációs adatbázisokból való lekérését.

A probléma megoldásához, ha OPA-val üzembe helyezett fürtöket frissít, győződjön meg arról, hogy a szabályzatok lehetővé teszik a rendszerképek lekérését Azure Container Registry. Az Azure Stack HCI-n futó AKS-frissítéshez a következő végpontot kell hozzáadnia a szabályzat listájához: ecpacr.azurecr.io.

A gazdagép OS HCI-jének HCIv2-be való frissítése megszakítja az AKS-t az Azure Stack HCI-telepítésen: OutOfCapacity

Ha az Azure Stack HCI-n futó AKS-sel rendelkező gazdagépen futtat egy operációsrendszer-frissítést, az azt okozhatja, hogy az üzembe helyezés rossz állapotba kerül, és a második napon meghiúsul. Előfordulhat, hogy az MOC NodeAgent Services nem indul el a frissített gazdagépeken. A csomópontokra irányuló MOC-hívások sikertelenek.

Megjegyzés

Ez a probléma csak alkalmanként fordul elő.

Reprodukálás: Ha egy meglévő AKS-telepítéssel rendelkező fürtöt frissít HCI-ről HCIv2-re, egy AKS-művelet, például New-AksHciCluster sikertelen lehet. A hibaüzenet szerint az MOC-csomópontok OutOfCapacity típusúak. Például:

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

A probléma megoldásához indítsa el a wssdagent Moc NodeAgent szolgáltatást az érintett csomópontokon. Ez megoldja a problémát, és jó állapotba hozza az üzembe helyezést. Futtassa az alábbi parancsot:

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

A célfürt frissítése elakad egy vagy több csomóponttal egy régi Kubernetes-verzióban

Az Update-AksHciCluster futtatása után a frissítési folyamat leáll.

Futtassa a következő parancsot annak ellenőrzéséhez, hogy van-e törléssel rendelkező PHASE gép, amely a korábbi Kubernetes-verziót futtatja, amelyről frissít.

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

Ha van olyan gép, amely törléssel PHASE rendelkezik, és VERSION megfelel az előző Kubernetes-verziónak, folytassa az alábbi lépésekkel.

A probléma megoldásához a következő információkra van szüksége:

  1. Kubernetes-verzió, amelyre frissíti a számításifeladat-fürtöt.
  2. A elakadt csomópont IP-címe.

Az információk megkereséséhez futtassa az alábbi parancsmagot és parancsot. Alapértelmezés szerint a parancsmag Get-AksHciCredential a kubeconfigot ~/.kube/configa következőre írja: . Ha a híváskor Get-AksHciCredentialmásik helyet ad meg a számítási feladatfürt kubeconfigjához, ezt a helyet meg kell adnia a kubectl számára egy másik argumentumként. Például: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

A javítandó csomópontnak meg kell jelennie STATUSReady,SchedulingDisabled. Ha ilyen állapotú csomópontot lát, használja ennek a csomópontnak az INTERNAL-IP IP-cím értékét az alábbi parancsban. Használja azt a Kubernetes-verziót, amelyre verzióértékként frissít; ennek meg kell egyeznie a VERSION csomópont értékével.ROLEScontrol-plane,master Mindenképpen adja meg a Kubernetes-verzió teljes értékét, beleértve például v1.22.6a vértéket is.

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Az ssh-parancs futtatása után a régi Kubernetes-verzióval rendelkező többi csomópontot törölni kell, és a frissítés folytatódik.

A gazdagép OS HCI-jének HCIv2-be való frissítése megszakítja az AKS-t az Azure Stack HCI-telepítésen: Nem érhető el a felügyeleti fürt

Ha az Azure Stack HCI-n futó AKS-sel rendelkező gazdagépen futtat egy operációsrendszer-frissítést, az azt okozhatja, hogy az üzembe helyezés hibás állapotba kerül, ami elérhetetlenné teszi a felügyeleti fürt API-kiszolgálóját, és a második napon meghiúsul. A kube-vip pod nem tudja alkalmazni a VIRTUÁLIS IP-konfigurációt az adapterre, ezért a VIRTUÁLIS IP-cím nem érhető el.

Reprodukálás: Frissítsen egy fürtöt egy meglévő AKS HCI-telepítéssel HCI-ről HCIv2-re. Ezután próbálkozzon olyan parancsok futtatásával, amelyek megpróbálják elérni a felügyeleti fürtöt, például Get-AksHciCluster: . A felügyeleti fürt elérésére tett minden művelet meghiúsul, például:

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

A probléma megoldásához indítsa újra a tárolót kube-vip , hogy az üzembe helyezés ismét megfelelő állapotba kerüljön.

  1. A tárolóazonosító lekérése kube-vip :
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

A kimenetnek így kell kinéznie, és a tárolóazonosító az első érték 4a49a5158a5f8. Például:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55
  1. Indítsa újra a tároló újraindítását:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Az Update-AksHci futtatásakor a frissítési folyamat elakadt az "AksHci számlázási operátor üzembe helyezésére várva"

Ez az állapotüzenet az Update-AksHci PowerShell-parancsmag futtatásakor jelenik meg.

Tekintse át a probléma megoldásának következő kiváltó okait:

  • Első ok: Az AksHci számlázási operátor frissítése során az operátor helytelenül jelölte meg magát a szabályzaton kívülre. A probléma megoldásához nyisson meg egy új PowerShell-ablakot, és futtassa a Sync-AksHciBilling parancsot. Látnia kell, hogy a számlázási művelet a következő 20-30 percen belül folytatódik.

  • Második ok: Előfordulhat, hogy a felügyeleti fürt virtuális gépe nem rendelkezik memóriával, ami miatt az API-kiszolgáló elérhetetlenné válik, és időtúllépést okoz a Get-AksHciClustertől, a számlázástól és a frissítéstől. Áthidaló megoldásként állítsa a felügyeleti fürt virtuális gépét 32 GB-ra a Hyper-V-ben, majd indítsa újra.

  • Harmadik ok: Előfordulhat, hogy az AksHci számlázási operátor nem rendelkezik tárterülettel, ami a Microsoft SQL konfigurációs beállításainak hibája miatt fordulhat elő. Előfordulhat, hogy a tárolóterület hiánya miatt a frissítés nem válaszol. A probléma megkerüléséhez az alábbi lépések végrehajtásával méretezze át manuálisan a számlázási podot pvc .

    1. Futtassa a következő parancsot a podbeállítások szerkesztéséhez:

      kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      
    2. Amikor megnyílik egy YAML-fájllal a Jegyzettömb vagy egy másik szerkesztő, szerkessze a tárterület sorát 100Mi-ről 5Gi-ra:

      spec:
        resources:
          requests:
            **storage: 5Gi**
      
    3. Ellenőrizze a számlázási üzembe helyezés állapotát a következő paranccsal:

      kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      

Amikor az AKS-t az Azure Stack HCI-n frissíti a 2022. februári frissítésről 2022. áprilisi frissítésre, a CSI üzembe helyezése eltűnik, és a frissítés elakadását okozza

Amikor a fürtöket az Azure Stack HCI 2022. februári frissítéséről a 2022. áprilisi frissítésre frissíti, előfordulhat, hogy a frissítés határozatlan ideig nem frissül. Előfordulhat, hogy a podok vagy az TerminatingCrashLoopBackoff állapotban ragadnak.

Előfordulhat, hogy az AksHci CSI-bővítmény egyes erőforrásai hiányoznak. Ezek az erőforrás-podok a vagy a csi-akshcicsi-controllercsi-akshcicsi-node démonkészlet használatával vannak üzembe helyezve.

A 2022. februári frissítésben az AksHci CSI-bővítmény módosította a CSI illesztőprogram-specifikációját, amely néha a frissítés során nem válaszoló állapotban hagyhatja a bővítmény erőforrásait. A CSI-illesztő .spec.fsGroupPolicy új értékre lett beállítva, annak ellenére, hogy nem módosítható mező. Mivel a mező nem módosítható, az illesztőprogram-specifikáció nem frissül. Ennek az a következménye, hogy előfordulhat, hogy a többi AksHci CSI-bővítmény erőforrásai nem lesznek teljes mértékben egyeztetve. Az összes CSI-erőforrás újra létre lesz hozva.

A probléma manuális megoldásához a CSI-illesztő manuálisan törölhető. Miután eltávolította, a felhőszolgáltató 10 percen belül egyezteti az AksHci CSI-bővítményt, és újra létrehozza az illesztőprogramot a hiányzó bővítmény-erőforrásokkal együtt.

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

Windows Admin Center frissítési irányítópult nem frissül a sikeres frissítések után

A sikeres frissítés után az Windows Admin Center frissítési irányítópult továbbra is az előző verziót jeleníti meg.

A hálózati mezőnevek inkonzisztensek a WAC-portálon.

Frissítse a böngészőt a probléma megoldásához.

Ha a PowerShellt használja a frissítéshez, a rendszer túl sok Kubernetes-konfigurációs titkos kódot hoz létre egy fürtön

Az Azure Stack HCI-n futó AKS június 1.0.1.10628-as buildje túl sok Kubernetes-konfigurációs titkos kódot hoz létre a fürtben. A június 1.0.1.10628-ról a július 1.0.2.10723-ra szóló kiadás frissítési útvonalát továbbfejlesztettük a Kubernetes további titkos kulcsainak eltávolításához. Bizonyos esetekben azonban a frissítés során a titkos kódok még mindig nem lettek megtisztítva, ezért a frissítési folyamat meghiúsul.

Ha ezt a problémát tapasztalja, futtassa az alábbi lépéseket:

  1. Mentse az alábbi szkriptet egy fix_leaked_secrets.ps1nevű fájlként:

    upgparam (
    [Parameter(Mandatory=$true)]
    [string] $ClusterName,
    [Parameter(Mandatory=$true)]
    [string] $ManagementKubeConfigPath
    )
    
    $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
    "Hostname is: $ControlPlaneHostName"
    
    $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
    $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
    $leakedSecretPath3 = "$ClusterName-kube-vip"
    $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
    $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
    $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
    
    $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
    $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
    
    foreach ($leakedSecretName in $leakedSecretNameList)
    {
    "Deleting secrets with the prefix $leakedSecretName"
    $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
    "Deleted: $output"
    }
    
  2. Ezután futtassa a következő parancsot a mentett fix_secret_leak.ps1 fájllal:

       .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
    
  3. Végül a következő PowerShell-paranccsal ismételje meg a frissítési folyamatot:

       Update-AksHci
    

Következő lépések

Ha továbbra is problémákba ütközik az AKS Arc használatakor, a GitHubon keresztül is beküldheti a hibákat.