Rozwiązywanie znanych problemów i błędów podczas konfigurowania sieci w usłudze AKS Arc

Agent chmury może zakończyć się niepowodzeniem podczas używania nazw ścieżek z spacjami w nich.

W przypadku używania polecenia Set-AksHciConfig do określenia -imageDirparametrów , -workingDir, -cloudConfigLocationlub -nodeConfigLocation o nazwie ścieżki zawierającej znak spacji, na przykład D:\Cloud Share\AKS HCI, uruchomienie usługi klastra agenta w chmurze zakończy się niepowodzeniem z następującym (lub podobnym) komunikatem o błędzie:

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'

Aby obejść ten problem, użyj ścieżki, która nie zawiera spacji, na przykład C:\CloudShare\AKS-HCI.

Klastry połączone z usługą Azure Arc dla platformy Kubernetes mogą mieć wartość właściwości distribution JSON ustawioną na pusty ciąg. W przypadku klastrów połączonych z usługą AKS Arc ta wartość jest ustawiana podczas początkowej instalacji i nigdy nie jest zmieniana przez okres istnienia wdrożenia.

Aby odtworzyć problem, otwórz okno programu Azure PowerShell i uruchom następujące polecenia:

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

Poniżej przedstawiono przykładowe dane wyjściowe tego polecenia:

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

Aby rozwiązać problem

Jeśli dane wyjściowe właściwości JSON distribution zwracają pusty ciąg, wykonaj następujące instrukcje, aby zastosować poprawkę klastra:

1. Skopiuj następującą konfigurację do pliku o nazwie patchBody.json:

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

   Ważne

   Jeśli klaster jest klastrem zarządzania usługi AKS, wartość powinna być ustawiona na aks_management. Jeśli jest to klaster obciążenia, powinien być ustawiony na aks_workloadwartość .

2. Z danych wyjściowych JSON uzyskanych powyżej skopiuj identyfikator połączonego klastra. Powinien być wyświetlany jako długi ciąg w następującym formacie:

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

3. Uruchom następujące polecenie, aby zastosować poprawkę klastra. Wartość <cc_arm_id> powinna być identyfikatorem uzyskanym w kroku 2:

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

4. Sprawdź, czy klaster został pomyślnie poprawiony, uruchamiając polecenie az connectedk8s show -g <rg_name> -n <cc_name> , aby upewnić się, że właściwość distribution JSON została poprawnie ustawiona.

Objawy:

• Serwer proxy włączony w usłudze AKS Arc. Usługa WSSDAgent utknęła w starting stanie . Jest wyświetlana jako następująca:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> z węzła, w którym agent węzła kończy się niepowodzeniem w kierunku agenta chmury, działa prawidłowo w systemie (nawet jeśli nie można uruchomić programu wssdagent)
• Curl.exe z węzła, na którym agent kończy się niepowodzeniem w kierunku agenta w chmurze, odtwarza problem i jest zablokowany: curl.exe https://<computerIP>:6500
• Aby rozwiązać ten problem, przekaż flagę --noproxy do curl.exe. Program Curl zwraca błąd z polecenia wssdcloudagent. Jest to oczekiwane, ponieważ program curl nie jest klientem GRPC. Program Curl nie czeka podczas wysyłania flagi --noproxy . Dlatego zwracanie błędu jest uznawane za powodzenie tutaj):

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

Prawdopodobnie ustawienia serwera proxy zostały zmienione na uszkodzony serwer proxy na hoście. Ustawienia serwera proxy usługi AKS Arc to zmienne środowiskowe dziedziczone z procesu nadrzędnego na hoście. Te ustawienia są propagowane tylko po uruchomieniu nowej usługi lub starej aktualizacji lub ponownym uruchomieniu. Możliwe, że uszkodzone ustawienia serwera proxy zostały ustawione na hoście i zostały one propagowane do programu WSSDAgent po aktualizacji lub ponownym uruchomieniu, co spowodowało niepowodzenie agenta WSSDAgent.

Należy naprawić ustawienia serwera proxy, zmieniając zmienne środowiskowe na maszynie. Na maszynie zmień zmienne za pomocą następujących poleceń:

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

Uruchom ponownie maszynę, aby menedżer usług i program WSSDAgent odebrał stały serwer proxy.

Ten błąd występuje, ponieważ za każdym razem, gdy zasobnik CAPH jest uruchamiany, następuje próba zalogowania się do agenta cloudagent i certyfikat jest przechowywany w woluminie magazynu tymczasowego, co spowoduje wyczyszczenie po ponownym uruchomieniu zasobnika. W związku z tym za każdym razem, gdy zasobnik zostanie ponownie uruchomiony, certyfikat zostanie zniszczony i zostanie podjęta nowa próba logowania.

Próba logowania rozpoczyna procedurę odnawiania, która odnawia certyfikat, gdy zbliża się do wygaśnięcia. Zasobnik CAPH decyduje, czy wymagane jest zalogowanie się, jeśli certyfikat jest dostępny, czy nie. Jeśli certyfikat jest dostępny, logowanie nie zostanie podjęta, zakładając, że jest już dostępna rutyna odnawiania.

Jednak po ponownym uruchomieniu kontenera katalog tymczasowy nie jest czyszczony, więc plik jest nadal utrwalany, a próba logowania nie jest podejmowana, co powoduje, że nie można uruchomić procedury odnawiania. Prowadzi to do wygaśnięcia certyfikatu.

Aby rozwiązać ten problem, uruchom ponownie zasobnik CAPH przy użyciu następującego polecenia:

kubectl delete pod pod-name

Podczas uruchamiania polecenia Set-AksHciConfig może wystąpić następujący błąd:

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.

W większości przypadków ten błąd występuje w wyniku zmiany tokenu zabezpieczającego użytkownika (ze względu na zmianę członkostwa w grupie), zmianę hasła lub wygasłe hasło. W większości przypadków problem można rozwiązać, wylogowując się z komputera i logując się ponownie. Jeśli błąd nadal występuje, możesz utworzyć bilet pomocy technicznej za pośrednictwem witryny Azure Portal.

Ten problem powoduje, że klaster usługi AKS Arc pozostaje w stanie ScalingControlPlane przez dłuższy czas.

Aby odtworzyć

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>

Ten problem został rozwiązany w ostatnich wersjach usługi AKS Arc. Zalecamy zaktualizowanie klastrów usługi AKS Arc do najnowszej wersji.

Aby rozwiązać ten problem, skontaktuj się z pomocą techniczną, aby ręcznie zastosować poprawkę stanu węzłów płaszczyzny sterowania, aby usunąć warunek MachineOwnerRemediatedCondition ze stanu maszyny za pośrednictwem narzędzia kubectl.

Nie można odnaleźć klastra obciążenia, jeśli pule adresów IP dwóch usług AKS w wdrożeniach lokalnych platformy Azure są takie same lub nakładają się na siebie. Jeśli wdrożysz dwa hosty usługi AKS i użyjesz tej samej AksHciNetworkSetting konfiguracji dla obu tych klasterów, program PowerShell i centrum administracyjne systemu Windows mogą nie znaleźć klastra obciążenia, ponieważ serwer interfejsu API zostanie przypisany do tego samego adresu IP w obu klastrach, co spowoduje konflikt.

Otrzymany komunikat o błędzie będzie wyglądać podobnie do przedstawionego poniżej przykładu.

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.

Aby rozwiązać ten problem, usuń jeden z klastrów i utwórz nowe ustawienie sieciowe klastra usługi AKS, które ma nienakładającą się sieć z innymi klastrami.

Uruchomienie polecenia Get-AksHciClusterNetwork zawiera listę wszystkich konfiguracji sieci wirtualnej. Jednak polecenie nie pokazuje bieżącej alokacji adresów IP.

Aby dowiedzieć się, jakie adresy IP są obecnie używane w sieci wirtualnej, wykonaj poniższe kroki:

1. Aby uzyskać grupę, uruchom następujące polecenie:

Get-MocGroup -location MocLocation

2. Aby uzyskać listę aktualnie używanych adresów IP oraz listę dostępnych lub używanych wirtualnych adresów IP, uruchom następujące polecenie:

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

3. Użyj następującego polecenia, aby wyświetlić listę wirtualnych adresów IP, które są obecnie używane:

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

Adres IP klastra jest wyświetlany jako "Niepowodzenie" podczas wstępnego badania. To wstępne sprawdzanie sprawdza, czy wszystkie adresy IPv4 i nazwy sieci DNS są w trybie online i są dostępne. Na przykład nieudana nazwa protokołu IPv4 lub sieci może spowodować niepowodzenie tego testu.

Aby rozwiązać ten problem, wykonaj następujące kroki:

1. Uruchom następujące polecenie:

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

2. Upewnij się, że wszystkie nazwy sieci i adresy IP są w stanie online.

3. Uruchom następujące dwa polecenia:

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

   a następnie

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

Podczas wdrażania usługi AKS na platformie Azure Lokalnie wdrożenie może upłynął limit czasu w różnych punktach procesu w zależności od tego, gdzie wystąpiła błędna konfiguracja. Należy przejrzeć komunikat o błędzie, aby określić przyczynę i miejsce jego wystąpienia.

Na przykład w poniższym błędzie punkt, w którym wystąpiła błędna konfiguracja, znajduje się w pliku 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"}

Oznacza to, że fizyczny węzeł lokalny platformy Azure może rozpoznać nazwę adresu URL pobierania, msk8s.api.cdp.microsoft.comale węzeł nie może nawiązać połączenia z serwerem docelowym.

Aby rozwiązać ten problem, należy określić, gdzie wystąpił podział w przepływie połączenia. Poniżej przedstawiono kilka kroków, które należy wykonać, aby spróbować rozwiązać problem z węzła klastra fizycznego:

1. Wyślij polecenie ping do docelowej nazwy DNS: ping msk8s.api.cdp.microsoft.com.
2. Jeśli otrzymasz odpowiedź z powrotem i nie upłynął limit czasu, podstawowa ścieżka sieciowa działa.
3. Jeśli upłynął limit czasu połączenia, może wystąpić przerwa w ścieżce danych. Aby uzyskać więcej informacji, zobacz sprawdzanie ustawień serwera proxy. Może też wystąpić przerwa w ścieżce powrotnej, więc należy sprawdzić reguły zapory.

Aplikacje zależne od czasu NTP mogą wyzwalać setki fałszywych alertów, gdy są poza czasem synchronizacji. Jeśli klaster jest uruchomiony w środowisku proxy, węzłów mogą nie być w stanie komunikować się z domyślnym serwerem NTP, time.windows.com, za pośrednictwem serwera proxy lub zapory.

Rozwiązanie

Aby obejść ten problem, zaktualizuj konfigurację serwera NTP w każdym węźle puli węzłów, aby zsynchronizować zegary. Spowoduje to również ustawienie zegarów w każdym zasobniku aplikacji.

Wymagania wstępne

• Adres serwera NTP, który jest dostępny w każdym węźle puli węzłów.
• Dostęp do pliku kubeconfig klastra obciążenia.
• Dostęp do klastra zarządzania kubeconfig.

Kroki

1. Uruchom następujące kubectl polecenie przy użyciu klastra obciążenia kubeconfig , aby uzyskać listę węzłów w nim:

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

2. Uruchom następujące kubectl polecenie, aby skorelować nazwy węzłów z poprzedniego polecenia do węzłów puli węzłów klastra obciążenia. Zanotuj odpowiednie adresy IP z danych wyjściowych poprzedniego polecenia.

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

3. Korzystając z danych wyjściowych z poprzednich kroków, uruchom następujące kroki dla każdego węzła puli węzłów, który wymaga zaktualizowania konfiguracji NTP:

   1. Połączenie SSH z maszyną wirtualną węzła puli węzłów:

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

   2. Sprawdź, czy skonfigurowany serwer NTP jest niedostępny:

      sudo timedatectl timesync-status
      

      Jeśli dane wyjściowe wyglądają następująco, serwer NTP jest niemożliwy do osiągnięcia i należy go zmienić:

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

   3. Aby zaktualizować serwer NTP, uruchom następujące polecenia, aby ustawić serwer NTP w pliku konfiguracji timesync na taki, który jest dostępny z maszyny wirtualnej puli węzłów:

      # 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. Uruchom ponownie usługę timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Sprawdź, czy serwer NTP jest dostępny:

      sudo timedatectl timesync-status
      

   6. Sprawdź, czy zegar pokazuje prawidłowy czas:

      date
      

4. Upewnij się, że każdy węzeł puli węzłów jest wyświetlany w tym samym czasie, uruchamiając polecenie z kroku 3.f.

5. Jeśli aplikacja nie zaktualizuje czasu automatycznie, uruchom ponownie zasobniki.

Następne kroki

• Omówienie rozwiązywania problemów
• Problemy z instalacją i błędy
• Znane problemy z magazynem