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

Essa mensagem de erro aparece após a execução do Install-AksHci.

Se você não estiver usando o Link Privado, para resolver 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-AksHcio .
3. Verifique se há recursos de cluster conectados que aparecem em um estado Desconectado e incluem um nome mostrado como um GUID gerado aleatoriamente.
4. Exclua esses recursos de cluster.
5. Feche a sessão do PowerShell e abra uma nova sessão antes de executar Install-AksHci novamente.

Esse erro pode ser causado pelo processo de instalação tentando 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 Azure Policies em um nível de assinatura ou grupo de recursos e, em seguida, tentam instalar o AKS no Azure Local, o que viola um Azure Policy.

Para resolver esse problema, leia a mensagem de erro para entender qual Azure Policy definido pelo administrador do Azure foi violado e, em seguida, modifique a política do Azure fazendo uma exceção à política do Azure. Para saber mais sobre exceções de política, consulte Estrutura de isenção do Azure Policy.

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 resolver esse problema, limpe 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 por 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 redes confidenciais a concluir downloads de arquivos grandes com êxito. Esse parâmetro é um recurso de visualização.

Após a implantação, ao reinicializar os nós locais do Azure, o relatório do AKS mostrou um status de falha para cobrança.

Para resolver esse problema, siga as instruções para girar manualmente o token e reiniciar o plug-in do 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 as possíveis causas e soluções para esse erro.

Motivo 1: configuração incorreta do gateway 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 verificar se você tem a configuração correta para seu endereço IP e gateway, execute o seguinte comando:

ipconfig /all

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

ping <DNS server>

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

Razão 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, use 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 durante a execução New-AksHciNetworkSetting executando o seguinte comando:

Get-MocConfig

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

O problema foi resolvido após a exclusão da configuração e a reinicialização da VM com uma nova configuração.

Install-AksHci falhou com este 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 falhou com esse erro porque os intervalos do pool de IPs fornecidos na configuração local do AKS no Azure foram desativados por 1 no CIDR e podem fazer com que o CloudAgent falhe. 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 contornar esse problema, execute New-AksHciNetworkSetting e use qualquer outro intervalo de endereços IP válido para o pool VIP e o pool de nós do Kubernetes. Certifique-se de que os valores usados não estejam desativados em 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 do agente de nuvem mostrou que o CloudAgent estava acessível.

Para garantir que todos os nós possam resolver 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 o download.

Se você receber esse erro, use a versão mais recente do Microsoft Edge ou Google Chrome e tente novamente.

Esse erro aparece após a execução de Set-AksHciRegistration em uma instalação local do AKS no Azure. 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 resolver 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 Local do Azure (Set-AksHciRegistration).
• Az.Accounts versão dos módulos do PowerShell (2.7.x) instalada.

Az.Accounts 2.7.x versions remove o ServicePrincipalSecret e CertificatePassword em PSAzureRmAccount, que é usado pelo AKS no Azure Local para integração do Azure Arc.

Reproduzir:

1. Instale a Az.Accounts versão dos 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 Local trava em Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding pods entra em loop de falha.
3. O Azure-arc-onboarding erro dos pods com o seguinte erro:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Para resolver o problema:

Desinstale os módulos 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 Local está fora da política. O status da conexão no cluster pode mostrar que ele está conectado, mas o log de eventos mostra a mensagem de aviso de que Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Para resolver esse erro, verifique se o cluster está registrado no Azure usando o Get-AzureStackHCI cmdlet do 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 Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

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

MS-HCIv2-03   Azure Local             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 cmdlet, você deverá entrar em contato com o Sync-AzureStackHCI 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 ao executar Install-AksHci sem executar Set-AksHciConfig primeiro.

Para resolver 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 no Azure Local seguindo a instalação do AKS no Azure Local 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 do 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-AksHciProxySettingo , defina o -https parâmetro com o mesmo valor de URL com prefixo HTTP que você definiu para -http.
3. Corra Set-AksHciConfig e prossiga.

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.

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 ainda falhar, você poderá registrar um problema em GitHub AKS Azure Local issues.

Espera-se que os agentes do Moc mantenham apenas os últimos 100 registros do agente. Eles devem excluir os logs mais antigos. No entanto, a rotação de logs 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 enésimo log, espera-se que os agentes excluam o n-100º log, se existirem.

Como resolver o problema:

1. Modifique os arquivos logconf do agente de nuvem e dos agentes de nó. O logconfig do agente de nuvem está localizado em:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   O logconfig do agente de 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 log 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 começará somente depois que n+100 logs forem gerados.

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.

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

Siga as etapas a seguir para resolver esse erro:

1. Verifique a configuração 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 verificar 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. Certifique-se de que todos os nós possam resolver 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 AD DS (Active Directory Domain Services) 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 um conceda permissões ao CNO para a 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 ser 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 aos quais você deseja delegar o controle > Clique em OK.
6. Selecione Criar uma tarefa personalizada para delegar> Clique em Avançar para ir para a página Tipo de Objeto do Active Directory.
7. Selecione Somente os seguintes objetos na pasta> Selecionar objetos> de computador Selecione Criar objetos selecionados nesta pasta e Excluir objetos selecionados nesta pasta> Clique em Avançar para ir para a página Permissões.
8. Selecione Criar todos os objetos filho e Excluir todos os objetos filho da lista de permissões > Clique em Avançar>Concluir

Se uma reinstalação falhar, tente novamente com as seguintes alterações nas etapas 7 e 8:

• Passo 7: Selecione Esta pasta, objetos existentes nesta pasta e 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 da 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 Aks-Hci do PowerShell 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 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 o Visualizador de Eventos e verifique se há 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 correto. Em seguida, inclua esse locatário como um parâmetro ao executar Set-AksHciRegistration.

Ao tentar implantar um cluster do AKS em uma VM do Azure, a instalação foi travada 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 eles estavam funcionando adequadamente. Verifica se há conflitos de endereço IP ou MAC não encontrou nenhum. Os registros não mostravam o pool VIP. Havia uma restrição na extração 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 resolver esse problema, execute as seguintes etapas:

1. Comece a implantar seu 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 da unidade máxima de transmissão (MTU). Não hesite em fazer a mudança; 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 do 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 do 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 resolver esse problema, execute Get-ClusterNetwork onde Role é ClusterAndClientigual a . Em seguida, em um dos nós do 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.

Enable-AksHciArcConnection pode conectar um cluster do AKS ao Azure, mas mostra o seguinte aviso quando o cliente usa uma entidade de serviço para autenticação:

WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS on Azure Local cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

O comportamento atual da integração do Arc é habilitar locais personalizados por padrão. Para habilitar locais personalizados, a ação GetServicePrincipals é executada no contexto do usuário conectado do Azure. Se o usuário (ou SPN) não tiver permissões suficientes para poder fazer isso, o comando emitirá um aviso de que essas permissões não existem e, portanto, o recurso Locais Personalizados não será habilitado.

Se você não quiser que os Locais Personalizados sejam habilitados, poderá ignorar esse aviso com segurança, pois isso não afeta a integração do cluster ao Arc. Por outro lado, se você precisar que os Locais Personalizados sejam habilitados, deverá conceder as permissões necessárias ao usuário (ou SPN).

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 a ter problemas ao usar o AKS Arc, poderá registrar bugs por meio do GitHub.