Corrigir problemas e erros conhecidos ao configurar uma rede no AKS Arc

O agente da cloud pode não conseguir iniciar com êxito ao utilizar nomes de caminho com espaços.

Ao utilizar Set-AksHciConfig para especificar -imageDirparâmetros , -workingDir, -cloudConfigLocationou -nodeConfigLocation com um nome de caminho que contenha um caráter de espaço, como D:\Cloud Share\AKS HCI, o serviço de cluster do agente da cloud não começará com a seguinte (ou semelhante) mensagem de erro:

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'

Para contornar este problema, utilize um caminho que não inclua espaços, por exemplo, C:\CloudShare\AKS-HCI.

Os clusters ligados ao Azure Arc para Kubernetes podem ter o valor da propriedade distribution JSON definido como uma cadeia vazia. Para clusters ligados ao AKS Arc, este valor é definido durante a instalação inicial e nunca é alterado durante a duração da implementação.

Para reproduzir o problema, abra uma janela Azure PowerShell e execute os seguintes comandos:

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

Segue-se um exemplo de saída deste comando:

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

Para resolver o problema

Se o resultado da propriedade JSON distribution devolver uma cadeia vazia, siga estas instruções para corrigir o cluster:

1. Copie a seguinte configuração para um ficheiro chamado patchBody.json:

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

   Importante

   Se o cluster for um cluster de gestão do AKS, o valor deve ser definido como aks_management. Se for um cluster de cargas de trabalho, deve ser definido como aks_workload.

2. Na saída JSON que obteve acima, copie o ID do cluster ligado. Deverá aparecer como uma cadeia longa no seguinte formato:

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

3. Execute o seguinte comando para corrigir o cluster. O <cc_arm_id> valor deve ser o ID obtido no passo 2:

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

4. Verifique se o cluster foi corrigido com êxito ao executar az connectedk8s show -g <rg_name> -n <cc_name> para se certificar de que a propriedade distribution JSON foi definida corretamente.

Sintomas:

• Proxy ativado no AKS Arc. O serviço WSSDAgent está bloqueado no starting estado . Aparece da seguinte forma:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> no nó em que o agente do nó está a falhar para o agente da cloud está a funcionar corretamente no sistema (mesmo quando o wssdagent não inicia)
• Curl.exe do nó no qual o agente está a falhar para o agente da cloud reproduz o problema e está a ficar bloqueado: curl.exe https://<computerIP>:6500
• Para corrigir o problema, passe o --noproxy sinalizador para curl.exe. Curl devolve um erro de wssdcloudagent. Isto é esperado, uma vez que curl não é um cliente GRPC. Curl não fica preso à espera quando envia a --noproxy bandeira. Por isso, devolver um erro é considerado um sucesso aqui:

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

É provável que as definições de proxy tenham sido alteradas para um proxy com falhas no anfitrião. As definições de proxy do AKS Arc são variáveis de ambiente herdadas do processo principal no anfitrião. Estas definições só são propagadas quando um novo serviço é iniciado ou um antigo é atualizado ou reiniciado. É possível que as definições de proxy com falhas tenham sido definidas no anfitrião e tenham sido propagadas para o WSSDAgent após uma atualização ou reinício, o que causou a falha do WSSDAgent.

Terá de corrigir as definições de proxy ao alterar as variáveis ambientais no computador. No computador, altere as variáveis com os seguintes comandos:

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

Reinicie o computador para que o gestor de serviços e o WSSDAgent recolham o proxy fixo.

Este erro ocorre porque sempre que o pod CAPH é iniciado, é tentado um início de sessão no cloudagent e o certificado é armazenado no volume de armazenamento temporário, o que irá limpar nos reinícios do pod. Por conseguinte, sempre que um pod é reiniciado, o certificado é destruído e é efetuada uma nova tentativa de início de sessão.

Uma tentativa de início de sessão inicia uma rotina de renovação, que renova o certificado quando está prestes a expirar. O pod CAPH decide se é necessário um início de sessão se o certificado está disponível ou não. Se o certificado estiver disponível, o início de sessão não é tentado, partindo do princípio de que a rotina de renovação já existe.

No entanto, num reinício do contentor, o diretório temporário não é limpo, pelo que o ficheiro continua persistente e a tentativa de início de sessão não é efetuada, o que faz com que a rotina de renovação não seja iniciada. Isto leva à expiração do certificado.

Para mitigar este problema, reinicie o pod CAPH com o seguinte comando:

kubectl delete pod pod-name

Ao executar Set-AksHciConfig, poderá encontrar o seguinte erro:

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.

Na maioria das vezes, este erro ocorre como resultado de uma alteração no token de segurança do utilizador (devido a uma alteração na associação ao grupo), uma alteração de palavra-passe ou uma palavra-passe expirada. Na maioria dos casos, o problema pode ser remediado ao terminar e reiniciar sessão no computador. Se o erro continuar a ocorrer, pode criar um pedido de suporte através do portal do Azure.

Este problema faz com que um cluster do AKS Arc permaneça no estado ScalingControlPlane durante um longo período de tempo.

Para reproduzir

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>

Este problema foi corrigido nas versões recentes do AKS Arc. Recomendamos que atualize os clusters do AKS Arc para a versão mais recente.

Para mitigar este problema, contacte o suporte para corrigir manualmente o estado dos nós do plano de controlo para remover a condição MachineOwnerRemediatedCondition do estado do computador através do kubectl.

O cluster de cargas de trabalho poderá não ser encontrado se os conjuntos de endereços IP de duas implementações do AKS no Azure Stack HCI forem iguais ou se se sobrepõem. Se implementar dois anfitriões do AKS e utilizar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e o Windows Admin Center poderão não conseguir encontrar o cluster de cargas de trabalho porque o servidor de API terá o mesmo endereço IP em ambos os clusters, o que resultará num conflito.

A mensagem de erro que receber terá um aspeto semelhante ao exemplo mostrado abaixo.

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.

Para resolver o problema, elimine um dos clusters e crie uma nova definição de rede de cluster do AKS que tenha uma rede não sobreposta com os outros clusters.

Executar o comando Get-AksHciClusterNetwork fornece uma lista de todas as configurações de rede virtual. No entanto, o comando não mostra a alocação atual dos endereços IP.

Para saber que endereços IP estão atualmente a ser utilizados numa rede virtual, utilize os passos abaixo:

1. Para obter o grupo, execute o seguinte comando:

Get-MocGroup -location MocLocation

2. Para obter a lista de endereços IP atualmente em utilização e a lista de endereços IP virtuais disponíveis ou utilizados, execute o seguinte comando:

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

3. Utilize o seguinte comando para ver a lista de endereços IP virtuais que estão atualmente a ser utilizados:

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

Um endereço IP do cluster é apresentado como "Com falhas" durante a pré-verificação. Esta verificação prévia testa que todos os endereços IPv4 e nomes de rede DNS estão online e acessíveis. Por exemplo, um IPv4 com falha ou um nome de rede pode fazer com que este teste falhe.

Para resolver este problema, execute os seguintes passos:

1. Execute o seguinte comando:

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

2. Certifique-se de que todos os nomes de rede e endereços IP estão num estado online.

3. Execute os dois comandos seguintes:

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

   e, em seguida,

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

Quando implementa o AKS no Azure Stack HCI, a implementação pode exceder o limite de tempo em diferentes pontos do processo, dependendo de onde ocorreu a configuração incorreta. Deve rever a mensagem de erro para determinar a causa e onde ocorreu.

Por exemplo, no seguinte erro, o ponto em que ocorreu a configuração incorreta está em 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"}

Isto indica que o nó físico do Azure Stack HCI consegue resolver o nome do URL de transferência, msk8s.api.cdp.microsoft.com, mas o nó não consegue ligar ao servidor de destino.

Para resolver este problema, tem de determinar onde ocorreu a discriminação no fluxo de ligação. Eis alguns passos para tentar resolver o problema a partir do nó de cluster físico:

1. Enviar ping para o nome DNS de destino: ping msk8s.api.cdp.microsoft.com.
2. Se receber uma resposta de volta e não exceder o tempo limite, o caminho de rede básico está a funcionar.
3. Se a ligação exceder o limite de tempo, poderá existir uma quebra no caminho dos dados. Para obter mais informações, veja Verificar as definições de proxy. Em alternativa, pode haver uma quebra no caminho de retorno, pelo que deve verificar as regras da firewall.

As aplicações dependentes do tempo NTP podem acionar centenas de alertas falsos quando estão fora da sincronização temporal. Se o cluster estiver em execução num ambiente proxy, os conjuntos de nós poderão não conseguir comunicar com o servidor NTP predefinido, time.windows.com, através do proxy ou da firewall.

Solução

Para contornar este problema, atualize a configuração do servidor NTP em cada nó de conjunto de nós para sincronizar os relógios. Ao fazê-lo, também definirá os relógios em cada um dos pods da sua aplicação.

Pré-requisitos

• Um endereço de um servidor NTP acessível em cada nó de conjunto de nós.
• Acesso ao ficheiro kubeconfig do cluster de cargas de trabalho.
• Acesso ao cluster de gestão kubeconfig.

Passos

1. Execute o seguinte kubectl comando com o kubeconfig do cluster de cargas de trabalho para obter uma lista de nós:

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

2. Execute o seguinte kubectl comando para correlacionar os nomes dos nós do comando anterior com os nós do conjunto de nós do cluster de cargas de trabalho. Tome nota dos endereços IP relevantes da saída do comando anterior.

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

3. Com a saída dos passos anteriores, execute os seguintes passos para cada nó de conjunto de nós que precisa da configuração NTP atualizada:

   1. SSH numa VM de nó de conjunto de nós:

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

   2. Verifique se o servidor NTP configurado está inacessível:

      sudo timedatectl timesync-status
      

      Se o resultado for semelhante a este, o servidor NTP está inacessível e tem de ser alterado:

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

   3. Para atualizar o servidor NTP, execute os seguintes comandos para definir o servidor NTP no ficheiro de configuração timesync para um que esteja acessível a partir da VM do conjunto de nós:

      # 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. Reinicie o serviço timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Verifique se o servidor NTP está acessível:

      sudo timedatectl timesync-status
      

   6. Verifique se o relógio mostra a hora correta:

      date
      

4. Certifique-se de que cada nó de conjunto de nós mostra o mesmo tempo ao executar o comando a partir do passo 3.f.

5. Se a aplicação não atualizar automaticamente a hora, reinicie os pods.

Passos seguintes

• Descrição geral da resolução de problemas
• Problemas e erros de instalação
• Problemas conhecidos do armazenamento