Düzenle

Aracılığıyla paylaş


AKS Arc'ın yükseltilmesiyle ilgili sorunları çözme

Bu makalede, Azure Kubernetes Service (AKS) Arc dağıtımlarını en yeni sürüme yükseltirken karşılaşabileceğiniz bilinen sorunlar ve hatalar açıklanmaktadır. Ayrıca Windows Yönetim Merkezi ile ilgili bilinen sorunları ve Azure Stack HCI'ye AKS'yi yüklerken de gözden geçirebilirsiniz.

Başarılı bir yükseltmeden sonra PowerShell'in eski sürümleri kaldırılmaz

PowerShell'in eski sürümleri kaldırılmaz.

Bu sorunu geçici olarak çözmek için bu betiği çalıştırarak eski PowerShell sürümlerini kaldırabilirsiniz.

Sertifika yenileme podu kilitlenme döngüsü durumunda

Hedef kümeyi yükselttikten veya ölçeklendirdikten sonra sertifika yenileme podu artık kilitlenme döngüsü durumundadır. Yolundan /etc/Kubernetes/pkibir sertifika dövme yaml dosyası bekliyor. Yapılandırma dosyası denetim düzlemi düğümü VM'lerinde bulunur ancak çalışan düğümü VM'lerinde yoktur.

Not

Bu sorun Nisan 2022 sürümünden sonra düzeltildi.

Bu sorunu çözmek için denetim düzlemi düğümündeki sertifika dövme dosyasını çalışan düğümlerinin her birine el ile kopyalayın.

  1. Dosyayı denetim düzlemi VM'sinden konak makinenizin geçerli dizinine kopyalayın.

    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. Dosyayı konak makinesinden çalışan düğümü VM'sine kopyalayın.

    scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
    
  3. Bu dosyadaki sahip ve grup bilgilerini kök olarak ayarlamadıysa kök olarak ayarlayın.

    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. Çalışan düğümlerinizin her biri için 2. ve 3. adımları yineleyin.

Küme 60 günden uzun süre yükseltilmediğinde süresi dolan belirteç nedeniyle cloudagent'a katılamadığında nodeagent bağlantı noktalarını sızdırıyor

Bir küme 60 günden uzun bir süredir yükseltilmediğinde, belirteç süresinin dolması nedeniyle düğüm aracısı yeniden başlatma sırasında başlatılamaz. Bu hata, aracıların başlangıç aşamasında olmasını neden olur. Cloudagent'a sürekli katılma girişimleri, konak üzerindeki bağlantı noktalarının kaynağını tüketebilir. Aşağıdaki komutun durumu Başlatılıyor şeklindedir.

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

Beklenen davranış: Düğüm aracısı, bulut aracısına sürekli katılmayı deneyerek bağlantı noktalarını tüketen başlangıç aşamasında olmalıdır.

Sorunu çözmek için wssdagent'ın çalışmasını durdurun. Hizmet başlangıç aşamasında olduğundan, hizmeti durdurmanızı engelleyebilir. Bu durumda, hizmeti durdurmayı denemeden önce işlemi sonlandırın.

  1. wssdagent'ın başlangıç aşamasında olduğunu onaylayın.

    Get-Service wssdagent | Select-Object -Property Name, Status
    
  2. İşlemi sonlandırın.

    kill -Name wssdagent -Force
    
  3. Hizmeti durdurun.

    Stop-Service wssdagent -Force
    

Not

Hizmeti durdurduktan sonra bile, durdurmadan önce wssdagent işlemi birkaç saniye içinde birkaç kez başlatılmış gibi görünür. Sonraki adıma geçmeden önce aşağıdaki komutun tüm düğümlerde bir hata döndürdüğünden emin olun.

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. Bu sorunu olan HCI kümesinin her düğümünde 1, 2 ve 3. adımları yineleyin.

  2. wssdagent'ın çalışmadığını onayladıktan sonra, çalışmıyorsa cloudagent'ı başlatın.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName
  1. Cloudagent'ın çalışır durumda olduğunu onaylayın.

    Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
    
  2. wssdagent'ı düzeltmek için aşağıdaki komutu çalıştırın:

    Repair-Moc
    
  3. Bu komut tamamlandıktan sonra wssdagent çalışır durumda olmalıdır.

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

Yükseltme hatasından sonra MOC aracıları başlatılamıyor

AKS-HCI Mayıs sürümünden Haziran sürümüne yükseltemediğinde, AKS-HCI'nin Mayıs sürümüne geri dönmeli ve çalışmaya devam etmelidir. Ancak MOC aracılarını durdurulmuş durumda bırakır ve aracıyı el ile başlatma girişimleri bunları etkinleştirmez.

Not

Bu sorun yalnızca Mayıs sürümünden Haziran sürümüne yükseltilirken geçerlidir.

Yeniden oluşturma adımları

  1. AKS-HCI PowerShell modülünün 1.1.36 sürümünü yükleyin.
  2. AKS-HCI'yi yükseltin. Yükseltme başarısız olursa AKS-HCI Mayıs'a geri döner, ancak MOC aracıları devre dışı kalır.

Beklenen davranış

Aks-Hci yükseltmesi başarısız olursa, beklenti AksHci'nin önceki sürüme geri dönerek sorunsuz çalışmaya devam etmesidir.

Belirtiler

Aks-Hci sürümü ile MOC sürümü arasındaki uyuşmazlık

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

Get-MocVersion ile wssdcloudagent.exe sürümü arasındaki uyuşmazlık

Get-MocVersion Haziran derlemesinin yüklü olduğunu, wssdcloudagent.exe sürümü ise Mayıs derlemesinin yüklü olduğunu gösterir.

MOC aracı hizmetleri görüntü yolunda dağıtım kimliği parametresi var

Bulut aracısının görüntü yolunu göstermek için aşağıdaki komutu çalıştırın:

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

Örnek çıkış

"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"

Düğüm aracısının görüntü yolunu göstermek için aşağıdaki komutu kullanın: "HKLM\System\CurrentControlSet\Services\wssdagent" reg sorgusu

Örnek çıkış

"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"

Sorunu azaltmak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

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'

Yükseltme sırasında özel düğüm renk tonları, roller ve etiketler kaybolur

Yükseltme sırasında, çalışan düğümlerinize eklediğiniz tüm özel renk tonlarını, rolleri ve etiketleri kaybedebilirsiniz. AKS yönetilen bir hizmet olduğundan, sağlanan PowerShell cmdlet'leri veya Windows Yönetim Merkezi dışında gerçekleştirildiğinde özel renk tonları, etiketler ve roller eklenmesi desteklenmez.

Bu sorunu geçici olarak çözmek için New-AksHciNodePool cmdlet'ini çalıştırarak çalışan düğümleriniz için taint'lerle doğru bir düğüm havuzu oluşturun.

60 gündür bir iş yükü kümesi oluşturulmadıysa AKS Arc ilke dışı bırakılır

Bir yönetim kümesi oluşturduysanız ancak ilk 60 gün içinde bir iş yükü kümesi dağıtmadıysanız, artık ilke dışı olduğundan bu kümeyi oluşturmanız engellenir. Bu durumda, Update-AksHci'yi çalıştırdığınızda güncelleştirme işlemi 'AksHci Faturalama İşleci' dağıtımının hazır olması bekleniyor hatasıyla engellenir. Sync-AksHciBilling çalıştırırsanız, başarılı bir çıkış döndürür. Ancak Get-AksHciBillingStatus çalıştırırsanız bağlantı durumu OutofPolicy olur.

60 gündür bir iş yükü kümesi dağıtmadıysanız faturalama ilke dışı bırakılır.

Bu sorunu düzeltmenin tek yolu temiz bir yüklemeyle yeniden dağıtmaktır.

Makine yeniden başlatıldıktan sonra vNIC kayboluyor

Not

Bu sorun Mayıs 2022 ve sonraki sürümlerde düzeltilmiştir.

Azure Stack HCI düğümleri birbiri ardına yeniden başlatılırsa, bazı sanal makineler bunlara bağlı vNIC'leri kaybeder. Bu vNIC kaybı VM'lerin ağ bağlantısını kaybetmesine ve kümenin kötü bir duruma düşmesine neden olur.

Yeniden Oluşturmak için

  1. Bir Azure Stack HCI düğümünü yeniden başlatın.
  2. Düğümün yeniden başlatmayı tamamlanmasını bekleyin. Düğümün yük devretme kümesinde işaretlenmesi Up gerekir.
  3. Diğer düğümleri yeniden başlatın.
  4. Tekrarlayın.

Beklenen davranış Küme durumunun iyi durumda olması gerekir. Tüm VM'lerde NIC'ler eklenmelidir.

Sorunu çözmek için vm'ye vNIC eklemek için MOC komutlarını kullanın.

  1. VM için vNIC adını alın.
(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

veya

mocctl.exe compute vm get --name <vmname> --group <group>
  1. vNIC'yi VM'ye bağlayın.
Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

veya

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>
  1. vNIC connect komutu başarısız olursa bağlantıyı kesmeyi ve yeniden bağlanmayı deneyin. vNIC bağlantısını kesme komutu aşağıdadır.
Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

veya

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

Bir dağıtımı yükseltirken, bazı podlar 'statik podların hazır bir koşula sahip olmasını beklerken' takılabilir

Podlar, statik podların hazır bir koşula sahip olmasını beklerken takıldı.

Podları serbest bırakmak ve bu sorunu çözmek için kubelet'i yeniden başlatmanız gerekir. Statik podlarla NotReady düğümünü görüntülemek için aşağıdaki komutu çalıştırın:

kubectl get nodes -o wide

Hatalı düğüm hakkında daha fazla bilgi edinmek için aşağıdaki komutu çalıştırın:

kubectl describe node <IP of the node>

Aşağıdaki komutu çalıştırarak NotReady düğümünde oturum açmak için SSH kullanın:

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

Ardından kubelet'i yeniden başlatmak için aşağıdaki komutu çalıştırın:

/etc/.../kubelet restart

Yükseltmenin çalıştırılması şu hatayla sonuçlanır: 'Platform yükseltme bilgileri getirilirken hata oluştu'

Windows Yönetim Merkezi'nde yükseltme çalıştırılırken aşağıdaki hata oluştu:

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.

Bu hata iletisi genellikle Azure Stack HCI üzerinde AKS, ara sunucu yapılandırılmış bir ortama dağıtıldığında oluşur. Şu anda, Windows Yönetim Merkezi'nin bir ara sunucu ortamına modül yükleme desteği yoktur.

Bu hatayı düzeltmek için proxy PowerShell komutunu kullanarak Azure Stack HCI üzerinde AKS'yi ayarlayın.

Bir Kubernetes kümesini Açık İlke Aracısı ile yükseltirken yükseltme işlemi kilitleniyor

OPA GateKeeper gibi bir Açık İlke Aracısı (OPA) ile Kubernetes kümelerini yükseltirken işlem kilitlenebilir ve tamamlanamayabilir. Bu sorun, ilke aracısı özel kayıt defterlerinden kapsayıcı görüntülerinin çekilmesini engelleyecek şekilde yapılandırıldığından oluşabilir.

Bu sorunu çözmek için, OPA ile dağıtılan kümeleri yükseltiyorsanız, ilkelerinizin Azure Container Registry'den görüntü çekmeye izin verin. Azure Stack HCI'deki bir AKS yükseltmesi için ilkenizin listesine şu uç noktayı eklemeniz gerekir: ecpacr.azurecr.io.

Konak işletim sistemi HCI'sinin HCIv2'ye güncelleştirilmesinde Azure Stack HCI yüklemesinde AKS kesintisi: OutOfCapacity

Azure Stack HCI dağıtımında AKS ile bir konakta işletim sistemi güncelleştirmesi çalıştırmak, dağıtımın hatalı bir duruma girmesine ve ikinci gün işlemlerinin başarısız olmasına neden olabilir. MOC NodeAgent Services güncelleştirilmiş konaklarda başlatılamıyor olabilir. Düğümlere yapılan tüm MOC çağrıları başarısız olur.

Not

Bu sorun yalnızca zaman zaman gerçekleşir.

Yeniden oluşturmak için: Bir kümeyi HCI'den HCIv2'ye var olan bir AKS dağıtımıyla güncelleştirdiğinizde, gibi New-AksHciCluster bir AKS işlemi başarısız olabilir. Hata iletisi, MOC düğümlerinin OutOfCapacity olduğunu belirtir. Örneğin:

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]

Bu sorunu çözmek için etkilenen düğümlerde wssdagent Moc NodeAgent Hizmetini başlatın. Bu işlem sorunu çözer ve dağıtımı yeniden iyi bir duruma getirir. Şu komutu çalıştırın:

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

Hedef küme yükseltmesi eski bir Kubernetes sürümünde bir veya daha fazla düğümle takılıyor

Update-AksHciCluster çalıştırıldıktan sonra yükseltme işlemi durur.

Yükseltme yaptığınız önceki Kubernetes sürümünü çalıştıran, Silme özelliğine sahip PHASE bir makine olup olmadığını denetlemek için aşağıdaki komutu çalıştırın.

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

Silme ve VERSION önceki Kubernetes sürümüyle PHASE eşleşen bir makine varsa aşağıdaki adımlarla devam edin.

Bu sorunu gidermek için aşağıdaki bilgi parçalarına ihtiyacınız vardır:

  1. İş yükü kümenizi yükselttiğiniz Kubernetes sürümü.
  2. Takılan düğümün IP adresi.

Bu bilgileri bulmak için aşağıdaki cmdlet'i ve komutu çalıştırın. Varsayılan olarak, cmdlet Get-AksHciCredential kubeconfig öğesini öğesine ~/.kube/configyazar. çağrısı Get-AksHciCredentialyaparken iş yükü kümeniz kubeconfig için farklı bir konum belirtirseniz, bu konumu kubectl'ye başka bir bağımsız değişken olarak sağlamanız gerekir. Örneğin, kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Düzeltilmesi gereken düğümde gösterilmelidir STATUS Ready,SchedulingDisabled. Bu duruma sahip bir düğüm görürseniz aşağıdaki komutta INTERNAL-IP BU düğümün IP adresi değerini kullanın. Sürüm değeri olarak yükselttiğiniz Kubernetes sürümünü kullanın; bu, ile düğümdeki değerle ROLES control-plane,mastereşleşmelidirVERSION. Kubernetes sürümünün tam değerini eklediğinizden vemin olun; örneğin v1.22.6, .

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

Bu ssh komutu çalıştırıldıktan sonra, eski Kubernetes sürümüne sahip kalan düğümler silinmelidir ve yükseltme devam edecektir.

Konak işletim sistemi HCI'sinin HCIv2'ye güncelleştirilmesinde Azure Stack HCI yüklemesinde AKS bozuluyor: Yönetim kümesine ulaşılamıyor

Azure Stack HCI dağıtımında AKS ile bir konakta işletim sistemi güncelleştirmesi çalıştırmak, dağıtımın hatalı bir duruma girmesine neden olabilir ve bu da yönetim kümesinin API sunucusuna ulaşılamaz hale gelir ve iki gün süren işlemlerde başarısız olur. Pod kube-vip , arabirime VIP yapılandırmasını uygulayamaz ve sonuç olarak VIP'ye ulaşılamaz.

Yeniden oluşturmak için: Bir kümeyi HCI'den HCIv2'ye var olan bir AKS HCI dağıtımıyla güncelleştirin. Ardından gibi Get-AksHciClusteryönetim kümesine erişmeye çalışan komutları çalıştırmayı deneyin. Yönetim kümesine erişmeye çalışan tüm işlemler aşağıdaki gibi hatalarla başarısız olur:

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)]

Bu sorunu çözmek için: dağıtımı yeniden iyi duruma getirmek için kapsayıcıyı yeniden başlatın kube-vip .

  1. kube-vip Kapsayıcı kimliğini alın:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

Çıkış, kapsayıcı kimliği ilk değer 4a49a5158a5f8olacak şekilde şuna benzer görünmelidir. Örneğin:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55
  1. Kapsayıcıyı yeniden başlatın:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Update-AksHci çalıştırılırken güncelleştirme işlemi 'AksHci Faturalama operatörü' dağıtımının hazır olması beklenirken' takıldı

Update-AksHci PowerShell cmdlet'i çalıştırılırken bu durum iletisi görüntülenir.

Sorunu çözmek için aşağıdaki kök nedenleri gözden geçirin:

  • Birinci neden: AksHci Faturalama İşleci'nin güncelleştirildiği sırada, işleç kendisini hatalı bir şekilde ilke dışı olarak işaretledi. Bu sorunu çözmek için yeni bir PowerShell penceresi açın ve Sync-AksHciBilling komutunu çalıştırın. Faturalama işleminin sonraki 20-30 dakika içinde devam etmesi gerekir.

  • İkinci neden: Yönetim kümesi VM'sinin belleği yetersiz olabilir; bu da API sunucusuna ulaşılamayabilir ve Get-AksHciCluster, faturalama ve güncelleştirme, zaman aşımı gibi tüm komutları yapar. Geçici bir çözüm olarak, Hyper-V'de yönetim kümesi VM'sini 32 GB olarak ayarlayın ve yeniden başlatın.

  • Üçüncü neden: AksHci Faturalama İşleci depolama alanı dışında olabilir ve bunun nedeni Microsoft SQL yapılandırma ayarlarındaki bir hatadır. Depolama alanı olmaması yükseltmenin yanıt vermeyi durdurmasına neden olabilir. Bu sorunu geçici olarak çözmek için aşağıdaki adımları kullanarak faturalama podunu pvc el ile yeniden boyutlandırın.

    1. Pod ayarlarını düzenlemek için aşağıdaki komutu çalıştırın:

      kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      
    2. YaML dosyasıyla Birlikte Not Defteri veya başka bir düzenleyici açıldığında, depolama satırını 100Mi ile 5Gi arasını düzenleyin:

      spec:
        resources:
          requests:
            **storage: 5Gi**
      
    3. Aşağıdaki komutu kullanarak faturalama dağıtımının durumunu denetleyin:

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

Azure Stack HCI üzerinde AKS'yi Şubat 2022 Güncelleştirmesi'nden Nisan 2022 Güncelleştirmesi'ne yükseltirken, CSI dağıtımı kaybolur ve yükseltmenin durmasına neden olur

Azure Stack HCI Şubat 2022 Güncelleştirmesi'ndeki AKS'den Nisan 2022 Güncelleştirmesi'ne kümeleri yükselttiğinizde, güncelleştirme süresiz olarak yükseltirken takılmış olabilir. veya CrashLoopBackoff durumunda takılmış Terminating podlar olabilir.

AksHci CSI eklenti kaynaklarından bazılarının eksik olduğunu görebilirsiniz. Daemonset'ten csi-akshcicsi-node veya kullanılarak csi-akshcicsi-controller dağıtılan bu kaynaklar podları.

Şubat 2022 Güncelleştirmesi'ndeki AksHci CSI eklentisi, yükseltme sırasında eklentinin kaynaklarını bazen yanıt vermeyen bir durumda bırakabilen CSI sürücü belirtiminde bir değişiklik içeriyordu. Sabit bir alan olmasına rağmen CSI sürücüsünün .spec.fsGroupPolicy değeri yeni bir değere ayarlanmıştır. Alan sabit olduğundan, sürücü belirtimi güncelleştirilmez. Bunun bir sonucu, diğer AksHci CSI eklenti kaynaklarının tam olarak uzlaştırılmamasıdır. Tüm CSI kaynakları yeniden oluşturulur.

Sorunu el ile çözmek için CSI sürücüsü el ile silinebilir. Bunu kaldırdıktan sonra, bulut operatörü 10 dakika içinde AksHci CSI eklentisini mutabık tutar ve eksik eklenti kaynaklarının geri kalanıyla birlikte sürücüyü yeniden oluşturur.

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

Başarılı güncelleştirmeler sonrasında Windows Admin Center güncelleştirme panosu yenilenmiyor

Başarılı bir yükseltmeden sonra, Windows Admin Center güncelleştirme panosu hala önceki sürümü gösterir.

WAC portalında ağ alanı adları tutarsız.

Bu sorunu düzeltmek için tarayıcıyı yenileyin.

Yükseltmek için PowerShell kullanılırken, kümede fazla sayıda Kubernetes yapılandırma gizli dizileri oluşturulur

Azure Stack HCI üzerinde AKS'nin Haziran 1.0.1.10628 derlemesi, kümede fazla sayıda Kubernetes yapılandırma gizli dizisini oluşturur. Ek Kubernetes gizli dizilerini temizlemek için Haziran 1.0.1.10628 sürümünden Temmuz 1.0.2.10723 sürümüne yükseltme yolu geliştirildi. Ancak, yükseltme sırasında bazı durumlarda gizli diziler hala temizlenmedi ve bu nedenle yükseltme işlemi başarısız oldu.

Bu sorunla karşılaşırsanız aşağıdaki adımları çalıştırın:

  1. Aşağıdaki betiği fix_leaked_secrets.ps1 adlı bir dosya olarak kaydedin:

    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. Ardından, kaydettiğiniz fix_secret_leak.ps1 dosyasını kullanarak aşağıdaki komutu çalıştırın:

       .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
    
  3. Son olarak, yükseltme işlemini yinelemek için aşağıdaki PowerShell komutunu kullanın:

       Update-AksHci
    

Sonraki adımlar

AKS Arc kullanırken sorunlarla karşılaşırsanız GitHub aracılığıyla hata oluşturabilirsiniz.