Requisitos do sistema para AKS habilitado pelo Azure Arc no Azure Stack HCI 22H2
Aplica-se a: Azure Stack HCI, versões 22H2; Windows Server 2022, Windows Server 2019
Este artigo descreve os requisitos para configurar o Serviço Kubernetes do Azure (AKS) habilitado pelo Azure Arc. Para obter uma visão geral do AKS habilitado pelo Arc, consulte a visão geral do AKS.
Requisitos de Hardware
A Microsoft recomenda a compra de uma solução de hardware/software HCI do Azure Stack validada dos nossos parceiros. Essas soluções são projetadas, montadas e validadas para executar nossa arquitetura de referência e verificar a compatibilidade e a confiabilidade para que você comece a trabalhar rapidamente. Você deve verificar se os sistemas, componentes, dispositivos e drivers que você está usando são certificados do Windows Server de acordo com o Catálogo do Windows Server. Consulte o site de soluções HCI do Azure Stack para obter soluções validadas.
Importante
Os sistemas host para implantações de produção devem ser hardware físico. Não há suporte para virtualização aninhada, caracterizada como implantar o Azure Stack HCI ou o Windows Server em uma máquina virtual e instalar o AKS nessa máquina virtual.
Especificações máximas de hardware suportadas
AKS no Azure Stack HCI e implantações do Windows Server que excedam as seguintes especificações não são suportadas:
| Recurso | Máximo |
|---|---|
| Servidores físicos por cluster | 8 (Azure Stack HCI versão 22H2 e Windows Server) |
| Número total de VMs | 200 |
Requisitos de computação
Requisitos mínimos de memória
Você pode configurar seu cluster AKS da seguinte maneira, para executar o AKS em um único nó Windows Server com RAM limitada:
| Tipo de cluster | Tamanho da VM do plano de controle | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| Anfitrião AKS | Standard_A4_v2 tamanho da VM = 8GB | N/A - O host do AKS não tem nós de trabalho. | 8 GB | N/A - O host AKS usa kubevip para balanceamento de carga. |
| Cluster de carga de trabalho | Standard_A4_v2 tamanho da VM = 8GB | Standard_K8S3_v1 para 1 nó de trabalho = 6GB | Pode reutilizar esses 8 GB reservados para atualização de cluster de carga de trabalho. | N/D se kubevip for usado para balanceamento de carga (em vez do balanceador de carga HAProxy padrão). |
Requisito mínimo total: 30 GB de RAM.
Esse requisito mínimo é para uma implantação do AKS com um nó de trabalho para executar aplicativos em contêineres. Se você optar por adicionar nós de trabalho ou um balanceador de carga HAProxy, o requisito final de RAM será alterado de acordo.
Requisitos de computação recomendados
| Environment | Núcleos de CPU por servidor | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 GB |
| Cluster de failover do Windows Server | 32 | 256 GB |
| Windows Server de nó único | 16 | 128 GB |
Para um ambiente de produção, o dimensionamento final depende do aplicativo e do número de nós de trabalho que você planeja implantar no cluster Azure Stack HCI ou Windows Server. Se você optar por executar o AKS em um Windows Server de nó único, não obterá recursos como alta disponibilidade que vêm com a execução do AKS em um HCI do Azure Stack ou cluster do Windows Server ou cluster de failover do Windows Server.
Outros requisitos de computação para AKS no Azure Stack HCI e Windows Server estão alinhados com os requisitos do Azure Stack HCI. Consulte Requisitos de sistema do Azure Stack HCI para obter mais informações sobre os requisitos do servidor HCI do Azure Stack.
Você deve instalar o mesmo sistema operacional em cada servidor do cluster. Se você estiver usando o Azure Stack HCI, o mesmo sistema operacional e a mesma versão deverão estar no mesmo em cada servidor do cluster. Se você estiver usando o Windows Server Datacenter, o mesmo sistema operacional e a mesma versão deverão ser os mesmos em cada servidor do cluster. Cada sistema operacional deve usar a região en-us e as seleções de idioma. Não é possível alterar essas configurações após a instalação.
Requisitos de armazenamento
O AKS no Azure Stack HCI e no Windows Server dá suporte às seguintes implementações de armazenamento:
| Nome | Tipo de armazenamento | Capacidade necessária |
|---|---|---|
| Cluster HCI do Azure Stack | Volumes compartilhados de cluster | 1 TB |
| Cluster de failover do Windows Server Datacenter | Volumes compartilhados de cluster | 1 TB |
| Datacenter do Windows Server de nó único | Armazenamento com conexão direta | 500 GB |
Para um cluster do Azure Stack HCI ou do Windows Server, há duas configurações de armazenamento com suporte para executar cargas de trabalho de máquina virtual:
- O armazenamento híbrido equilibra o desempenho e a capacidade utilizando armazenamento flash e unidades de disco rígido (HDD).
- O armazenamento totalmente flash maximiza o desempenho usando unidades de estado sólido (SSDs) ou NVMe.
Os sistemas que têm apenas armazenamento baseado em HDD não são suportados pelo Azure Stack HCI e, portanto, não são recomendados para executar o AKS no Azure Stack HCI e no Windows Server. Para obter mais informações sobre as configurações de unidade recomendadas, consulte a documentação do Azure Stack HCI. Todos os sistemas validados no catálogo HCI do Azure Stack se enquadram em uma dessas duas configurações de armazenamento com suporte.
O Kubernetes usa etcd para armazenar o estado dos clusters. O Etcd armazena a configuração, as especificações e o status dos pods em execução. Além disso, o Kubernetes usa a loja para descoberta de serviços. Como um componente de coordenação para a operação do Kubernetes e as cargas de trabalho que ele suporta, a latência e a taxa de transferência para etcd são críticas. Você deve executar o AKS em um SSD. Para obter mais informações, consulte Desempenho em etcd.io.
Para um cluster baseado em Datacenter do Windows Server, você pode implantar com armazenamento local ou armazenamento baseado em SAN. Para armazenamento local, é recomendável usar os Espaços de Armazenamento Diretos integrados ou uma solução SAN virtual certificada equivalente para criar uma infraestrutura hiperconvergente que apresente Volumes Compartilhados de Cluster para uso por cargas de trabalho. Para os Espaços de Armazenamento Direct, é necessário que o seu armazenamento seja híbrido (flash + HDD), que equilibra o desempenho e a capacidade, ou totalmente flash (SSD, NVMe), que maximiza o desempenho. Se você optar por implantar com armazenamento baseado em SAN, certifique-se de que seu armazenamento SAN possa oferecer desempenho suficiente para executar várias cargas de trabalho de máquinas virtuais. O armazenamento SAN baseado em HDD mais antigo pode não fornecer os níveis de desempenho necessários para executar várias cargas de trabalho de máquinas virtuais e poderá ver problemas de desempenho e tempos limites.
Para implantações do Windows Server de nó único usando armazenamento local, o uso de armazenamento totalmente flash (SSD, NVMe) é altamente recomendado para fornecer o desempenho necessário para hospedar várias máquinas virtuais em um único host físico. Sem armazenamento flash, os níveis mais baixos de desempenho nas HDD podem causar problemas de implementação e tempos limites.
Requisitos de rede
Os requisitos a seguir se aplicam a um cluster HCI 22H2 do Azure Stack e a um cluster do Windows Server Datacenter. Para requisitos de rede no Azure Stack HCI 23H2, consulte Requisitos de rede.
- Para o Azure Stack HCI 22H2 e o Windows Server, verifique se você tem um comutador virtual externo existente configurado se estiver usando o Windows Admin Center. Para clusters HCI ou Windows Server, essa opção e seu nome devem ser os mesmos em todos os nós de cluster. Para HCI 23H2, consulte os requisitos de sistema de rede.
- Verifique se você desabilitou o IPv6 em todos os adaptadores de rede.
- Para uma implantação bem-sucedida, os nós de cluster do Azure Stack HCI ou do Windows Server e as VMs de cluster do Kubernetes devem ter conectividade externa com a Internet.
- Certifique-se de que todas as sub-redes definidas para o cluster são roteáveis entre si e para a Internet.
- Verifique se há conectividade de rede entre os hosts HCI do Azure Stack e as VMs locatárias.
- A resolução de nomes DNS é necessária para que todos os nós possam se comunicar entre si.
- (Recomendado) Habilite atualizações dinâmicas de DNS em seu ambiente DNS para permitir que o AKS registre o nome do cluster genérico do agente de nuvem no sistema DNS para descoberta.
Atribuição de endereço IP
No AKS habilitado pelo Arc, as redes virtuais são usadas para alocar endereços IP para os recursos do Kubernetes que os exigem, conforme listado anteriormente. Existem dois modelos de rede para escolher, dependendo da arquitetura de rede AKS desejada.
Nota
A arquitetura de rede virtual definida aqui para suas implantações AKS é diferente da arquitetura de rede física subjacente em seu data center.
- Rede IP estática: A rede virtual aloca endereços IP estáticos para o servidor de API de cluster do Kubernetes, nós do Kubernetes, VMs subjacentes, balanceadores de carga e quaisquer serviços do Kubernetes executados sobre o cluster.
- Rede DHCP: A rede virtual aloca endereços IP dinâmicos para os nós do Kubernetes, VMs subjacentes e balanceadores de carga usando um servidor DHCP. O servidor de API de cluster do Kubernetes e todos os serviços do Kubernetes executados sobre o cluster ainda recebem endereços IP estáticos.
Reserva mínima de endereço IP
No mínimo, você deve reservar o seguinte número de endereços IP para sua implantação:
| Tipo de cluster | Nó do plano de controle | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| AKS Anfitrião | 1 PI | ND | 2 PI | ND |
| Cluster de carga de trabalho | 1 IP por nó | 1 IP por nó | 5 PI | 1 PI |
Além disso, deve reservar o seguinte número de endereços IP para o seu pool VIP:
| Tipo de recurso | Número de endereços IP |
|---|---|
| Servidor de API de cluster | 1 por cluster |
| Serviços do Kubernetes | 1 por serviço |
Como você pode ver, o número de endereços IP necessários é variável, dependendo da arquitetura AKS e do número de serviços que você executa no cluster Kubernetes. Recomendamos reservar um total de 256 endereços IP (/24 sub-rede) para sua implantação.
Para obter mais informações sobre requisitos de rede, consulte Conceitos de rede de nó no AKS e Conceitos de rede de contêiner no AKS.
Requisitos de porta de rede e URL
AKS habilitado pelos requisitos do Arc
Ao criar um cluster Kubernetes no Azure Stack HCI, as seguintes portas de firewall são abertas automaticamente em cada servidor do cluster.
Se os nós de cluster físico do Azure Stack HCI e as VMs de cluster do Azure Kubernetes estiverem em duas vlans isoladas, essas portas deverão ser abertas no firewall entre elas:
| Porta | Origem | Description | Notas de firewall |
|---|---|---|---|
| 22 | AKS VMs | Necessário para coletar logs ao usar Get-AksHciLogso . |
Se estiverem usando VLANs separadas, os hosts Hyper-V físicos devem acessar as VMs AKS nessa porta. |
| 6443 | AKS VMs | Necessário para se comunicar com APIs do Kubernetes. | Se estiverem usando VLANs separadas, os hosts Hyper-V físicos devem acessar as VMs AKS nessa porta. |
| 45000 | Hosts Hyper-V físicos | Servidor gRPC wssdAgent. | Não são necessárias regras de VLAN cruzadas. |
| 45001 | Hosts Hyper-V físicos | Autenticação gRPC wssdAgent. | Não são necessárias regras de VLAN cruzadas. |
| 46000 | AKS VMs | wssdCloudAgent para lbagent. | Se estiverem usando VLANs separadas, os hosts Hyper-V físicos devem acessar as VMs AKS nessa porta. |
| 55000 | Recurso de cluster (-CloudServiceCIDR) | Servidor gRPC do Cloud Agent. | Se usarem VLANs separadas, as VMs AKS devem acessar o IP do recurso de cluster nessa porta. |
| 65000 | Recurso de cluster (-CloudServiceCIDR) | Autenticação gRPC do Cloud Agent. | Se usarem VLANs separadas, as VMs AKS devem acessar o IP do recurso de cluster nessa porta. |
Se a sua rede requer o uso de um servidor proxy para se conectar à Internet, consulte Usar configurações do servidor proxy no AKS.
Os seguintes URLs devem ser adicionados à sua lista de permissões:
| URL | Porta | Notas |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Usado ao baixar o AKS no catálogo de produtos do Azure Local, bits de produtos e imagens do sistema operacional do SFS. Ocorre durante a execução Set-AksHciConfig e sempre que você fizer o download do SFS. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Usado ao baixar o AKS no catálogo de produtos do Azure Local, bits de produtos e imagens do sistema operacional do SFS. Ocorre durante a execução Set-AksHciConfig e sempre que você fizer o download do SFS. |
login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net |
443 | Usado para fazer logon no Azure ao executar Set-AksHciRegistrationo . |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net Ponto de extremidade dos EUA: wus2replica*.blob.core.windows.net |
443 | Necessário para extrair imagens de contêiner durante a execução Install-AksHcido . |
| <região.dp.kubernetesconfiguration.azure.com> | 443 | Necessário para integrar clusters híbridos AKS ao Azure Arc. |
| gbl.his.arc.azure.com | 443 | Necessário para obter o ponto de extremidade regional para obter certificados de Identidade Gerenciada atribuídos pelo sistema. |
| *.his.arc.azure.com | 443 | Necessário para obter certificados de Identidade Gerenciada atribuídos pelo sistema. |
| k8connecthelm.azureedge.net | 443 | O Kubernetes habilitado para Arc usa o Helm 3 para implantar agentes do Azure Arc no AKS no cluster de gerenciamento Local do Azure. Esse ponto de extremidade é necessário para o download do cliente Helm para facilitar a implantação do gráfico de leme do agente. |
| *.arc.azure.net | 443 | Necessário para gerenciar clusters híbridos AKS no portal do Azure. |
| dl.k8s.io | 443 | Necessário para baixar e atualizar binários do Kubernetes para o Azure Arc. |
| akshci.azurefd.net | 443 | Necessário para o AKS na faturação local do Azure durante a execução Install-AksHcido . |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Usado periodicamente para enviar os dados de diagnóstico necessários da Microsoft do host do Azure Local ou do Windows Server. |
Nota
O AKS habilitado pela Arc armazena e processa dados de clientes. Por padrão, os dados do cliente permanecem na região na qual o cliente implanta a instância de serviço. Esses dados são armazenados em datacenters regionais operados pela Microsoft. Para regiões com requisitos de residência de dados, os dados do cliente são sempre mantidos na mesma região.
Requisitos adicionais de URL para recursos do Azure Arc
A lista de URLs anterior abrange as URLs mínimas necessárias para você conectar seu serviço AKS ao Azure para cobrança. Você deve permitir URLs adicionais se quiser usar a conexão de cluster, locais personalizados, RBAC do Azure e outros serviços do Azure, como o Azure Monitor, etc., em seu cluster de carga de trabalho AKS. Para obter uma lista completa de URLs do Arc, consulte Requisitos de rede do Kubernetes habilitados para Azure Arc.
Você também deve examinar as URLs HCI do Azure Stack. Como o Arc for server agents agora está instalado por padrão nos nós HCI do Azure Stack do Azure Stack HCI 21H2 e superiores, você também deve revisar o Arc para URLs de agentes de servidor.
Aglomerados esticados no AKS
Conforme descrito na visão geral de clusters estendidos, não há suporte para a implantação do AKS no Azure Stack HCI e no Windows Server usando clusters estendidos do Windows. Recomendamos que você use uma abordagem de backup e recuperação de desastres para a continuidade operacional do datacenter. Para obter mais informações, consulte Executar backup ou restauração de cluster de carga de trabalho usando Velero e armazenamento de Blob do Azure no Azure Stack HCI e Windows Server e Implantar configurações no AksHci usando GitOps com Flux v2 para continuidade de aplicativos.
Requisitos do Windows Admin Center
O Windows Admin Center é a interface do usuário para criar e gerenciar o AKS habilitado pelo Azure Arc. Para usar o Windows Admin Center com o AKS no Azure Stack HCI e no Windows Server, você deve atender a todos os critérios da lista a seguir.
Estes são os requisitos para a máquina que executa o gateway do Windows Admin Center:
- Windows 10 ou Windows Server.
- Registrado no Azure.
- No mesmo domínio que o cluster Azure Stack HCI ou Windows Server Datacenter.
- Uma assinatura do Azure na qual você tem direitos de proprietário. Você pode verificar seu nível de acesso navegando até sua assinatura e selecionando Controle de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecionando Exibir meu acesso.
Requisitos do Azure
Você deve se conectar à sua conta do Azure.
Conta e subscrição do Azure
Se ainda não tiver uma conta do Azure, crie uma. Pode utilizar uma subscrição existente de qualquer tipo:
- Conta gratuita com créditos do Azure para estudantes ou subscritores do Visual Studio.
- Subscrição pré-paga com cartão de crédito.
- Subscrição obtida através de um Enterprise Agreement (EA).
- Subscrição obtida através do programa Cloud Solution Provider (CSP).
Permissões, função e nível de acesso do Microsoft Entra
Você deve ter permissões suficientes para registrar um aplicativo com seu locatário do Microsoft Entra.
Para verificar se você tem permissões suficientes, siga as informações abaixo:
- Vá para o portal do Azure e selecione Funções e administradores em ID do Microsoft Entra para verificar sua função.
- Se sua função for Usuário, você deve certificar-se de que os não-administradores podem registrar aplicativos.
- Para verificar se você pode registrar aplicativos, vá para Configurações do usuário no serviço Microsoft Entra para verificar se você tem permissão para registrar um aplicativo.
Se a configuração de registros de aplicativos estiver definida como Não, somente os usuários com uma função de administrador poderão registrar esses tipos de aplicativos. Para saber mais sobre as funções de administrador disponíveis e as permissões específicas na ID do Microsoft Entra que são dadas a cada função, consulte Funções internas do Microsoft Entra. Se a sua conta tiver a função de Utilizador , mas a definição de registo da aplicação estiver limitada a utilizadores administradores, peça ao administrador para lhe atribuir uma das funções de administrador que podem criar e gerir todos os aspetos dos registos de aplicações ou para permitir que os utilizadores registem aplicações.
Se você não tiver permissões suficientes para registrar um aplicativo e seu administrador não puder lhe dar essas permissões, a maneira mais fácil de implantar o AKS é pedir ao administrador do Azure para criar uma entidade de serviço com as permissões certas. Os administradores podem verificar a seção a seguir para saber como criar uma entidade de serviço.
Função de assinatura do Azure e nível de acesso
Para verificar o seu nível de acesso, navegue até à sua subscrição, selecione Controlo de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecione Ver o meu acesso.
- Se estiver a utilizar o Windows Admin Center para implementar um anfitrião AKS ou um cluster de carga de trabalho AKS, tem de ter uma subscrição do Azure na qual seja Proprietário.
- Se você estiver usando o PowerShell para implantar um host AKS ou um cluster de carga de trabalho AKS, o usuário que registrar o cluster deverá ter pelo menos uma das seguintes opções:
- Uma conta de usuário com a função Proprietário interna.
- Uma entidade de serviço com um dos seguintes níveis de acesso:
- A função interna de Colaborador .
- A função de Proprietário incorporada.
Se a sua subscrição do Azure for através de um EA ou CSP, a forma mais fácil de implementar o AKS é pedir ao administrador do Azure para criar uma entidade de serviço com as permissões certas. Os administradores podem verificar a seção a seguir sobre como criar uma entidade de serviço.
Opcional: criar uma nova entidade de serviço
Execute as etapas a seguir para criar uma nova entidade de serviço com a função Proprietário interna. Somente os proprietários de assinaturas podem criar entidades de serviço com a atribuição de função correta. Pode verificar o seu nível de acesso navegando até à sua subscrição, selecionando Controlo de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecionando Ver o meu acesso.
Defina as seguintes variáveis do PowerShell em uma janela de administração do PowerShell. Verifique se a assinatura e o locatário são o que você deseja usar para registrar seu host AKS para cobrança:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Instale e importe o módulo AKS PowerShell:
Install-Module -Name AksHci
Entre no Azure usando o comando Connect-AzAccount PowerShell:
Connect-AzAccount -tenant $tenantID
Defina a assinatura que você deseja usar para registrar seu host AKS para cobrança como a assinatura padrão executando o comando Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Verifique se o contexto de entrada está correto executando o comando Get-AzContext PowerShell. Verifique se a assinatura, o locatário e a conta são o que você deseja usar para registrar seu host AKS para cobrança:
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Crie uma entidade de serviço executando o comando New-AzADServicePrincipal PowerShell. Este comando cria uma entidade de serviço com a função Proprietário e define o escopo em um nível de assinatura. Para obter mais informações sobre como criar entidades de serviço, consulte Criar uma entidade de serviço do Azure com o Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Recupere a senha da entidade de serviço executando o seguinte comando. Note que este comando só funciona para Az.Accounts 2.6.0 ou inferior. Baixamos automaticamente o módulo Az.Accounts 2.6.0 quando você instala o módulo AksHci PowerShell:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
A partir da saída anterior, agora você tem o ID do aplicativo e o segredo disponíveis ao implantar o AKS. Você deve anotar esses itens e armazená-los com segurança. Com isso criado, no portal do Azure, em Assinaturas, Controle de Acesso e, em seguida, Atribuições de Função, você verá sua nova entidade de serviço.
Grupo de recursos do Azure
Você deve ter um grupo de recursos do Azure na região do Azure Leste da Austrália, Leste dos EUA, Sudeste Asiático ou Europa Ocidental disponível antes do registro.
Regiões do Azure
Aviso
Atualmente, o AKS Arc oferece suporte à criação de clusters exclusivamente nas seguintes regiões especificadas do Azure. Se você tentar implantar em uma região fora dessa lista, ocorrerá uma falha de implantação.
O serviço AKS Arc é usado para registro, faturamento e gerenciamento. Atualmente é suportado nas seguintes regiões:
- E.U.A. Leste
- E.U.A. Centro-Sul
- Europa Ocidental
Requisitos do Ative Directory
Para que um cluster de failover AKS com 2 ou mais nós físicos funcione de forma ideal em um ambiente do Ative Directory, verifique se os seguintes requisitos são atendidos:
Nota
O Ative Directory não é necessário para implantações de nó único, Azure Stack, HCI ou Windows Server.
- Configure a sincronização de tempo para que a divergência não seja superior a 2 minutos em todos os nós do cluster e no controlador de domínio. Para obter informações sobre como definir a sincronização de tempo, consulte Serviço de tempo do Windows.
- Verifique se a(s) conta(s) de usuário usada(s) para adicionar, atualizar e gerenciar clusters AKS ou Windows Server Datacenter tem as permissões corretas no Ative Directory. Se você estiver usando Unidades Organizacionais (UOs) para gerenciar políticas de grupo para servidores e serviços, a(s) conta(s) de usuário exigirá permissões de lista, leitura, modificação e exclusão em todos os objetos na UO.
- Use uma unidade organizacional (UO) separada para os servidores e serviços de seus clusters AKS ou Windows Server Datacenter. Usar uma UO separada permite controlar o acesso e as permissões com mais granularidade.
- Se você estiver usando modelos de GPO em contêineres no Ative Directory, verifique se a implantação do AKS no Azure Stack HCI e no Windows Server está isenta da política.
Próximos passos
Depois de satisfazer todos os pré-requisitos acima, você pode configurar um host AKS no Azure Stack HCI usando: