Hálózat AKS Arcban történő konfigurálásakor felmerülő ismert problémák és hibák elhárítása

Előfordulhat, hogy a felhőügynök nem indul el sikeresen, ha szóközökkel rendelkező elérési utakat használ.

Ha a Set-AksHciConfig használatával szóköz karaktert (példáulD:\Cloud Share\AKS HCI) tartalmazó elérésiút-névvel rendelkező , -workingDir, , -cloudConfigLocationvagy -nodeConfigLocation paramétereket ad meg-imageDir, a felhőügynök fürtszolgáltatása nem indul el a következő (vagy hasonló) hibaüzenettel:

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'

A probléma megkerüléséhez használjon olyan elérési utat, amely nem tartalmaz szóközöket, például C:\CloudShare\AKS-HCI: .

A Kuberneteshez csatlakoztatott Azure Arc-fürtök JSON-tulajdonságának distribution értéke egy üres sztringre állítható. Az AKS Archoz csatlakoztatott fürtök esetében ez az érték a kezdeti telepítés során van beállítva, és az üzembe helyezés teljes élettartama alatt nem változik.

A probléma reprodukálásához nyisson meg egy Azure PowerShell ablakot, és futtassa a következő parancsokat:

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

Az alábbi példakimenet az alábbi parancsból származik:

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

A probléma megoldása

Ha a JSON distribution tulajdonság kimenete üres sztringet ad vissza, kövesse az alábbi utasításokat a fürt javításához:

1. Másolja a következő konfigurációt egy patchBody.json nevű fájlba:

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

   Fontos

   Ha a fürt AKS felügyeleti fürt, az értéket a következőre kell állítani: aks_management. Ha számítási feladatokat futtató fürtről van szó, akkor a következőre kell állítani: aks_workload.

2. A fenti JSON-kimenetből másolja ki a csatlakoztatott fürtazonosítót. Hosszú sztringként kell megjelennie a következő formátumban:

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

3. Futtassa a következő parancsot a fürt javításához. Az <cc_arm_id> értéknek a 2. lépésben kapott azonosítónak kell lennie:

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

4. Ellenőrizze, hogy a fürt sikeresen ki lett-e javítva a futtatással az connectedk8s show -g <rg_name> -n <cc_name> , és ellenőrizze, hogy a JSON tulajdonság distribution megfelelően van-e beállítva.

Tünetek:

• Az AKS Arcban engedélyezett proxy. A WSSDAgent szolgáltatás elakadt az starting állapotban. A következőként jelenik meg:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> a csomópontról, ahol a csomópontügynök meghibásodik a felhőügynök felé, megfelelően működik a rendszeren (még akkor is, ha a wssdagent nem indul el)
• Curl.exe attól a csomóponttól, amelyen az ügynök a felhőügynök felé halad, reprodukálja a problémát, és elakad: curl.exe https://<computerIP>:6500
• A probléma megoldásához adja át a jelzőt a --noproxy curl.exe. A Curl hibát ad vissza a wssdcloudagentből. Ez azért várható, mert a curl nem GRPC-ügyfél. Curl nem fog elakadni, amikor elküldi a jelzőt --noproxy . A hiba visszaadása tehát sikeresnek minősül itt:

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

Valószínű, hogy a proxybeállítások hibás proxyra lettek módosítva a gazdagépen. Az AKS Arc proxybeállításai olyan környezeti változók, amelyek a gazdagép szülőfolyamatától öröklődnek. Ezek a beállítások csak akkor lesznek propagálva, ha egy új szolgáltatás elindul, vagy egy régi frissül vagy újraindul. Lehetséges, hogy a hibás proxybeállítások be lettek állítva a gazdagépen, és egy frissítés vagy újraindítás után propagálták őket a WSSDAgentre, ami miatt a WSSDAgent meghiúsult.

A számítógép környezeti változóinak módosításával meg kell javítania a proxybeállításokat. A gépen módosítsa a változókat a következő parancsokkal:

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

Indítsa újra a gépet, hogy a szolgáltatáskezelő és a WSSDAgent vegye fel a rögzített proxyt.

Ez a hiba azért fordul elő, mert minden alkalommal, amikor a CAPH-pod elindul, a rendszer megpróbál bejelentkezni a cloudagentbe, és a tanúsítványt az ideiglenes tárolókötetben tárolja, amely a pod újraindításakor törlődik. Ezért minden alkalommal, amikor egy pod újraindul, a tanúsítvány megsemmisül, és új bejelentkezési kísérlet történik.

A bejelentkezési kísérlet elindít egy megújítási rutint, amely megújítja a tanúsítványt, amikor az hamarosan lejár. A CAPH-pod dönti el, hogy szükség van-e bejelentkezésre, ha a tanúsítvány elérhető vagy nem. Ha a tanúsítvány elérhető, a rendszer nem kísérli meg a bejelentkezést, feltéve, hogy a megújítási rutin már létezik.

A tároló újraindításakor azonban az ideiglenes könyvtár nem törlődik, így a fájl továbbra is megmarad, és a bejelentkezési kísérlet nem történik meg, ami miatt a megújítási rutin nem indul el. Ez tanúsítványlejárathoz vezet.

A probléma megoldásához indítsa újra a CAPH-podot a következő paranccsal:

kubectl delete pod pod-name

A Set-AksHciConfig futtatásakor a következő hibaüzenet jelenhet meg:

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.

Ez a hiba leggyakrabban a felhasználó biztonsági jogkivonatának (a csoporttagság megváltozása), a jelszó módosítása vagy a lejárt jelszó változása miatt fordul elő. A legtöbb esetben a probléma orvosolható, ha kijelentkezik a számítógépről, majd újra bejelentkezik. Ha a hiba továbbra is fennáll, létrehozhat egy támogatási jegyet a Azure Portal keresztül.

Ez a probléma azt eredményezi, hogy egy AKS Arc-fürt hosszabb ideig a ScalingControlPlane állapotban marad.

Reprodukálás

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>

Ezt a problémát kijavítottuk az AKS Arc legújabb verzióiban. Javasoljuk, hogy frissítse az AKS Arc-fürtöket a legújabb kiadásra.

A probléma megoldásához forduljon az ügyfélszolgálathoz, hogy manuálisan javítsa ki a vezérlősík csomópontjainak állapotát a MachineOwnerRemediatedCondition feltétel eltávolításához a gép állapotából a kubectl használatával.

Előfordulhat, hogy a számítási feladatfürt nem található, ha az Azure Stack HCI-üzemelő példányokon két AKS IP-címkészlete azonos vagy átfedésben van. Ha két AKS-gazdagépet helyez üzembe, és ugyanazt AksHciNetworkSetting a konfigurációt használja mindkettőhöz, a PowerShell és a Windows Admin Center valószínűleg nem találja a számítási feladatokat tartalmazó fürtöt, mert az API-kiszolgáló mindkét fürtben ugyanazt az IP-címet fogja hozzárendelni, ami ütközést eredményez.

A kapott hibaüzenet az alábbi példához hasonlóan fog kinézni.

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.

A probléma megoldásához törölje az egyik fürtöt, és hozzon létre egy új AKS-fürthálózati beállítást, amely nem fedi át egymást a többi fürttel.

A Get-AksHciClusterNetwork parancs futtatása az összes virtuális hálózati konfiguráció listáját tartalmazza. A parancs azonban nem jeleníti meg az IP-címek aktuális lefoglalását.

A virtuális hálózaton jelenleg használt IP-címek megtekintéséhez kövesse az alábbi lépéseket:

1. A csoport lekéréséhez futtassa a következő parancsot:

Get-MocGroup -location MocLocation

2. A jelenleg használt IP-címek listájának, valamint az elérhető vagy használt virtuális IP-címek listájának lekéréséhez futtassa a következő parancsot:

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

3. Az alábbi paranccsal megtekintheti a jelenleg használt virtuális IP-címek listáját:

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

A fürt IP-címe "Sikertelen" állapotúként jelenik meg az előzetes ellenőrzés során. Ez az előzetes ellenőrzés azt ellenőrzi, hogy az összes IPv4-cím és DNS-hálózatnév online és elérhető-e. Egy sikertelen IPv4- vagy hálózatnév például a teszt sikertelenségéhez vezethet.

A probléma megoldásához hajtsa végre a következő lépéseket:

1. Futtassa az alábbi parancsot:

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

2. Győződjön meg arról, hogy minden hálózatnév és IP-cím online állapotban van.

3. Futtassa a következő két parancsot:

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

   elemet, majd

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

Ha az AKS-t az Azure Stack HCI-n helyezi üzembe, az üzembe helyezés a folyamat különböző pontjain időtúllépést okozhat attól függően, hogy hol történt a helytelen konfiguráció. A hiba okának és előfordulásának megállapításához tekintse át a hibaüzenetet.

A következő hibában például az a pont, ahol a helytelen konfiguráció történt, a következőben Get-DownloadSdkRelease -Name "mocstack-stable"található:

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

Ez azt jelzi, hogy a fizikai Azure Stack HCI-csomópont fel tudja oldani a letöltési URL-címet, msk8s.api.cdp.microsoft.comde a csomópont nem tud csatlakozni a célkiszolgálóhoz.

A probléma megoldásához meg kell határoznia, hogy hol történt a lebontás a kapcsolati folyamatban. Íme néhány lépés a probléma fizikai fürtcsomópontról történő megoldásához:

1. Pingelje a cél DNS-nevét: ping msk8s.api.cdp.microsoft.com.
2. Ha a rendszer választ kap, és nincs időtúllépés, akkor az alapszintű hálózati útvonal működik.
3. Ha a kapcsolat túllépi az időkorlátot, az adatútvonal megszakadhat. További információ: Proxybeállítások ellenőrzése. Vagy előfordulhat, hogy a visszatérési útvonal megszakad, ezért ellenőrizze a tűzfalszabályokat.

Az NTP-alapú időfüggő alkalmazások több száz hamis riasztást aktiválhatnak, amikor az időkorláton kívül vannak szinkronizálva. Ha a fürt proxykörnyezetben fut, előfordulhat, hogy a csomópontkészletek nem tudnak kommunikálni az alapértelmezett NTP-kiszolgálóval, time.windows.com a proxyn vagy a tűzfalon keresztül.

Áthidaló megoldás

A probléma megkerüléséhez frissítse az NTP-kiszolgáló konfigurációt minden csomópontkészlet-csomóponton az órák szinkronizálásához. Ezzel az egyes alkalmazás podokban is beállítja az órákat.

Előfeltételek

• Egy NTP-kiszolgáló címe, amely minden csomópontkészlet-csomópontban elérhető.
• Hozzáférés a számítási feladatfürt kubeconfig fájlhoz.
• Hozzáférés a kubeconfig felügyeleti fürthöz.

Lépések

1. Futtassa a következő kubectl parancsot a kubeconfig számítási feladatfürt használatával a benne lévő csomópontok listájának lekéréséhez:

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

2. A következő kubectl parancs futtatásával korrelálhatja az előző parancs csomópontneveit a számítási feladat fürtjének csomópontkészlet-csomópontjaival. Jegyezze fel az előző parancs kimenetének megfelelő IP-címeket.

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

3. Az előző lépések kimenetét használva futtassa a következő lépéseket minden olyan csomópontkészlet-csomóponthoz, amelynek frissítenie kell az NTP-konfigurációját:

   1. SSH egy nodepool-csomópont virtuális gépére:

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

   2. Ellenőrizze, hogy a konfigurált NTP-kiszolgáló nem érhető-e el:

      sudo timedatectl timesync-status
      

      Ha a kimenet így néz ki, akkor az NTP-kiszolgáló nem érhető el, és módosítani kell:

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

   3. Az NTP-kiszolgáló frissítéséhez futtassa az alábbi parancsokat az NTP-kiszolgáló időszinkron konfigurációs fájlban való beállításához a nodepool virtuális gépről elérhetőre:

      # 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. Indítsa újra az időszinkronizálási szolgáltatást:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Ellenőrizze, hogy az NTP-kiszolgáló elérhető-e:

      sudo timedatectl timesync-status
      

   6. Ellenőrizze, hogy az óra a megfelelő időpontot jeleníti-e meg:

      date
      

4. A 3.f lépésben található parancs futtatásával győződjön meg arról, hogy minden csomópontcsomópont ugyanabban az időben jelenik meg.

5. Ha az alkalmazás nem frissíti automatikusan az idejét, indítsa újra a podokat.

Következő lépések

• Hibaelhárítási áttekintés
• Telepítési problémák és hibák
• A tárterület ismert problémái