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

O agente de nuvem pode falhar ao iniciar com êxito ao usar nomes de caminho com espaços.

Ao usar Set-AksHciConfig para especificar -imageDirparâmetros , -workingDir, -cloudConfigLocation, ou -nodeConfigLocation com um nome de caminho que contém um caractere de espaço, como D:\Cloud Share\AKS HCI, o serviço de cluster do agente de nuvem falhará ao iniciar com a seguinte mensagem de erro (ou semelhante):

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 esse problema, use um caminho que não inclua espaços, por exemplo, C:\CloudShare\AKS-HCI.

O Azure Arc para clusters conectados ao Kubernetes pode ter o valor da propriedade distribution JSON definido como uma cadeia de caracteres vazia. Para clusters conectados ao AKS Arc, esse valor é definido durante a instalação inicial e nunca é alterado durante o tempo de vida da implantação.

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

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

Veja a seguir um exemplo de saída desse 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 a saída da propriedade JSON distribution retornar uma string vazia, siga estas instruções para corrigir o cluster:

1. Copie a seguinte configuração em um arquivo chamado patchBody.json:

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

   Importante

   Se o cluster for um cluster de gerenciamento do AKS, o valor deverá ser definido como aks_management. Se for um cluster de carga de trabalho, ele deverá ser definido como aks_workload.

2. Na saída JSON obtida acima, copie a ID do cluster conectado. Ele deve aparecer como uma cadeia de caracteres longa no seguinte formato:

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

3. Execute o comando a seguir para corrigir o cluster. O <cc_arm_id> valor deve ser o ID obtido na etapa 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 executando az connectedk8s show -g <rg_name> -n <cc_name> para garantir que a propriedade distribution JSON tenha sido definida corretamente.

Sintomas:

• Proxy habilitado no AKS Arc. O serviço WSSDAgent ficou preso no starting estado. Aparece da seguinte forma:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> do nó em que o agente do nó está falhando em direção ao agente de nuvem está funcionando corretamente no sistema (mesmo quando o wssdagent falha ao iniciar)
• Curl.exe do nó no qual o agente está falhando em direção ao agente de nuvem reproduz o problema e está travando: curl.exe https://<computerIP>:6500
• Para corrigir o problema, passe o --noproxy sinalizador para curl.exe. Curl retorna um erro de from wssdcloudagent. Isso é esperado, pois curl não é um cliente GRPC. Curl não fica preso esperando quando você envia a --noproxy bandeira. Portanto, retornar um erro é considerado um sucesso aqui):

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

É provável que as configurações de proxy tenham sido alteradas para um proxy defeituoso no host. As configurações de proxy para o AKS Arc são variáveis de ambiente herdadas do processo pai no host. Essas configurações só são propagadas quando um novo serviço é iniciado ou um antigo é atualizado ou reinicializado. É possível que configurações de proxy defeituosas tenham sido definidas no host e propagadas para o WSSDAgent após uma atualização ou reinicialização, o que causou a falha do WSSDAgent.

Você precisará corrigir as configurações de proxy alterando as variáveis de ambiente na máquina. Na máquina, 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")

Reinicialize o computador para que o gerenciador de serviços e o WSSDAgent selecionem o proxy fixo.

Esse erro ocorre porque toda vez que o pod CAPH é iniciado, um login no cloudagent é tentado e o certificado é armazenado no volume de armazenamento temporário, que será limpo nas reinicializações do pod. Portanto, toda vez que um pod é reiniciado, o certificado é destruído e uma nova tentativa de login é feita.

Uma tentativa de logon inicia uma rotina de renovação, que renova o certificado quando ele se aproxima da expiração. O pod CAPH decide se um logon é necessário se o certificado estiver disponível ou não. Se o certificado estiver disponível, o logon não será tentado, supondo que a rotina de renovação já esteja lá.

No entanto, em uma reinicialização de contêiner, o diretório temporário não é limpo, portanto, o arquivo ainda é persistido e a tentativa de logon não é feita, fazendo com que a rotina de renovação não seja iniciada. Isso leva à expiração do certificado.

Para atenuar esse problema, reinicie o pod CAPH usando o seguinte comando:

kubectl delete pod pod-name

Ao executar Set-AksHciConfig, você pode 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, esse erro ocorre como resultado de uma alteração no token de segurança do usuário (devido a uma alteração na associação ao grupo), uma alteração de senha ou uma senha expirada. Na maioria dos casos, o problema pode ser corrigido ao fazer logoff do computador e fazer logon novamente. Se o erro persistir, você poderá criar um tíquete de suporte por meio do portal do Azure.

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

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>

Esse problema foi corrigido em versões recentes do AKS Arc. É recomendável atualizar os clusters do AKS Arc para a versão mais recente.

Para atenuar esse problema, entre em contato com o suporte para corrigir manualmente o status dos nós do plano de controle para remover a condição MachineOwnerRemediatedCondition do status do computador por meio de kubectl.

O cluster de carga de trabalho poderá não ser encontrado se os pools de endereços IP de duas implantações locais do AKS no Azure forem iguais ou se sobrepuserem. Se você implantar dois hosts AKS e usar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e o Windows Admin Center potencialmente não conseguirão encontrar o cluster de carga de trabalho porque o servidor de API receberá o mesmo endereço IP em ambos os clusters, resultando em um conflito.

A mensagem de erro que você recebe será 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, exclua um dos clusters e crie uma nova configuração de rede de cluster do AKS que tenha uma rede não sobreposta com os outros clusters.

A execução do 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 descobrir quais endereços IP estão em uso atualmente em uma rede virtual, use as etapas abaixo:

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

Get-MocGroup -location MocLocation

2. Para obter a lista de endereços IP que estão em uso no momento e a lista de endereços IP virtuais disponíveis ou usados, execute o seguinte comando:

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

3. Use o seguinte comando para exibir a lista de endereços IP virtuais que estão em uso no momento:

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

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

Para resolver isso, execute as seguintes etapas:

1. Execute o comando a seguir:

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

2. Certifique-se de que todos os nomes de rede e endereços IP estejam em um estado online.

3. Execute estes dois comandos:

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

   e então

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

Quando você implanta o AKS no Azure Local, a implantação pode atingir o tempo limite em diferentes pontos do processo, dependendo de onde ocorreu a configuração incorreta. Você deve revisar a mensagem de erro para determinar a causa e onde ela ocorreu.

Por exemplo, no erro a seguir, 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"}

Isso indica que o nó local físico do Azure pode resolver o nome da URL de download, msk8s.api.cdp.microsoft.com, mas o nó não pode se conectar ao servidor de destino.

Para resolver esse problema, você precisa determinar onde ocorreu a falha no fluxo de conexão. Aqui estão algumas etapas para tentar resolver o problema no nó do cluster físico:

1. Faça ping no nome DNS de destino: ping msk8s.api.cdp.microsoft.com.
2. Se você receber uma resposta de volta e nenhum tempo limite, o caminho de rede básico está funcionando.
3. Se a conexão atingir o tempo limite, poderá haver uma interrupção no caminho de dados. Para obter mais informações, consulte verificar configurações de proxy. Ou pode haver uma quebra no caminho de retorno, portanto, você deve verificar as regras do firewall.

Os aplicativos dependentes do tempo do NTP podem disparar centenas de alertas falsos quando estão fora do tempo de sincronização. Se o cluster estiver em execução em um ambiente de proxy, seus pools de nós podem não ser capazes de se comunicar com o servidor NTP padrão, time.windows.com, por meio de seu proxy ou firewall.

Solução alternativa

Para contornar esse problema, atualize a configuração do servidor NTP em cada nó do pool de nós para sincronizar os relógios. Isso também definirá os relógios em cada um dos pods de aplicativos.

Pré-requisitos

• Um endereço de um servidor NTP que pode ser acessado em cada nó do pool de nós.
• Acesso ao arquivo kubeconfig do cluster de carga de trabalho.
• Acesso ao cluster de gerenciamento kubeconfig.

Etapas

1. Execute o seguinte kubectl comando usando o cluster de carga de trabalho kubeconfig para obter uma lista de nós nele:

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

2. Execute o comando a seguir kubectl para correlacionar os nomes de nó do comando anterior com os nós do pool de nós do cluster de carga de trabalho. Anote os 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. Usando a saída das etapas anteriores, execute as seguintes etapas para cada nó do pool de nós que precisa de sua configuração NTP atualizada:

   1. SSH em uma VM de nó do pool 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 a saída for assim, o servidor NTP está inacessível e precisa 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 arquivo de configuração de sincronização de tempo para um que seja acessível a partir da VM do pool 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 de sincronização de tempo:

      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ó do pool de nós mostre a mesma hora executando o comando da etapa 3.f.

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

Próximas etapas

• Visão geral de solução de problemas
• Problemas e erros de instalação
• Problemas conhecidos de armazenamento