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

Esta mensagem de erro aparece depois de executar Install-AksHci.

Se você não estiver usando o Private Link, 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 apareçam 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 uma nova sessão antes de executar Install-AksHci novamente.

Este erro pode ser causado pelo processo de instalação que tenta violar uma política do Azure que foi definida na subscrição do Azure ou no grupo de recursos fornecido durante o processo de integração do Azure Arc. Este erro pode ocorrer para utilizadores que definiram Políticas do Azure a nível de subscrição ou de grupo de recursos e, em seguida, tentam instalar o AKS no Azure Local que viola uma Política do Azure.

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

Uma funcionalidade instalada anteriormente permanece num estado de falha e não foi limpa. 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 de API: Erro de download de arquivo: incompatibilidade de hash".

1. Abra o PowerShell e execute Uninstall-AksHcio .
2. Tente instalar novamente.
3. Se o problema persistir, use o -concurrentDownloads parâmetro com Set-AksHciConfig e defina-o para um número inferior ao padrão 10 antes de tentar novamente uma instalação. Reduzir o número de downloads simultâneos pode ajudar redes sensíveis a concluir downloads de arquivos grandes com êxito. Este parâmetro é um recurso de visualização.

Após a implantação, ao reinicializar os nós locais do Azure, o relatório 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 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árias razões pelas 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 IP Se você estiver usando endereços IP estáticos e tiver recebido 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 executar 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.

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, 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 Kubernetes do Azure no Azure Local .

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.cabo .

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

Não é possível aceder ao ficheiro porque está a ser utilizado por outro processo.

Pode resolver este problema ao reiniciar a sessão do PowerShell. Feche a janela do PowerShell e tente Install-AksHci novamente.

Install-AksHci falhou com esse erro porque os intervalos de pool de IP fornecidos na configuração AKS on Azure Local foram desativados por 1 no CIDR e podem causar falha no CloudAgent. Por exemplo, se tiver a sub-rede 10.0.0.0/21 com um intervalo de endereços 10.0.0.0 – 10.0.7.255 e utilizar o endereço inicial de 10.0.0.1 ou um endereço final de 10.0.7.254, tal fará com que o CloudAgent falhe.

Para contornar esse problema, execute New-AksHciNetworkSetting e use qualquer outro intervalo de endereços IP válido para seu pool VIP e pool de nós Kubernetes. Certifique-se de que os valores que você usa 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 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 do 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 do Google Chrome e tente novamente.

Este erro aparece depois de executar Set-AksHciRegistration em uma instalação AKS no Azure Local. 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 registo demora aproximadamente 10 minutos a concluir. Para monitorar o processo de registro, use os seguintes comandos.

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 do tempo limite quando:

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

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

Para 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 colisão.
3. O Azure-arc-onboarding erro pods com o seguinte erro:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Para resolver este problema:

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

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

Este 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 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 sua máquina. O dashboard do Windows Admin Center também mostra informações sobre o estado do registo no Azure do cluster.

Se o cluster já estiver registado, deverá ver o campo LastConnected na saída de Get-AzureStackHCI. Se o campo mostrar que já passaram mais de 30 dias desde a última ligação, deverá tentar resolver a situação com 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 depois de executar o cmdlet, entre em contato com o Sync-AzureStackHCI suporte da Microsoft.

Esse problema acontece 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ê deve executar Uninstall-AksHci antes de executar Install-AksHci novamente.

Você pode acionar esses erros quando 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 estiver a utilizar o AKS com um servidor proxy, poderá ter utilizado o URL errado ao definir o valor do 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-AksHciProxySettingo , defina o -https parâmetro com o mesmo valor de URL prefixado por 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. 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.

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.

Geralmente, este erro ocorre como resultado de uma alteração no token de segurança do utilizador (devido a uma alteração na associação ao grupo), uma alteração de palavra-passe ou uma palavra-passe expirada. Na maioria dos casos, o problema pode ser remediado ao terminar e reiniciar sessão no computador. Se ainda falhar, você pode registrar um problema no GitHub AKS Azure Local issues.

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

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

Para 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 do nó está localizado em:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Altere o valor de Limit 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 logs será iniciada somente depois que n+100 logs forem gerados.

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.

Este erro pode ocorrer quando há uma configuração incorreta da infraestrutura.

Utilize os passos seguintes para resolver este erro:

1. Verifique a configuração do servidor DNS 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 anfitrião, 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 enviar um ping ao gateway IP e ao servidor DNS.

2. Verifique o serviço CloudAgent para se certificar de que está em execução:

   1. Envie um ping ao serviço CloudAgent para garantir que está acessível.
   2. Certifique-se de que todos os nós podem resolver o DNS do CloudAgent executando o seguinte comando em cada nó:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Quando o passo anterior for bem-sucedido nos nós, certifique-se de que estes podem aceder à porta do CloudAgent para verificar se um proxy não está a tentar bloquear esta ligação e a porta está aberta. Para tal, 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 Objeto de Nome de Cluster (CNO) que representa o cluster de failover subjacente nos Serviços de Domínio Ative Directory (AD DS) não tem permissões para criar um Objeto de Computador Virtual (VCO) na Unidade Organizacional (UO) ou no contêiner onde o cluster reside.

Se você não for um administrador de domínio, poderá pedir a um para conceder as permissões CNO à UO ou pré-configurar 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 Ative Directory. Tente o seguinte antes de tentar uma reinstalação.

1. Navegue até Usuários e Computadores do Ative Directory.
2. Clique com o botão direito do mouse na UO ou no contêiner onde 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 Ative 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 ir 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 Próximo>Término

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

• Etapa 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 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 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 máquinas virtuais que não iniciam. 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 para 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 certo. Em seguida, inclua esse locatário como um parâmetro ao executar Set-AksHciRegistration.

Ao tentar implantar um cluster AKS em uma VM do Azure, a instalação foi bloqueada no 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ços IP ou MAC que não foram encontrados. Os registros não mostravam o pool VIP. Havia uma restrição em extrair a imagem do contêiner usando sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 que retornava um tempo limite 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 a extração de 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 de 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 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 do Azure conectado. Se o usuário (ou SPN) não tiver permissões suficientes para 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 ativados, ignore 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óximos passos

• Descrição geral da resolução de problemas
• Problemas conhecidos do Windows Admin Center
• Troubleshooting Kubernetes clusters (Resolver problemas dos clusters do Kubernetes)

Se você continuar a ter problemas quando estiver usando o AKS Arc, poderá arquivar bugs através do GitHub.