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.
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 .\
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
Á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
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.
Ellenőrizze, hogy a wssdagent kezdő fázisban van-e.
Get-Service wssdagent | Select-Object -Property Name, Status
A folyamat leállítása.
kill -Name wssdagent -Force
Á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
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.
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
Ellenőrizze, hogy a cloudagent működik-e.
Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
Futtassa a következő parancsot a wssdagent javításához:
Repair-Moc
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
- Telepítse az AKS-HCI PowerShell-modul 1.1.36-os verzióját.
- 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.10513Get-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
- Indítsa újra az egyik Azure Stack HCI-csomópontot.
- 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. - Indítsa újra a többi csomópontot.
- 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.
- 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>
- 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>
- 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:
- Kubernetes-verzió, amelyre frissíti a számításifeladat-fürtöt.
- 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/config
a következőre írja: . Ha a híváskor Get-AksHciCredential
má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 STATUS
Ready,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.ROLES
control-plane,master
Mindenképpen adja meg a Kubernetes-verzió teljes értékét, beleértve például v1.22.6
a 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.
- 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
- 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
.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
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**
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 Terminating
CrashLoopBackoff
á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-controller
csi-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.
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:
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" }
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
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.