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ılamaz.

Set-AksHciConfig kullanarak, gibi D:\Cloud Share\AKS HCIbir boşluk karakteri içeren bir yol adıyla , -workingDir, -cloudConfigLocationveya -nodeConfigLocation parametreleri 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'e bağlı kümeler için Azure Arc'ta JSON özelliğinin distribution değeri boş bir dizeye ayarlanmış olabilir. AKS Arc'a bağ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

Bu komutun örnek çıktısı aşağıda 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 elde edilen 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 çalıştırarak az connectedk8s show -g <rg_name> -n <cc_name> kümenize başarıyla düzeltme eki eklenip yüklenmediğini denetleyin.

Belirtiler:

• AKS Arc'ta proxy etkinleştirildi. WSSDAgent hizmeti durumunda starting takıldı. Aşağıdaki gibi gösterilir:
• 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 düzeltmek 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

Proxy ayarları büyük olasılıkla 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'ta oturum açma girişiminde bulunuluyor olması ve sertifikanın geçici depolama biriminde depolanmasıdır ve bu da pod yeniden başlatmalarında temizlenir. 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ın oturum açma 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 temizlenmediği için dosya 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 neden olur.

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

kubectl delete pod pod-name

Set-AksHciConfig komutunu ç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.

Bu hata çoğu zaman 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ı üzerinden bir destek bileti oluşturabilirsiniz.

Bu sorun, AKS Arc kümesinin ScalingControlPlane durumunda uzun 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, machineOwnerRemediatedCondition koşulunu kubectl aracılığıyla makine durumundan kaldırmak üzere denetim düzlemi düğümlerinin durumunu el ile düzeltme eki uygulamak için desteğe başvurun.

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 konağından dağıtıp 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 Yönetim Merkezi iş yükü kümesini bulamayacağından ç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ğa sahip 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, komutu IP adreslerinin geçerli ayırmasını göstermez.

Sanal ağda şu anda hangi IP adreslerinin kullanıldığını öğ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. Şu anda kullanımda 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ı uygulayın:

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"
   

   ve ardından

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

Aks'yi Azure Yerel'de 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 uğradı. Nedenini ve oluştuğu yeri belirlemek için hata iletisini gözden geçirmeniz gerekir.

Ö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 Yerel 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 çözmeye yönelik 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 uğradıysa 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 varsayılan NTP sunucusuyla (time.windows.com) iletişim kuramayabilir.

Geçici çözüm

Bu sorunu geçici olarak çözmek için, 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 elde edilen çı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ış şöyle görünüyorsa NTP sunucusuna ulaşılamıyor ve değiştirilmesi gerekiyor:

      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 timesync 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üğümünü aynı anda gösterdiğ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