Corrigir problemas e erros conhecidos 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 neles.

Ao usar Set-AksHciConfig para especificar -imageDir, -workingDir, -cloudConfigLocation, ou -nodeConfigLocation parâmetros com um nome de caminho que contenha 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

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 a saída da propriedade JSON distribution retornar uma cadeia de caracteres 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 AKS, o valor deverá ser definido como aks_management. Se for um cluster de carga de trabalho, ele deve ser definido como aks_workload.

2. A partir da saída JSON obtida acima, copie o 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 seguinte comando 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 certificar-se de que a propriedade distribution JSON foi definida corretamente.

Sintomas:

• Proxy ativado 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ó em que o agente está falhando em direção ao agente de nuvem reproduz o problema e está ficando preso: curl.exe https://<computerIP>:6500
• Para corrigir o problema, passe o --noproxy sinalizador para curl.exe. Curl retorna um erro de wssdcloudagent. Isso é esperado, uma vez que a 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 tenham sido 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 ambientais 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 a máquina para que o gerenciador de serviços e o WSSDAgent peguem 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 login inicia uma rotina de renovação, que renova o certificado quando ele se aproxima do vencimento. O pod CAPH decide se um login é necessário se o certificado está disponível ou não. Se o certificado estiver disponível, o login não é 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 é persistente e a tentativa de login 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 remediado ao terminar e reiniciar sessão no computador. Se o erro ainda ocorrer, você poderá criar um tíquete de suporte por meio do portal do Azure.

Esse problema faz com que um cluster 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. Recomendamos atualizar seus clusters AKS Arc para a versão mais recente.

Para atenuar esse problema, contate o suporte para corrigir manualmente o status dos nós do plano de controle para remover a condição MachineOwnerRemediatedCondition do status da máquina via kubectl.

O cluster de carga de trabalho pode não ser encontrado se os pools de endereços IP de dois AKS em implantações do Azure Local forem os mesmos ou se sobreporem. 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 localizar 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 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 atualmente em uso 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 atualmente em uso 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. Esta 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 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 em um estado online.

3. Execute os seguintes dois comandos:

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

   E depois

   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. Deve rever a mensagem de erro para determinar a causa e onde ocorreu.

Por exemplo, no seguinte erro, o ponto em que a configuração incorreta ocorreu 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 do Azure físico pode resolver o nome da URL de download, msk8s.api.cdp.microsoft.commas 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 a partir do nó do cluster físico:

1. Execute 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 expirar, pode haver uma quebra no caminho de dados. Para obter mais informações, consulte verificar as configurações de proxy. Ou, pode haver uma quebra no caminho de retorno, então você deve verificar as regras de firewall.

Os aplicativos que dependem do tempo do NTP podem disparar centenas de alertas falsos quando estão fora de sincronia. Se o cluster estiver sendo executado em um ambiente proxy, seus nodepools talvez não consigam se comunicar com o servidor NTP padrão, time.windows.com, por meio de seu proxy ou firewall.

Solução

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 ajustará os relógios em cada um dos seus pods de aplicação.

Pré-requisitos

• Um endereço de um servidor NTP acessível em cada nó do pool de nós.
• Acesso ao arquivo kubeconfig do cluster de carga de trabalho.
• Acesso ao cluster de gerenciamento kubeconfig.

Passos

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 aos 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 tiver esta aparência, 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 do timesync 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 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ó do pool de nós mostra a mesma hora executando o comando da etapa 3.f.

5. Se o seu aplicativo não atualizar seu tempo automaticamente, reinicie seus pods.

Próximos passos

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