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 -imageDirparâmetros , -workingDir, -cloudConfigLocationou -nodeConfigLocation 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.

Os clusters conectados ao Azure Arc para Kubernetes podem 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 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 o 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 resolve 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 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. Ela 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 a ID obtida 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 verificar se a propriedade distribution JSON foi definida corretamente.

Sintomas:

• Proxy habilitado no AKS Arc. O serviço WSSDAgent preso no starting estado. Aparece como o seguinte:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> do nó em que o agente do nó está falhando em relaçã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 relaçã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, pois curl não é um cliente GRPC. Curl não fica preso esperando quando você envia o --noproxy sinalizador. 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 com falha no host. As configurações de proxy do 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 as configurações de proxy com falha tenham sido definidas no host e elas tenham sido propagadas para o WSSDAgent após uma atualização ou reinicialização, o que fez com que o WSSDAgent falhasse.

Você precisará corrigir as configurações de proxy alterando 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 gerenciador de serviços e o WSSDAgent peguem o proxy fixo.

Esse erro ocorre porque sempre que o pod CAPH é iniciado, um logon no cloudagent é tentado e o certificado é armazenado no volume de armazenamento temporário, o que limpo em reinicializações de pod. Portanto, sempre que um pod é reiniciado, o certificado é destruído e uma nova tentativa de logon é 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 está 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 é persistente 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 de 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 ainda ocorrer, 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.

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>

Esse problema foi corrigido nas versões recentes do AKS Arc. Recomendamos atualizar seus clusters do AKS Arc para a versão mais recente.

Para atenuar esse problema, entre em contato com o suporte para corrigir manualmente a status dos nós do painel de controle para remover a condição MachineOwnerRemediatedCondition do computador status 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 do AKS no Azure Stack HCI forem iguais ou sobrepostos. Se você implantar dois hosts do AKS e usar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e Windows Admin Center potencialmente falharão ao 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 recebida 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 resolve 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.

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 descobrir quais endereços IP estão sendo usados 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 é mostrado como "Falha" durante a pré-verificação. Essa verificação prévia testa se 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 esse teste falhe.

Para resolve isso, execute as seguintes etapas:

1. Execute o comando a seguir:

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

2. Verifique se todos os nomes de rede e endereços IP estão em um estado online.

3. Execute os dois comandos a seguir:

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

   e, em seguida,

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

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

Por exemplo, no erro a seguir, o ponto no qual 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ó físico do Azure Stack HCI pode resolve o nome da URL de download, msk8s.api.cdp.microsoft.commas o nó não pode se conectar ao servidor de destino.

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

1. Executar ping no nome DNS de destino: ping msk8s.api.cdp.microsoft.com.
2. Se você receber uma resposta de volta e sem tempo limite, o caminho de rede básico estará 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 marcar configurações de proxy. Ou, pode haver uma interrupção no caminho de retorno, portanto, você deve marcar as regras de firewall.

Aplicativos dependentes de tempo 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 nodepools poderão 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ó de nodepool para sincronizar os relógios. Isso definirá os relógios em cada um dos pods de aplicativo também.

Pré-requisitos

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

Etapas

1. Execute o seguinte kubectl comando usando o kubeconfig do cluster de carga de trabalho 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 de nodepool 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ó de nodepool que precisa da configuração NTP atualizada:

   1. SSH em uma VM de nó nodepool:

      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 semelhante a esta, o servidor NTP será inacessível e precisará 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 timesync para um que esteja acessível na VM do nodepool:

      # 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. Verifique se cada nó de nodepool mostra o mesmo tempo executando o comando da etapa 3.f.

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

Próximas etapas

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