Aplica-se a: AKS no Azure Local, AKS no Windows Server Use este tópico para ajudá-lo a solucionar e resolver problemas relacionados à rede com o AKS Arc.
Erro: 'Falha ao iniciar o serviço de cluster genérico do agente de nuvem no cluster de failover. O grupo de recursos de cluster está no estado 'falha'.
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
.
Os clusters conectados ao arco têm a propriedade JSON "distribution" vazia
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:
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 comoaks_workload
.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>",
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"
Verifique se o cluster foi corrigido com êxito executando
az connectedk8s show -g <rg_name> -n <cc_name>
para certificar-se de que a propriedadedistribution
JSON foi definida corretamente.
O serviço WSSDAgent está preso durante a inicialização e não consegue se conectar ao agente de nuvem
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.
CAPH pod não renova certificado
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
Set-AksHciConfig falha com erros do WinRM, mas mostra que o WinRM está configurado corretamente
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.
Cluster AKS Arc preso no estado de provisionamento "ScalingControlPlane"
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 não foi encontrado
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.
Nota
O nome do cluster será diferente.
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.
Get-AksHCIClusterNetwork não mostra a alocação atual de endereços IP
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:
- Para obter o grupo, execute o seguinte comando:
Get-MocGroup -location MocLocation
- 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
- 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
"Endereço IP do cluster x.x.x.x" falha
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:
Execute o seguinte comando:
Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
Certifique-se de que todos os nomes de rede e endereços IP estão em um estado online.
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 com uma rede mal configurada, a implantação atinge o tempo limite em vários pontos
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.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 a partir do nó do cluster físico:
- Execute ping no nome DNS de destino: ping
msk8s.api.cdp.microsoft.com
. - Se você receber uma resposta de volta e nenhum tempo limite, o caminho de rede básico está funcionando.
- 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.
Aplicativos que dependem do tempo do NTP disparam centenas de alertas falsos
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
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
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>
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:
SSH em uma VM de nó do pool de nós:
ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
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
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
Reinicie o serviço timesync:
sudo systemctl restart systemd-timesyncd.service
Verifique se o servidor NTP está acessível:
sudo timedatectl timesync-status
Verifique se o relógio mostra a hora correta:
date
Certifique-se de que cada nó do pool de nós mostra a mesma hora executando o comando da etapa 3.f.
Se o seu aplicativo não atualizar seu tempo automaticamente, reinicie seus pods.