AKS Arc'ta ağ yapılandırırken bilinen sorunları ve hataları düzeltme

Bulut aracısı, içinde boşluklar olan yol adları kullanılırken başarıyla başlatılamaya çalışabilir.

Set-AksHciConfig kullanarak, gibi D:\Cloud Share\AKS HCIboşluk karakteri içeren bir yol adıyla , -workingDir, -cloudConfigLocationveya -nodeConfigLocation parametrelerini belirtirken-imageDir, bulut aracısı küme hizmeti aşağıdaki (veya benzer) hata iletisiyle başlatılamaz:

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Bu sorunu geçici olarak çözmek için boşluk içermeyen bir yol kullanın; örneğin, C:\CloudShare\AKS-HCI.

Kubernetes bağlantılı kümeler için Azure Arc, JSON özelliğinin distribution değerini boş bir dize olarak ayarlayabilir. AKS Arc bağlantılı kümeler için bu değer ilk yükleme sırasında ayarlanır ve dağıtımın ömrü boyunca hiçbir zaman değiştirilmez.

Sorunu yeniden oluşturmak için bir Azure PowerShell penceresi açın ve aşağıdaki komutları çalıştırın:

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

Aşağıda, bu komuttan alınan örnek çıktı verilmiştir:

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

Sorunu çözmek için

JSON distribution özelliğinin çıkışı boş bir dize döndürüyorsa kümenize düzeltme eki uygulamak için şu yönergeleri izleyin:

1. Aşağıdaki yapılandırmayı patchBody.json adlı bir dosyaya kopyalayın:

   {
      "properties": {
        "distribution": "aks_management"
      }
   }
   

   Önemli

   Kümeniz bir AKS yönetim kümesiyse, değeri olarak aks_managementayarlanmalıdır. Bu bir iş yükü kümesiyse, olarak ayarlanmalıdır aks_workload.

2. Yukarıda elde ettiğiniz JSON çıkışından bağlı küme kimliğinizi kopyalayın. Aşağıdaki biçimde uzun bir dize olarak görünmelidir:

   "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

3. Kümenize düzeltme eki uygulamak için aşağıdaki komutu çalıştırın. Değer, <cc_arm_id> 2. adımda alınan kimlik olmalıdır:

   az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"
   

4. JSON özelliğinin distribution doğru ayarlandığından emin olmak için komutunu çalıştırarak az connectedk8s show -g <rg_name> -n <cc_name> kümenize başarıyla düzeltme eki eklenip eklenmediğini denetleyin.

Belirtiler:

• AKS Arc'ta proxy etkinleştirildi. WSSDAgent hizmeti durumunda starting takıldı. Aşağıdaki gibi görünür:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> düğüm aracısının bulut aracısına doğru başarısız olduğu düğümden sistem üzerinde düzgün çalışıyor (wssdagent başlatılamıyor olsa bile)
• Aracının bulut aracısına doğru başarısız olduğu düğümden Curl.exe sorunu yeniden üretir ve takılıyor: curl.exe https://<computerIP>:6500
• Sorunu çözmek için bayrağını --noproxy curl.exe geçirin. Curl, wssdcloudagent'dan bir hata döndürür. Curl bir GRPC istemcisi olmadığından bu beklenen bir durumdur. Bayrağı gönderdiğinizde --noproxy Curl beklerken takılmaz. Bu nedenle hata döndürmek burada başarılı olarak kabul edilir:

curl.exe --noproxy '*' https://<computerIP>:65000

Büyük olasılıkla ara sunucu ayarları konakta hatalı bir ara sunucuya değiştirilmiş olabilir. AKS Arc için ara sunucu ayarları, konak üzerindeki üst işlemden devralınan ortam değişkenleridir. Bu ayarlar yalnızca yeni bir hizmet başlatıldığında veya eski bir hizmet güncelleştirildiğinde veya yeniden başlatıldığında yayılır. Hatalı ara sunucu ayarları konakta ayarlanmış olabilir ve bir güncelleştirme veya yeniden başlatmadan sonra WSSDAgent'a yayılır ve bu da WSSDAgent'ın başarısız olmasına neden olur.

Makinedeki ortam değişkenlerini değiştirerek ara sunucu ayarlarını düzeltmeniz gerekir. Makinede aşağıdaki komutlarla değişkenleri değiştirin:

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

Hizmet yöneticisinin ve WSSDAgent'ın sabit ara sunucuyu alması için makineyi yeniden başlatın.

Bu hatanın nedeni, CAPH podunun her başlatıldığında cloudagent'da oturum açma girişiminde bulunup sertifikanın pod yeniden başlatmalarında temizlenecek geçici depolama biriminde depolanmasıdır. Bu nedenle, bir pod her yeniden başlatıldığında sertifika yok edilir ve yeni bir oturum açma girişimi yapılır.

Oturum açma girişimi, süresi dolmaya yaklaştığında sertifikayı yenileyen bir yenileme yordamı başlatır. CAPH podu, sertifikanın kullanılabilir olup olmadığını oturum açmanın gerekip gerekmediğine karar verir. Sertifika kullanılabilir durumdaysa, yenileme yordamının zaten orada olduğu varsayılarak oturum açma girişiminde bulunulmuyordur.

Ancak kapsayıcı yeniden başlatıldığında geçici dizin temizlenmez, bu nedenle dosya hala kalıcı hale getirilir ve oturum açma girişimi yapılmaz ve bu da yenileme yordamının başlatılmamasına neden olur. Bu, sertifika süresinin dolmasına yol açar.

Bu sorunu azaltmak için aşağıdaki komutu kullanarak CAPH podunu yeniden başlatın:

kubectl delete pod pod-name

Set-AksHciConfig'i çalıştırırken aşağıdaki hatayla karşılaşabilirsiniz:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

Çoğu zaman, bu hata kullanıcının güvenlik belirtecindeki bir değişikliğin (grup üyeliğindeki bir değişiklik nedeniyle), parola değişikliğinin veya süresi dolmuş parolanın bir sonucu olarak oluşur. Çoğu durumda bilgisayarda oturum kapatılıp yeniden açılarak sorun düzeltilebilir. Hata yine de oluşursa, Azure portal aracılığıyla bir destek bileti oluşturabilirsiniz.

Bu sorun, AKS Arc kümesinin ScalingControlPlane durumunda uzun bir süre kalmasına neden olur.

Yeniden oluşturmak için

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

Bu sorun son AKS Arc sürümlerinde düzeltilmiştir. AKS Arc kümelerinizi en son sürüme güncelleştirmenizi öneririz.

Bu sorunu azaltmak için denetim düzlemi düğümlerinin durumuna el ile düzeltme eki uygulayarak MachineOwnerRemediatedCondition koşulunu kubectl aracılığıyla makine durumundan kaldırın.

Azure Stack HCI dağıtımlarında iki AKS'nin IP adresi havuzları aynıysa veya çakışıyorsa iş yükü kümesi bulunamayabilir. İki AKS konağından 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ğından PowerShell ve Windows Admin Center iş yükü kümesini bulamaz ve bu da ç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.

Sorunu çözmek için kümelerden birini silin ve diğer kümelerle çakışmayan bir ağı olan yeni bir AKS kümesi ağ ayarı oluşturun.

Get-AksHciClusterNetwork komutunu çalıştırmak tüm sanal ağ yapılandırmalarının listesini sağlar. Ancak komut, IP adreslerinin geçerli ayırmasını göstermez.

Sanal ağda şu anda hangi IP adreslerinin kullanımda olduğunu öğrenmek için aşağıdaki adımları kullanın:

1. Grubu almak için aşağıdaki komutu çalıştırın:

Get-MocGroup -location MocLocation

2. Kullanılmakta olan IP adreslerinin listesini ve kullanılabilir veya kullanılan sanal IP adreslerinin listesini almak için aşağıdaki komutu çalıştırın:

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. Şu anda kullanımda olan sanal IP adreslerinin listesini görüntülemek için aşağıdaki komutu kullanın:

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

Ön denetim sırasında küme IP adresi "Başarısız" olarak gösterilir. Bu ön denetim, tüm IPv4 adreslerinin ve DNS ağ adlarının çevrimiçi ve erişilebilir olduğunu test eder. Örneğin, başarısız bir IPv4 veya ağ adı bu testin başarısız olmasına neden olabilir.

Bu sorunu çözmek için aşağıdaki adımları gerçekleştirin:

1. Şu komutu çalıştırın:

   Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
   

2. Tüm ağ adlarının ve IP adreslerinin çevrimiçi durumda olduğundan emin olun.

3. Aşağıdaki iki komutu çalıştırın:

   Stop-ClusterResource -name "Cluster IP Address x.x.x.x"
   

   ardından

   Start-ClusterResource -name "Cluster IP Address x.x.x.x"
   

Azure Stack HCI üzerinde AKS dağıttığınızda, yanlış yapılandırmanın oluştuğu yere bağlı olarak işlemin farklı noktalarında dağıtım zaman aşımına uyabilir. Nedenini ve oluştuğu yeri belirlemek için hata iletisini gözden geçirmelisiniz.

Örneğin, aşağıdaki hatada, yanlış yapılandırmanın oluştuğu nokta içindedir Get-DownloadSdkRelease -Name "mocstack-stable":

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Bu, fiziksel Azure Stack HCI düğümünün indirme URL'sinin adını çözümleyebildiğini ancak msk8s.api.cdp.microsoft.comdüğümün hedef sunucuya bağlanadığını gösterir.

Bu sorunu çözmek için bağlantı akışında dökümün nerede oluştuğuna karar vermeniz gerekir. Fiziksel küme düğümünden sorunu çözmeyi denemek için bazı adımlar şunlardır:

1. Hedef DNS adına ping at: ping msk8s.api.cdp.microsoft.com.
2. Geri bir yanıt alırsanız ve zaman aşımı yoksa temel ağ yolu çalışıyor demektir.
3. Bağlantı zaman aşımına uysa veri yolunda bir kesme olabilir. Daha fazla bilgi için bkz. Ara sunucu ayarlarını denetleme. Alternatif olarak, dönüş yolunda bir kesme olabilir, bu nedenle güvenlik duvarı kurallarını denetlemeniz gerekir.

NTP zamana bağımlı uygulamalar, zaman eşitlemesi olmadığında yüzlerce yanlış uyarı tetikleyebilir. Küme bir ara sunucu ortamında çalışıyorsa, düğüm havuzlarınız ara sunucunuz veya güvenlik duvarınız aracılığıyla time.windows.com varsayılan NTP sunucusuyla iletişim kuramayabilir.

Geçici çözüm

Bu soruna geçici bir çözüm olarak, saatleri eşitlemek için her düğüm havuzu düğümünde NTP sunucu yapılandırmasını güncelleştirin. Bunu yaptığınızda uygulama podlarınızın her birinde de saatler ayarlanır.

Önkoşullar

• Her düğüm havuzu düğümünde erişilebilen bir NTP sunucusunun adresi.
• İş yükü kümesi kubeconfig dosyasına erişim.
• Yönetim kümesi kubeconfig'e erişim.

Adımlar

1. Kubeconfig iş yükü kümesini kullanarak aşağıdaki kubectl komutu çalıştırarak içindeki düğümlerin listesini alın:

   kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
   

2. Önceki komuttan düğüm adlarını iş yükü kümesinin düğüm havuzu düğümleri ile ilişkilendirmek için aşağıdaki kubectl komutu çalıştırın. Önceki komutun çıkışındaki ilgili IP adreslerini not alın.

   kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>
   

3. Önceki adımlardan alınan çıkışı kullanarak NTP yapılandırmasının güncelleştirilmesi gereken her düğüm havuzu düğümü için aşağıdaki adımları çalıştırın:

   1. Düğüm havuzu düğümü VM'sine SSH:

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
      

   2. Yapılandırılan NTP sunucusuna ulaşılamediğini doğrulayın:

      sudo timedatectl timesync-status
      

      Çıkış şuna benzerse, NTP sunucusuna ulaşılamaz ve değiştirilmesi gerekir:

      Server: n/a (time.windows.com)
      Poll interval: 0 (min: 32s; max 34min 8s)
      Packet count: 0
      

   3. NTP sunucusunu güncelleştirmek için aşağıdaki komutları çalıştırarak zaman uyumsuz yapılandırma dosyasındaki NTP sunucusunu nodepool VM'sinden erişilebilen bir sunucuya ayarlayın:

      # make a backup of the config file
      sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak
      
      # update the ntp server
      NTPSERVER="NEW_NTP_SERVER_ADDRESS"
      sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf
      
      # verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
      sudo cat /etc/systemd/timesyncd.conf 
      

   4. Timesync hizmetini yeniden başlatın:

      sudo systemctl restart systemd-timesyncd.service
      

   5. NTP sunucusunun erişilebilir olduğunu doğrulayın:

      sudo timedatectl timesync-status
      

   6. Saatin doğru saati gösterdiğini doğrulayın:

      date
      

4. 3.f adımındaki komutu çalıştırarak her düğüm havuzu düğümlerinin aynı zamanda gösterildiğinden emin olun.

5. Uygulamanız zamanını otomatik olarak güncelleştirmezse podlarını yeniden başlatın.

Sonraki adımlar

• Sorun Giderme seçenekleri
• Yükleme sorunları ve hataları
• Depolama ile ilgili bilinen sorunlar