Resolver problemas e erros durante uma instalação do AKS Arc

Esta mensagem de erro é exibida depois de executar Install-AksHci.

Se você não estiver usando Link Privado, para resolve esse problema, use as seguintes etapas:

1. Abra o PowerShell e execute Uninstall-AksHci.
2. Abra o portal do Azure e navegue até o grupo de recursos usado ao executar Install-AksHci.
3. Verifique se há recursos de cluster conectados que aparecem em um estado Desconectado e inclua um nome mostrado como um GUID gerado aleatoriamente.
4. Exclua esses recursos de cluster.
5. Feche a sessão do PowerShell e abra nova sessão antes de executar Install-AksHci novamente.

Esse erro pode ser causado pelo processo de instalação que tenta violar uma política do Azure que foi definida na assinatura do Azure ou no grupo de recursos fornecido durante o processo de integração do Azure Arc. Esse erro pode ocorrer para usuários que definiram as Políticas do Azure em um nível de assinatura ou grupo de recursos e, em seguida, tentar instalar o AKS no Azure Stack HCI, o que viola um Azure Policy.

Para resolve esse problema, leia a mensagem de erro para entender qual Azure Policy definida pelo administrador do Azure foi violada e modifique a política do Azure fazendo uma exceção à política do Azure. Para saber mais sobre exceções de política, consulte Azure Policy estrutura de isenção.

Um recurso instalado anteriormente permanece em um estado de falha e não foi limpo. Você poderá ver o seguinte erro:

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

Ou você pode ver:

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

Para resolve esse problema, limpo manualmente a função de cluster. Você pode remover o recurso do gerenciador de cluster de failover executando o seguinte cmdlet do PowerShell: Remove-ClusterResource -name <resource name>.

O Install-AksHci cmdlet falha com "Erro GetRelease retornado pela chamada à API: Erro de download de arquivo: incompatibilidade de hash".

1. Abra o PowerShell e execute Uninstall-AksHci.
2. Tente novamente uma instalação.
3. Se o problema persistir, use o -concurrentDownloads parâmetro com Set-AksHciConfig e defina-o como um número menor que o padrão 10 antes de tentar novamente uma instalação. Reduzir o número de downloads simultâneos pode ajudar as redes confidenciais a concluir grandes downloads de arquivos com êxito. Esse parâmetro é uma versão prévia do recurso.

Após a implantação, ao reinicializar os nós do Azure Stack HCI, o relatório do AKS mostrou uma status com falha na cobrança.

Para resolve esse problema, siga as instruções para girar manualmente o token e reiniciar o plug-in KMS.

Depois de executar Install-AksHci, a instalação parou e exibiu a seguinte mensagem de erro:

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
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.]

Há vários motivos pelos quais uma instalação pode falhar com o waiting for API server erro.

A seção a seguir descreve possíveis causas e soluções para esse erro.

Motivo 1: configuração incorreta do gateway de IP Se você estiver usando endereços IP estáticos e receber a seguinte mensagem de erro, confirme se a configuração do endereço IP e do gateway está correta.

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

Para marcar se você tem a configuração certa para seu endereço IP e gateway, execute o seguinte comando:

ipconfig /all

Nas configurações exibidas, confirme a configuração. Você também pode tentar executar ping no gateway de IP e no servidor DNS.

ping <DNS server>

Se esses métodos não funcionarem, use New-AksHciNetworkSetting para alterar a configuração.

Motivo 2: servidor DNS incorreto Se você estiver usando endereços IP estáticos, confirme se o servidor DNS está configurado corretamente. Para verificar o endereço do servidor DNS do host, execute o seguinte comando:

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

Confirme se o endereço do servidor DNS é o mesmo que o endereço usado ao executar New-AksHciNetworkSetting executando o seguinte comando:

Get-MocConfig

Se o servidor DNS tiver sido configurado incorretamente, reinstale o AKS no Azure Stack HCI com o servidor DNS correto. Para obter mais informações, consulte Reiniciar, remover ou reinstalar Serviço de Kubernetes do Azure no Azure Stack HCI .

O problema foi resolvido depois de excluir a configuração e reiniciar a VM com uma nova configuração.

Install-AksHci falha com esse erro porque outro processo está acessando mocstack.cab.

Para resolver esse problema, feche todas as janelas abertas do PowerShell e reabra uma nova janela do PowerShell.

O arquivo não pode ser acessado porque ele está sendo usado por outro processo.

Esse problema pode ser resolvido reiniciando sua sessão do PowerShell. Feche a janela do PowerShell e tente Install-AksHci novamente.

Install-AksHci Falha com esse erro porque os intervalos de pool de IP fornecidos na configuração do AKS no Azure Stack HCI estavam desativados por 1 no CIDR e podem causar falha no CloudAgent. Por exemplo, se a sub-rede 10.0.0.0/21 tiver um intervalo de endereços 10.0.0.0 - 10.0.7.255 e, em seguida, você usar o endereço inicial 10.0.0.1 ou o endereço final 10.0.7.254, isso faria com que o CloudAgent falhasse.

Para solucionar esse problema, execute New-AksHciNetworkSetting e use qualquer outro intervalo de endereços IP válido para o pool de VIP e o pool de nós do Kubernetes. Verifique se os valores usados não estão desativados por 1 no início ou no final do intervalo de endereços.

Ao executar Install-AksHci em uma configuração de nó único, a instalação funcionou, mas ao configurar o cluster de failover, a instalação falha com a mensagem de erro. No entanto, o ping no agente de nuvem mostrou que o CloudAgent era acessível.

Para garantir que todos os nós possam resolve o DNS do CloudAgent, execute o seguinte comando em cada nó:

Resolve-DnsName <FQDN of cloudagent>

Quando a etapa acima for bem-sucedida nos nós, verifique se os nós podem acessar a porta CloudAgent para verificar se um proxy não está tentando bloquear essa conexão e se a porta está aberta. Para fazer isso, execute o seguinte comando em cada nó:

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

O erro decorre de um erro com download.

Se você receber esse erro, deverá usar a versão mais recente do Microsoft Edge ou do Google Chrome e tentar novamente.

Esse erro aparece depois de executar Set-AksHciRegistration em uma instalação do AKS no Azure Stack HCI. O erro indica que os Provedores de Recursos do Kubernetes não estão registrados para o locatário que está conectado no momento.

Para resolve esse problema, execute a CLI do Azure ou as etapas do PowerShell abaixo:

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

O registro leva aproximadamente 10 minutos para ser concluído. Para monitorar o processo de registro, use os comandos a seguir.

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci trava antes Waiting for azure-arc-onboarding to complete de atingir o tempo limite quando:

• Uma entidade de serviço é usada no AKS no Registro do Azure Stack HCI (Set-AksHciRegistration).
• Az.Accounts PowerShell modules version(2.7.x) installed.

Az.Accounts 2.7.x as versões removem o ServicePrincipalSecret e CertificatePassword em PSAzureRmAccount, que é usado pelo AKS no Azure Stack HCI para integração do Azure Arc.

Para reproduzir:

1. Instale Az.Accounts a versão de módulos do PowerShell (>= 2.7.0).
2. Set-AksHciRegistration usando uma entidade de serviço.
3. Install-AksHci.

Comportamento esperado:

1. A instalação do AKS no Azure Stack HCI está em Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding os pods entram em loop de colisão.
3. O Azure-arc-onboarding erro de pods com o seguinte erro:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Para resolver esse problema:

Desinstale os módulos do Az.Accounts com as versões 2.7.x. Execute o seguinte cmdlet:

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

Esse erro ocorre quando o Azure Stack HCI está fora da política. A conexão status no cluster pode mostrar que ele está conectado, mas o log de eventos mostra a mensagem de aviso de que Azure Stack HCI's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Para resolve esse erro, verifique se o cluster está registrado no Azure usando o cmdlet do Get-AzureStackHCI PowerShell disponível em seu computador. O painel do Windows Admin Center também mostra informações de status sobre o registro do Azure do cluster.

Se o cluster já estiver registrado, você deverá exibir o campo LastConnected na saída de Get-Get-AzureStackHCI. Se o campo mostrar que mais de 30 dias se passaram, você deverá tentar resolver a situação usando o cmdlet Sync-AzureStackHCI.

Você também pode validar se cada nó do cluster tem a licença necessária usando o seguinte cmdlet:

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Se o problema não for resolvido após a execução do Sync-AzureStackHCI cmdlet, entre em contato com o suporte da Microsoft.

Esse problema ocorre porque uma instalação com falha pode resultar em recursos vazados que precisam ser limpos antes que você possa instalar novamente.

Se a instalação falhar usando Install-AksHci, você deverá executar Uninstall-AksHci antes de executar Install-AksHci novamente.

Você pode disparar esses erros quando executar Install-AksHci sem executar Set-AksHciConfig primeiro.

Para resolve o erro, execute uninstall-akshci e feche todas as janelas do PowerShell. Abra uma nova sessão do PowerShell e reinicie o processo de instalação do AKS-HCI seguindo a instalação do AKS-HCI usando o PowerShell.

O Set-AksHciConfig cmdlet do PowerShell falha com o erro:

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

Se você estiver usando o AKS com um servidor proxy, talvez tenha usado a URL errada ao definir o valor de URL de proxy HTTPS necessário. Os valores de URL de proxy HTTP e URL de proxy HTTPS são necessários ao configurar o AKS com um servidor proxy, mas é comum precisar de ambos os valores para compartilhar a mesma URL prefixada por HTTP.

Se esse for o caso em seu ambiente, tente as seguintes etapas de mitigação:

1. Feche a janela do PowerShell e abra uma nova.
2. Execute os New-AksHciNetworkSetting cmdlets e New-AksHciProxySetting novamente. Ao executar New-AksHciProxySetting, defina o -https parâmetro com o mesmo valor de URL prefixado por HTTP que você definiu para -http.
3. Execute Set-AksHciConfig e continue.

Quando você implanta o AKS no Azure Stack HCI, a implantação pode acabar 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.com, mas o nó não pode se conectar ao servidor de destino.

Para resolve esse problema, você precisa determinar onde o detalhamento ocorreu 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.

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.

Esse erro geralmente 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 ele ainda falhar, você poderá registrar um problema em problemas do GitHub AKS HCI.

Espera-se que os agentes moc mantenham apenas os últimos 100 logs de agente. Eles devem excluir os logs mais antigos. No entanto, a rotação de log não está acontecendo e os logs continuam sendo acumulados consumindo espaço em disco.

Para reproduzir: Install AksHci e ter um cluster em execução até que o número de logs do agente exceda 100. No momento da criação do nº log, espera-se que os agentes excluam o n-100º log, se existirem.

Como resolver o problema:

1. Modifique os arquivos de logconf do agente de nuvem e dos agentes de nó. A configuração de log do agente de nuvem está localizada em:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   O logconfig do agente do nó está localizado em:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Altere o valor de Limite para 100 e Slots para 100 e salve os arquivos de configuração.

3. Reinicie o agente de nuvem e os agentes de nó para registrar essas alterações.

Essas etapas iniciam a rotação de logs somente depois que 100 novos logs são gerados a partir da reinicialização do agente. Se já houver n logs de agente no momento da reinicialização, a rotação de log será iniciada somente depois que n+100 logs forem gerados.

Ao usar Set-AksHciConfig para especificar -imageDiros parâ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.

Esse erro pode ocorrer quando há um erro de configuração de infraestrutura.

Siga as etapas a seguir para resolver esse erro:

1. Verifique as configurações do servidor DNS do host e as configurações do gateway:

   1. Confirme se o servidor DNS está configurado corretamente. Para verificar o endereço do servidor DNS do host, execute o seguinte comando:

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. Para marcar se o endereço IP e a configuração do gateway estão corretos, execute o comando ipconfig/all.
   3. Tente executar ping no gateway de IP e no servidor DNS.

2. Verifique o serviço CloudAgent para verificar se ele está em execução:

   1. Execute ping no serviço CloudAgent para garantir que ele esteja acessível.
   2. Verifique se todos os nós podem resolve o DNS do CloudAgent executando o seguinte comando em cada nó:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Quando a etapa anterior for bem-sucedida nos nós, verifique se os nós podem alcançar a porta CloudAgent para verificar se um proxy não está tentando bloquear essa conexão e se a porta está aberta. Para fazer isso, execute o seguinte comando em cada nó:

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. Para verificar se o serviço de cluster está em execução para um cluster de failover, você também pode executar o seguinte comando:

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

Isso normalmente indica que o CNO (Objeto de Nome de Cluster) que representa o cluster de failover subjacente no Active Directory Domain Services (AD DS) não tem permissões para criar um VCO (Objeto de Computador Virtual) na UO (Unidade Organizacional) ou no contêiner em que o cluster reside.

Se você não for um administrador de domínio, poderá solicitar que você conceda as permissões CNO à UO ou pré-configure um VCO para o serviço de cluster genérico do agente de nuvem.

Se você for um administrador de domínio, ainda é possível que sua UO ou contêiner não tenha as permissões necessárias. Por exemplo, o modo de imposição, introduzido no KB5008383, pode estar habilitado no Active Directory. Tente o seguinte antes de tentar uma reinstalação.

1. Navegue até Usuários e Computadores do Active Directory.
2. Clique com o botão direito do mouse na UO ou no contêiner em que o cluster reside.
3. Selecione Delegar Controle... para abrir o Assistente de Delegação de Controle.
4. Clique em Avançar> Clique em Adicionar... para abrir a janela Selecionar Usuários, Computadores ou Grupos .
5. Selecione sua escolha de grupo ou usuários para os quais você deseja delegar o controle > Clique em OK.
6. Selecione Criar uma tarefa personalizada para delegar> Clique em Avançar para passar para a página Tipo de Objeto do Active Directory .
7. Selecione Somente os seguintes objetos na pasta> Selecionar Objetos> do computador Selecione Criar objetos selecionados nesta pasta e Excluir objetos selecionados nesta pasta> Clique em Avançar para passar para a página Permissões .
8. Selecione Criar todos os Objetos Filho e Excluir Todos os Objetos Filho na lista de permissões > Clique em Avançar>Concluir

Se uma reinstalação falhar, repita o procedimento acima com as seguintes alterações nas Etapas 7 e 8:

• Etapa 7: selecione Esta pasta, os objetos existentes nesta pasta e a criação de novos objetos nesta pasta> Clique em Avançar.
• Etapa 8: selecione Ler, Gravar, Criar Todos os Objetos Filho e Excluir Todos os Objetos Filho na lista de permissões > Clique em Avançar> Clique em Concluir.

Você pode receber esse erro ao executar Install-AksHci.

Você pode obter mais informações executando $error = Install-AksHci e , em seguida $error[0].Exception.InnerException, .

Os comandos do PowerShell do Aks-Hci não validam a memória disponível no servidor host antes de criar nós do Kubernetes. Esse problema pode levar ao esgotamento da memória e às máquinas virtuais que não são iniciadas. No momento, essa falha não é tratada normalmente e a implantação deixará de responder sem nenhuma mensagem de erro clara.

Se você tiver uma implantação que pare de responder, abra Visualizador de Eventos e marcar para uma mensagem de erro relacionada ao Hyper-V indicando que não há memória suficiente para iniciar a VM.

Esse erro pode ocorrer quando você tem vários locatários em sua conta do Azure.

Use $tenantId = (Get-AzContext).Tenant.Id para definir o locatário certo. Em seguida, inclua esse locatário como um parâmetro durante a execução de Set-AksHciRegistration.

Ao tentar implantar um cluster do AKS em uma VM do Azure, a instalação ficou paralisada em e, em Waiting for pod 'Cloud Operator' to be ready...seguida, falhou e atingiu o tempo limite após duas horas. As tentativas de solucionar problemas verificando o gateway e o servidor DNS mostraram que estavam funcionando adequadamente. Verifica se há conflitos de endereços IP ou MAC que não encontraram nenhum. Os logs não mostraram o pool vip. Houve uma restrição ao pull da imagem de contêiner usando sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 que retornava um tempo limite de TLS (Transport Layer Security) em vez de não autorizado.

Para resolve esse problema, execute as seguintes etapas:

1. Comece a implantar o cluster.
2. Quando o cluster for implantado, conecte-se à VM do cluster de gerenciamento por meio do SSH, conforme mostrado abaixo:

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. Altere a configuração de MTU (unidade de transmissão máxima). Não hesite em fazer a alteração; se você fizer a alteração tarde demais, a implantação falhará. Modificar a configuração de MTU ajuda a desbloquear o pull da imagem de contêiner.

sudo ifconfig eth0 mtu 1300

4. Para exibir o status de seus contêineres, execute o seguinte comando:

sudo docker ps -a

Depois de executar essas etapas, o pull da imagem de contêiner deve ser desbloqueado.

Esse erro indica que o endereço IP do serviço de nuvem não faz parte da rede de cluster e não corresponde a nenhuma das redes de cluster que têm a client and cluster communication função habilitada.

Para resolve esse problema, execute Get-ClusterNetwork em que Role é ClusterAndClientigual a . Em seguida, em um dos nós de cluster, selecione o nome, o endereço e a máscara de endereço para verificar se o endereço IP fornecido para o -cloudServiceIP parâmetro New-AksHciNetworkSetting corresponde a uma das redes exibidas.

Próximas etapas

• Visão geral de solução de problemas
• Problemas conhecidos do Windows Admin Center
• Solucionar problemas de clusters do Kubernetes

Se você continuar tendo problemas ao usar o AKS Arc, poderá arquivar bugs por meio do GitHub.