AKS Arc'ta Kubernetes yönetimi ve iş yükü kümesi sorunlarını giderme

Remove-ClusterNode komutu çalıştırılırken düğüm yük devretme kümesinden çıkarılır, ancak Remove-AksHciNode daha sonra çalıştırılamazsa, düğüm CloudAgent'da bulunmaya devam eder.

Düğüm kümeden kaldırıldığından ancak CloudAgent'dan kaldırılmadığından, yeni bir düğüm oluşturmak için VHD kullanırsanız bir "Dosya bulunamadı" hatası görüntülenir. Bu sorun, VHD paylaşılan depolama alanında olduğundan ve kaldırılan düğümün buna erişimi olmadığından oluşur.

Bu sorunu çözmek için, fiziksel düğümü kümeden kaldırın ve aşağıdaki adımları izleyin:

1. CloudAgent'dan düğümün kaydını kaldırmak için komutunu çalıştırın Remove-AksHciNode .
2. Makineyi yeniden görüntüleme gibi rutin bakımlar gerçekleştirin.
3. Düğümü kümeye geri ekleyin.
4. Düğümü CloudAgent'a kaydetmek için komutunu çalıştırın Add-AksHciNode .

Büyük kümelerde komut Get-AksHciLogs bir özel durum oluşturabilir, düğümleri numaralandıramaz veya c:\wssd\wssdlogs.zip çıkış dosyasını oluşturmaz.

Bunun nedeni, 'Compress-Archive' adlı bir dosyayı sıkıştırmak için PowerShell komutunun 2 GB çıkış dosyası boyutu sınırına sahip olmasıdır.

İş yükü kümesini yükselttikten veya ölçeklendirdikten sonra, pod dosya konumundan /etc/Kubernetes/pkisertifika dövme YAML dosyasını beklediğinden sertifika yenileme podu artık kilitlenme döngüsü durumundadır.

Bu sorun, denetim düzlemi VM'lerinde bulunan ancak çalışan düğümü VM'lerinde bulunmayan bir yapılandırma dosyasından kaynaklanıyor olabilir.

Bu sorunu çözmek için, sertifika dövme YAML dosyasını denetim düzlemi düğümünden tüm çalışan düğümlerine el ile kopyalayın.

1. YAML dosyasını iş yükü kümesindeki 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` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. YAML dosyasını konak makinesinden çalışan düğümü VM'sine kopyalayın. Dosyayı kopyalamadan önce YAML dosyasındaki makinenin adını kopyalamakta olduğunuz düğüm adıyla değiştirmeniz gerekir (bu, iş yükü kümesi denetim düzleminin düğüm adıdır).

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

3. YAML dosyasındaki sahip ve grup bilgileri henüz kök olarak ayarlı değilse, bilgileri 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 certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Tüm çalışan düğümleri için 2. ve 3. adımları yineleyin.

Aks-Hci PowerShell komutları Kubernetes düğümlerini oluşturmadan önce konak sunucusunda kullanılabilir belleği doğrulamaz. Bu sorun, başlatılmayan bellek tükenmesine ve sanal makinelere yol açabilir.

Bu hata şu anda düzgün bir şekilde işlenmemektedir ve dağıtım net bir hata iletisi olmadan yanıt vermeyi durduracaktır. Yanıt vermeyi durduran bir dağıtımınız varsa Olay Görüntüleyicisi açın ve VM'yi başlatmak için yeterli bellek olmadığını belirten Hyper-V ile ilgili bir hata iletisi olup olmadığını denetleyin.

Windows Yönetim Merkezi'nde AKS Arc yüklemesinin durumunu doğrulamak için Get-AksHciCluster çalıştırılırken çıkışta şu hata gösterilir: "1.0.3.10818 sürümüne sahip bir sürüm BULUNAMADı." Ancak Get-AksHciVersion çalıştırılırken aynı sürümün yüklü olduğu gösterildi. Bu hata derlemenin süresinin dolduğunu gösterir.

Bu sorunu çözmek için komutunu çalıştırın Uninstall-AksHcive ardından yeni bir AKS Arc derlemesi çalıştırın.

Vm'yi Azure Yerel kümesindeki bir düğümden (Düğüm B) başka bir düğüme (Düğüm B) taşımak için küme yönetim aracını kullanırken, VM yeni düğümde başlatılamaz. VM'yi özgün düğüme geri taşıdıktan sonra orada da başlatılamaz.

Bu sorun, ilk geçişi temizleme mantığının zaman uyumsuz olarak çalışması nedeniyle oluşur. Sonuç olarak Azure Kubernetes Service'in "VM konumunu güncelleştir" mantığı, A düğümündeki özgün Hyper-V'de VM'yi bulur ve kaydını silmek yerine siler.

Bu sorunu geçici olarak çözmek için VM'yi özgün düğüme geri taşımadan önce yeni düğümde başarıyla başlatıldığından emin olun.

PowerShell kullanarak statik IP adreslerine sahip bir küme oluştururken ve ardından iş yükü kümesindeki çalışan düğümlerinin sayısını artırmaya çalışırken, yükleme "denetim düzlemi sayısı 2'de, hala istenen durum bekliyor: 3" durumunda takılıyor. Belirli bir süre sonra başka bir hata iletisi görüntülenir: "Hata: koşulu beklerken zaman aşımına uğradı."

Get-AksHciCluster çalıştırıldığında, denetim düzlemi düğümlerinin oluşturulduğunu ve sağlandığını ve Hazır durumda olduğunu gösterdi. Ancak çalıştırıldığındakubectl get nodes, denetim düzlemi düğümlerinin oluşturulduğunu ancak sağlanmadığını ve Hazır durumda olmadığını gösterdi.

Bu hatayı alırsanız, OLUŞTURULAN düğümlere Hyper-V Yöneticisi veya PowerShell kullanılarak IP adreslerinin atandığını doğrulayın:

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

Ardından, havuzda daha fazla VM oluşturmak için yeterli IP adresi olduğundan emin olmak için ağ ayarlarını doğrulayın.

, Update-AksHciCertificates, ve Update-AksHciClusterCertificatesgibi Update-AksHcikomutlar ve yönetim kümesiyle tüm etkileşimler"Hata: Sunucuda oturum açmanız gerekir (Yetkisiz)" döndürebilir.

Kubeconfig dosyasının süresi dolduğunda bu hata oluşabilir. Süresinin dolup dolmadığını denetlemek için aşağıdaki betiği çalıştırın:

$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

Bu betik geçerli tarihten önceki bir tarihi görüntülerse kubeconfig dosyasının süresi dolmuş demektir.

Sorunu azaltmak için yönetim denetim düzlemi VM'sinin içindeki admin.conf dosyasını Azure Yerel konağına kopyalayın:

• Yönetim denetim düzlemi VM'sine SSH:

  • Yönetim denetim düzlemi VM IP'sini alın:

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

  • SSH içine:

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

• Dosyayı clouduser konumuna kopyalayın:

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

• Clouduser'a erişim verin:

  sudo chown clouduser:clouduser admin.conf
  

• [İsteğe bağlı] kubeconfig dosyasının yedeğini oluşturun:

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

• Dosyayı kopyalayın:

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

Hyper-V yöneticisini denetlediğinizde, yönetim kümesi için yüksek CPU ve bellek talepleri güvenle yoksayılabilir. Bunlar, iş yükü kümeleri sağlanırken işlem kaynağı kullanımında ani artışlarla ilgilidir.

Yönetim kümesi için bellek veya CPU boyutunun artırılması önemli bir gelişme göstermemiştir ve güvenle yoksayılabilir.

Bu adımları izlerseniz bu sorunu görürsünüz:

1. Kubernetes kümesi oluşturun.
2. Kümeyi ikiden fazla düğüme ölçeklendirin.
3. Aşağıdaki komutu çalıştırarak düğümü silin:

kubectl delete node <node-name>

4. Aşağıdaki komutu çalıştırarak düğümlerin listesini döndür:

kubectl get nodes

Kaldırılan düğüm çıkışta listelenmez. 5. Yönetim ayrıcalıklarıyla bir PowerShell penceresi açın ve aşağıdaki komutu çalıştırın:

get-vm

Kaldırılan düğüm listelenmeye devam ediyor.

Bu hata, sistemin düğümün eksik olduğunu algılamamasına neden olur ve bu nedenle yeni bir düğüm açılmaz.

Bir yönetim veya iş yükü kümesini 60 günden uzun süre kullanmazsanız sertifikaların süresi dolar ve AKS Arc'ı yükseltebilmeniz için önce bunları yenilemeniz gerekir. AKS kümesi 60 gün içinde yükseltilemediğinde KMS eklenti belirtecinin ve sertifikaların süresi 60 gün içinde dolar. Küme hala işlevseldir. Ancak, 60 günden fazla olduğundan, yükseltmek için Microsoft desteğini aramanız gerekir. Küme bu süre sonunda yeniden başlatılırsa, işlevsel olmayan bir durumda kalır.

Bu sorunu çözmek için aşağıdaki adımları çalıştırın:

1. Belirteci el ile döndürerek yönetim kümesi sertifikasını onarın ve ardından KMS eklentisini ve kapsayıcısını yeniden başlatın.
2. mocctl komutunu çalıştırarak Repair-MocLoginsertifikaları onarın.
3. Belirteci el ile döndürerek iş yükü kümesi sertifikalarını onarın ve ardından KMS eklentisini ve kapsayıcısını yeniden başlatın.

Azure Yerel dağıtımlarında iki AKS'nin IP adresi havuzları aynıysa veya çakışıyorsa iş yükü kümesi bulunamayabilir. İki AKS ana bilgisayarı dağıtır ve her ikisi için de aynı AksHciNetworkSetting yapılandırmayı kullanırsanız, API sunucusuna her iki kümede de aynı IP adresi atanacağı için PowerShell ve Windows Yönetim Merkezi iş yükü kümesini bulamaz ve çakışmaya neden olur.

Aldığınız hata iletisi aşağıda gösterilen örneğe benzer olacaktır.

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.

Büyük bir kümenin dağıtımı iki saat sonra zaman aşımına uğrar. Ancak bu statik bir zaman aşımıdır.

İşlem arka planda çalışırken bu zaman aşımı oluşumunu yoksayabilirsiniz. kubectl get nodes Kümenize erişmek ve ilerleme durumunu izlemek için komutunu kullanın.

Birkaç gün sonra Azure Yerel dağıtımında bir AKS'yi etkinleştirmeye çalışırken, Kubectl komutlarından hiçbirini yürütmedi. Anahtar Yönetim Merkezi (KMS) eklenti günlüğü hata iletisini 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 certificatesgörüntüledi.

API sunucusu çalışmıyorsa Repair-AksHciClusterCerts cmdlet'i başarısız olur. Azure Yerel'de AKS 60 veya daha fazla gün boyunca yükseltilmemişse, KMS eklentisini yeniden başlatmayı denediğinizde başlatılmaz. Bu hata, API sunucusunun başarısız olmasına da neden olur.

Bu sorunu çözmek için belirteci el ile döndürmeniz ve ardından API sunucusu yedeklemesini almak için KMS eklentisini ve kapsayıcısını yeniden başlatmanız gerekir. Bunu yapmak için aşağıdaki adımları çalıştırın:

1. Aşağıdaki komutu çalıştırarak belirteci döndürün:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Aşağıdaki komutu kullanarak belirteci VM'ye kopyalayın. ip Aşağıdaki komuttaki ayar AKS konağı denetim düzleminin IP adresini ifade eder.

   $ 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. KMS eklentisini ve kapsayıcıyı yeniden başlatın.

   Kapsayıcı kimliğini almak için aşağıdaki komutu çalıştırın:

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

   Çıktı aşağıdaki alanlarla görünmelidir:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Çıktı şu örneğe benzer görünmelidir:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Son olarak, aşağıdaki komutu çalıştırarak kapsayıcıyı yeniden başlatın:

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

Windows Admin Center uzantısı sürüm 1.82.0 ile Azure Yerel'de bir AKS yüklemesinde, yönetim kümesi PowerShell kullanılarak ayarlandı ve Windows Admin Center kullanılarak bir iş yükü kümesi dağıtma girişiminde bulunuldu. Makinelerden birinde PowerShell modülü sürüm 1.0.2 yüklü, diğer makinelerde ise PowerShell modülü 1.1.3 yüklüdür. İş yükü kümesini dağıtma girişimi "'nodePoolName' parametre adıyla eşleşen bir parametre bulunamadı" hatasıyla başarısız oldu. Bu hata, sürüm uyuşmazlığı nedeniyle oluşmuş olabilir. PowerShell sürüm 1.1.0'dan başlayarak, -nodePoolName <String> parametresi New-AksHciCluster cmdlet'ine eklendi ve tasarım gereği, Windows Admin Center uzantısı sürüm 1.82.0 kullanılırken bu parametre artık zorunludur.

Bu sorunu çözümlemek için, aşağıdakilerden birini yapın:

• İş yükü kümesini 1.1.0 veya sonraki bir sürüme el ile güncelleştirmek için PowerShell'i kullanın.
• Kümeyi 1.1.0 sürümüne veya en son PowerShell sürümüne güncelleştirmek için Windows Admin Center'ı kullanın.

En son PowerShell modülleri yüklü olduğundan, yönetim kümesi Windows Yönetim Merkezi kullanılarak dağıtılırsa bu sorun oluşmaz.

Azure Yerel'de AKS'yi dağıtıp çalıştırdığınızdakubectl get pods, aynı düğümdeki podlar Sonlandırılıyor durumunda takılır. Düğüm büyük olasılıkla yüksek bellek talebiyle karşılaştığından makine SSH bağlantılarını reddeder. Bu sorun, Windows düğümlerinin aşırı sağlanmış olması ve çekirdek bileşenler için yedek olmaması nedeniyle oluşur.

Bu durumu önlemek için, düğümlerin aşırı sağlanmadığından emin olmak için pod belirtimine CPU ve bellek için kaynak sınırlarını ve kaynak isteklerini ekleyin. Windows düğümleri kaynak sınırlarına göre çıkarma işlemini desteklemez, bu nedenle kapsayıcıların ne kadar kullanacağını tahmin etmeli ve düğümlerin yeterli CPU ve bellek miktarına sahip olduğundan emin olmalısınız. Sistem gereksinimleri bölümünde daha fazla bilgi bulabilirsiniz.

AKS konak yönetim kümenizde aşağıdaki Azure ilkesini kullandığınızda küme otomatik ölçeklendirme başarısız olabilir: "Kubernetes kümeleri varsayılan ad alanını kullanmamalıdır." Bunun nedeni, ilkenin AKS konak yönetim kümesinde uygulandığında varsayılan ad alanında otomatik ölçeklendirici profillerinin oluşturulmasını engellemesidir. Bu sorunu düzeltmek için aşağıdaki seçeneklerden birini belirleyin:

• AKS konak yönetim kümesindeki Azure İlkesi uzantısını kaldırın. Azure İlkesi uzantılarını kaldırma hakkında daha fazla bilgi için buraya bakın.
• AKS konak yönetim kümelerini dışlamak için Azure ilkesinin kapsamını değiştirin. Azure İlkesi kapsamları hakkında daha fazla bilgiyi burada bulabilirsiniz.
• AKS konak yönetim kümesi için ilke zorlama modunu "Devre Dışı" olarak ayarlayın. Zorlama modu hakkında daha fazla bilgiyi burada bulabilirsiniz.

Bu, Azure Yerel Temmuz Güncelleştirmesi (sürüm 1.0.2.10723) üzerinde AKS ile ilgili bilinen bir sorundur. CloudAgent hizmetinin sistemdeki birden çok küme paylaşılan birimi arasında sanal makinelerin dağıtımı sırasında zaman aşımına uğradığından hata oluşur.

Bu sorunu çözmek için Azure Yerel sürümündeki en son AKS sürümüne yükseltmeniz gerekir.

Azure Yerel'de sıfır Linux veya Windows düğümlü bir AKS kümesi sağlarsanız, Get-AksHciCluster komutunu çalıştırdığınızda çıkış boş bir dize veya null değer olur.

Null, sıfır düğümler için beklenen bir dönüşdür.

Bir yönetim veya iş yükü kümesini dört günden uzun süre kapattığınızda sertifikaların süresi dolar ve kümeye ulaşılamaz. Sertifikaların süresi, güvenlik nedeniyle 3-4 günde bir döndürüldüğünden sona erer.

Kümeyi yeniden başlatmak için, herhangi bir küme işlemi gerçekleştirmeden önce sertifikaları el ile onarmanız gerekir. Sertifikaları onarmak için aşağıdaki Repair-AksHciClusterCerts komutunu çalıştırın:

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

bir iş yükü kümesinin ölçeği genişletildiğinde, ilgili Linux ve Windows VM'leri çalışan düğümleri olarak eklenmiştir, ancak yüksek oranda kullanılabilir VM'ler olarak yapılandırılmamışlardır. Get-ClusterGroup komutu çalıştırılırken, yeni oluşturulan Linux VM Küme Grubu olarak yapılandırılmadı.

Bu bilinen bir sorundur. Yeniden başlatmadan sonra VM'leri yüksek oranda kullanılabilir olarak yapılandırma özelliği bazen kaybolur. Geçerli geçici çözüm, Azure Yerel düğümlerinin her birinde yeniden başlatmaktır wssdagent . Bu yalnızca bir genişleme işlemi gerçekleştirirken veya düğümlerde yeniden başlatıldıktan wssdagent sonra yeni Kubernetes kümeleri oluştururken düğüm havuzları oluşturarak oluşturulan yeni VM'ler için çalışır. Ancak, mevcut VM'leri yük devretme kümesine el ile eklemeniz gerekir.

Bir kümenin ölçeğini azalttığınızda, VM'ler kaldırılırken yüksek kullanılabilirlik kümesi kaynakları başarısız durumda olur. Bu sorunun geçici çözümü, başarısız kaynakları el ile kaldırmaktır.

Azure VM'sinde dağıtılan aks kümesi daha önce sorunsuz çalışıyordu, ancak AKS konağı birkaç gün Kubectl boyunca kapatıldıktan sonra komut çalışmadı. veya Kubectl get services komutunu çalıştırdıktan Kubectl get nodes sonra şu hata iletisi görüntülenir: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Aks konağı dört günden uzun süre kapalı olduğundan bu sorun oluştu ve bu da sertifikaların süresinin dolmasına neden oldu. Sertifikalar genellikle dört günlük bir döngüde döndürülür. Sertifika süre sonu sorununu düzeltmek için Repair-AksHciClusterCerts komutunu çalıştırın.

Statik IP adresleri ve Windows düğümleri olan bir iş yükü kümesinde, düğümdeki tüm podlar (podlar dahildaemonset) ContainerCreating durumunda takılır. SSH kullanarak bu düğüme bağlanmaya çalışırken bağlantı bir Connection timed out hatayla başarısız oluyor.

Bu sorunu çözmek için Hyper-V Yöneticisi'ni veya Yük Devretme Kümesi Yöneticisi'ni kullanarak bu düğümün VM'sini kapatın. 5-10 dakika sonra düğüm, tüm podların çalıştığı şekilde yeniden oluşturulmuş olmalıdır.

Kubelet disk baskısı altındayken, duraklatma görüntüleri içerebilen kullanılmayan kapsayıcı görüntülerini toplar ve bu durumda ContainerD görüntüyü çekemez.

Bu sorunu çözmek için aşağıdaki adımları çalıştırın:

1. Etkilenen düğüme SSH kullanarak bağlanın ve aşağıdaki komutu çalıştırın:

sudo su

2. Görüntüyü çekmek için aşağıdaki komutu çalıştırın:

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

Sonraki adımlar

• Sorun Giderme seçenekleri
• Ağ sorunları ve hataları
• depolama ile ilgili bilinen sorunlar