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 AKS (Serviço de Kubernetes do Azure) 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 do Azure Stack HCI validada de nossos parceiros. Essas soluções são projetadas, montadas e validadas para executar nossa arquitetura de referência e para marcar compatibilidade e confiabilidade para que você comece a trabalhar rapidamente. Você deve marcar que os sistemas, componentes, dispositivos e drivers que você está usando sejam Certificados pelo Windows Server de acordo com o Catálogo do Windows Server. Consulte o site de soluções do Azure Stack HCI para obter soluções validadas.
Importante
Os sistemas de host para implantações de produção devem ser hardware físico. Não há suporte para a virtualização aninhada, caracterizada como a implantação do Azure Stack HCI ou do Windows Server em uma máquina virtual e a instalação do AKS nessa máquina virtual.
Especificações máximas de hardware com suporte
Não há suporte para as implantações do AKS no Azure Stack HCI e do Windows Server que excedam as seguintes especificações:
| 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 o cluster do AKS da seguinte maneira para executar o AKS em um único nó do Windows Server com RAM limitada:
| Tipo de cluster | Tamanho da VM do painel de controle | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| Host do AKS | Standard_A4_v2 tamanho da VM = 8 GB | N/D – O host do AKS não tem nós de trabalho. | 8GB | N/D – O host do AKS usa kubevip para balanceamento de carga. |
| Cluster de carga de trabalho | Standard_A4_v2 tamanho da VM = 8 GB | Standard_K8S3_v1 para 1 nó de trabalho = 6 GB | Pode reutilizá-lo com 8 GB reservados para a atualização do 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 adequadamente.
Requisitos de computação recomendados
| Ambiente | Núcleos de CPU por servidor | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 GB |
| Cluster de failover do Windows Server | 32 | 256 GB |
| Nó único Windows Server | 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ê está planejando implantar no cluster do Azure Stack HCI ou do 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 cluster do Azure Stack HCI ou windows server ou cluster de failover do Windows Server.
Outros requisitos de computação para o AKS no Azure Stack HCI e no Windows Server estão alinhados com os requisitos do Azure Stack HCI. Confira Requisitos do sistema do Azure Stack HCI para obter mais informações sobre os requisitos de servidor do Azure Stack HCI.
Você deve instalar o mesmo sistema operacional em cada servidor no 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 no 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 no 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 do Azure Stack HCI | Volumes compartilhados do cluster | 1 TB |
| Cluster de failover do Windows Server Datacenter | Volumes compartilhados do cluster | 1 TB |
| Datacenter do Windows Server de nó único | Armazenamento anexado direto | 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 usando HDDs (unidades de disco rígido) e armazenamento flash.
- O armazenamento all-flash maximiza o desempenho usando SSDs (unidades de estado sólido) ou NVMe.
Sistemas que têm apenas armazenamento baseado em HDD não têm suporte do 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 do Azure Stack HCI 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 as status de pods em execução. Além disso, o Kubernetes usa o repositório para descoberta de serviço. Como um componente de coordenação para a operação do Kubernetes e as cargas de trabalho compatíveis, 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 o armazenamento local, é recomendável que você use o Espaços de Armazenamento Diretos interno ou uma solução san virtual certificada equivalente para criar uma infraestrutura hiperconvergente que apresente Volumes Compartilhados Clusterizados para uso por cargas de trabalho. Para Espaços de Armazenamento Diretos, é necessário que o armazenamento seja híbrido (flash + HDD) que equilibre o desempenho e a capacidade ou todos os flash (SSD, NVMe) que maximizem o desempenho. Se você optar por implantar com o armazenamento baseado em SAN, verifique se o armazenamento san pode fornecer desempenho suficiente para executar várias cargas de trabalho de máquina virtual. O armazenamento SAN baseado em HDD mais antigo pode não fornecer os níveis necessários de desempenho para executar várias cargas de trabalho de máquina virtual e você pode ver problemas de desempenho e tempos limite.
Para implantações do Windows Server de nó único usando o armazenamento local, o uso de armazenamento all-flash (SSD, NVMe) é altamente recomendável para fornecer o desempenho necessário para hospedar várias máquinas virtuais em um único host físico. Sem o armazenamento flash, os níveis mais baixos de desempenho em HDDs podem causar problemas de implantação e tempos limite.
Requisitos de rede
Os requisitos a seguir se aplicam a um cluster do Azure Stack HCI 22H2 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 Windows Admin Center. Para clusters HCI ou Windows Server, essa opção e seu nome devem ser iguais em todos os nós de cluster. Para HCI 23H2, consulte os requisitos do 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 com a Internet externa.
- Verifique se 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 do Azure Stack HCI e as VMs de locatário.
- A resolução de nomes DNS é necessária para que todos os nós possam se comunicar entre si.
- (Recomendado) Habilite atualizações DNS dinâmicas em seu ambiente DNS para permitir que o AKS registre o nome de 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. Há dois modelos de rede para escolher, dependendo da arquitetura de rede do AKS desejada.
Observação
A arquitetura de rede virtual definida aqui para suas implantações do 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 todos os serviços do Kubernetes executados em cima do 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 kubernetes executados na parte superior do cluster ainda são endereços IP estáticos alocados.
Reserva de endereço IP mínimo
No mínimo, você deve reservar o seguinte número de endereços IP para sua implantação:
| Tipo de cluster | Nó do painel de controle | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| AKS Host | 1 IP | NA | 2 IP | NA |
| Cluster de carga de trabalho | 1 IP por nó | 1 IP por nó | 5 IP | 1 IP |
Além disso, você deve reservar o seguinte número de endereços IP para seu pool VIP:
| Tipo de recurso | Número de endereços IP |
|---|---|
| Servidor de API de cluster | 1 por cluster |
| Serviços de Kubernetes | 1 por serviço |
Como você pode ver, o número de endereços IP necessários é variável dependendo da arquitetura do AKS e do número de serviços executados no cluster do Kubernetes. Recomendamos reservar um total de 256 endereços IP (/24 sub-rede) para sua implantação.
Para obter mais informações sobre os requisitos de rede, consulte Conceitos de rede de nós 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 do Kubernetes no Azure Stack HCI, as seguintes portas de firewall são abertas automaticamente em cada servidor no cluster.
Se os nós de cluster físico do Azure Stack HCI e as VMs de cluster do Kubernetes do Azure estiverem em duas vlans isoladas, essas portas deverão ser abertas no firewall entre elas:
| Porta | Fonte | Descrição | Notas sobre firewall |
|---|---|---|---|
| 22 | AKS VMs | Necessário para coletar logs ao usar Get-AksHciLogs. |
Se estiver usando VLANs separadas, os hosts físicos do Hyper-V deverão acessar as VMs do AKS nessa porta. |
| 6443 | AKS VMs | Necessário para se comunicar com APIs do Kubernetes. | Se estiver usando VLANs separadas, os hosts físicos do Hyper-V deverão acessar as VMs do AKS nessa porta. |
| 45000 | Hosts físicos do Hyper-V | servidor gRPC wssdAgent. | Nenhuma regra de VLAN cruzada é necessária. |
| 45001 | Hosts físicos do Hyper-V | wssdAgent gRPC authentication. | Nenhuma regra de VLAN cruzada é necessária. |
| 46000 | AKS VMs | wssdCloudAgent para lbagent. | Se estiver usando VLANs separadas, os hosts físicos do Hyper-V deverão acessar as VMs do AKS nessa porta. |
| 55000 | Recurso de cluster (-CloudServiceCIDR) | Servidor gRPC do Cloud Agent. | Se estiver usando VLANs separadas, as VMs do AKS deverão acessar o IP do recurso de cluster nessa porta. |
| 65000 | Recurso de cluster (-CloudServiceCIDR) | Autenticação gRPC do Cloud Agent. | Se estiver usando VLANs separadas, as VMs do AKS deverão acessar o IP do recurso de cluster nessa porta. |
Se sua rede exigir o uso de um servidor proxy para se conectar à Internet, consulte Usar configurações de servidor proxy no AKS.
As seguintes URLs devem ser adicionadas à sua lista de permitidos:
| URL | Porta | Observações |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Usado ao baixar o AKS no catálogo de produtos do Azure Stack HCI, bits de produto e imagens do sistema operacional do SFS. Ocorre ao executar Set-AksHciConfig e a qualquer momento que você baixa 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 Stack HCI, bits de produto e imagens do sistema operacional do SFS. Ocorre ao executar Set-AksHciConfig e a qualquer momento que você baixa 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-AksHciRegistration. |
| 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 efetuar pull de imagens de contêiner ao executar Install-AksHci. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | Necessário para integrar clusters híbridos do AKS ao Azure Arc. |
| gbl.his.arc.azure.com | 443 | Necessário para obter o ponto de extremidade regional para extrair certificados da Identidade Gerenciada atribuída pelo sistema. |
| *.his.arc.azure.com | 443 | Necessário para efetuar pull dos certificados de Identidade Gerenciada atribuída pelo sistema. |
| k8connecthelm.azureedge.net | 443 | O Kubernetes habilitado para Arc usa o Helm 3 para implantar agentes do Azure Arc no cluster de gerenciamento do AKS-HCI. Esse ponto de extremidade é necessário para o download do cliente helm para facilitar a implantação do gráfico helm do agente. |
| *.arc.azure.net | 443 | Necessário para gerenciar clusters híbridos do AKS em 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 a cobrança do AKS no Azure Stack HCI ao executar Install-AksHci. |
| v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net | 443 | Usado periodicamente para enviar dados de diagnóstico necessários do host do Azure Stack HCI ou do Windows Server à Microsoft. |
Observação
O AKS habilitado pelo Arc armazena e processa dados do cliente. Por padrão, os dados do cliente permanecem dentro da 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 que você conecte o serviço do 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., no cluster de carga de trabalho do AKS. Para obter uma lista completa de URLs do Arc, consulte Requisitos de rede do Kubernetes habilitado para Azure Arc.
Você também deve examinar AS URLs do Azure Stack HCI. Como o Arc para agentes de servidor agora está instalado por padrão em nós do Azure Stack HCI do Azure Stack HCI 21H2 e superiores, você também deve examinar as URLs do Arc para agentes de servidor.
Clusters estendidos no AKS
Conforme descrito na visão geral dos 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 desastre para a continuidade operacional do datacenter. Para obter mais informações, consulte Executar backup ou restauração de cluster de carga de trabalho usando o Velero e o Armazenamento de Blobs do Azure no Azure Stack HCI e Windows Server e Implantar configurações no AksHci usando o GitOps com o Flux v2 para continuidade do aplicativo.
Requisitos do Windows Admin Center
Windows Admin Center é a interface do usuário para criar e gerenciar o AKS habilitado pelo Azure Arc. Para usar Windows Admin Center com o AKS no Azure Stack HCI e no Windows Server, você deve atender a todos os critérios na lista a seguir.
Esses são os requisitos para o computador que executa o gateway de Windows Admin Center:
- Windows 10 ou Windows Server.
- Registrado no Azure.
- No mesmo domínio que o cluster do Azure Stack HCI ou do Windows Server Datacenter.
- Uma assinatura do Azure na qual você tem direitos de Proprietário. Você pode marcar seu nível de acesso navegando até sua assinatura e selecionando Controle de acesso (IAM) no lado esquerdo do portal do Azure e selecionando Exibir meu acesso.
Requisitos do Azure
Você deve se conectar à sua conta do Azure.
Conta e assinatura do Azure
Se você ainda não tiver uma conta do Azure, crie uma. Você pode usar uma assinatura existente de qualquer tipo:
- Conta gratuita com créditos do Azure para alunos ou assinantes do Visual Studio.
- Assinatura paga conforme o uso com cartão de crédito.
- Assinatura obtida por meio de um EA (Enterprise Agreement).
- Assinatura obtida por meio do programa CSP (Provedor de Soluções na Nuvem).
Microsoft Entra permissões, nível de função e acesso
Você deve ter permissões suficientes para registrar um aplicativo com seu locatário Microsoft Entra.
Para marcar que você tenha permissões suficientes, siga as informações abaixo:
- Vá para o portal do Azure e selecione Funções e administradores em Microsoft Entra ID para marcar sua função.
- Se sua função for Usuário, você deve garantir que os não administradores possam registrar aplicativos.
- Para marcar se você puder registrar aplicativos, acesse Configurações de usuário no serviço Microsoft Entra para marcar se você tiver permissão para registrar um aplicativo.
Se a configuração de registros de aplicativo estiver definida como Não, somente 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 em Microsoft Entra ID que são fornecidas a cada função, confira Microsoft Entra funções internas. Se sua conta receber a função Usuário , mas a configuração de registro do aplicativo for limitada a usuários administradores, peça ao administrador para atribuir uma das funções de administrador que podem criar e gerenciar todos os aspectos dos registros de aplicativo ou para permitir que os usuários registrem aplicativos.
Se você não tiver permissões suficientes para registrar um aplicativo e seu administrador não puder fornecer 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 marcar 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 marcar seu nível de acesso, navegue até sua assinatura, selecione Controle de acesso (IAM) no lado esquerdo do portal do Azure e selecione Exibir meu acesso.
- Se você estiver usando Windows Admin Center para implantar um host do AKS ou um cluster de carga de trabalho do AKS, deverá ter uma assinatura do Azure na qual você é proprietário.
- Se você estiver usando o PowerShell para implantar um host aks ou um cluster de carga de trabalho do AKS, o usuário que está registrando o cluster deverá ter pelo menos um dos seguintes:
- Uma conta de usuário com a função de Proprietário interna.
- Uma entidade de serviço com um dos seguintes níveis de acesso:
- A função colaborador interna.
- A função de Proprietário interna.
Se sua assinatura do Azure for por meio de um EA ou CSP, 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 marcar 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 de Proprietário interna. Somente os proprietários de assinatura podem criar entidades de serviço com a atribuição de função correta. Você pode marcar seu nível de acesso navegando até sua assinatura, selecionando Controle de acesso (IAM) no lado esquerdo do portal do Azure e selecionando em Exibir meu acesso.
Defina as seguintes variáveis do PowerShell em uma janela de administrador do PowerShell. Verifique se a assinatura e o locatário são o que você deseja usar para registrar o host do AKS para cobrança:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Instale e importe o módulo do AKS PowerShell:
Install-Module -Name AksHci
Entre no Azure usando o comando Connect-AzAccount do PowerShell:
Connect-AzAccount -tenant $tenantID
Defina a assinatura que você deseja usar para registrar o host do 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 do PowerShell. Verifique se a assinatura, o locatário e a conta são o que você deseja usar para registrar o host do 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 do PowerShell. Esse 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 Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Recupere a senha da entidade de serviço executando o comando a seguir. Observe que esse comando só funciona para Az.Accounts 2.6.0 ou inferior. Baixamos automaticamente o módulo Az.Accounts 2.6.0 ao instalar o módulo do AksHci PowerShell:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
Na saída anterior, agora você tem a 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 atribuições de função, você deverá ver sua nova entidade de serviço.
Grupo de recursos do Azure
Você deve ter um grupo de recursos do Azure na região Leste da Austrália, Leste dos EUA, Sudeste da Ásia ou Oeste da Europa do Azure disponível antes do registro.
Regiões do Azure
Aviso
Atualmente, o AKS Arc dá suporte à criação de cluster exclusivamente nas regiões do Azure especificadas a seguir. Se você tentar implantar em uma região fora dessa lista, ocorrerá uma falha de implantação.
O serviço do AKS Arc é usado para registro, cobrança e gerenciamento. Atualmente, há suporte para ele nas seguintes regiões:
- Leste dos EUA
- Centro-Sul dos Estados Unidos
- Europa Ocidental
Requisitos do Active Directory
Para que um cluster de failover do AKS com 2 ou mais nós físicos funcione de forma ideal em um ambiente do Active Directory, verifique se os seguintes requisitos são atendidos:
Observação
O Active Directory não é necessário para implantações do Azure Stack HCI ou do Windows Server de nó único.
- Configure a sincronização de tempo para que a divergência não seja maior que 2 minutos em todos os nós de cluster e no controlador de domínio. Para obter informações sobre como definir a sincronização de tempo, consulte Serviço de hora do Windows.
- Verifique se as contas de usuário usadas para adicionar atualização e gerenciar clusters do AKS ou do Windows Server Datacenter têm as permissões corretas no Active Directory. Se você estiver usando UOs (Unidades Organizacionais) para gerenciar políticas de grupo para servidores e serviços, as contas de usuário exigirão lista, permissões de leitura, modificação e exclusão em todos os objetos na UO.
- Use uma UO (unidade organizacional) separada para os servidores e serviços pelos clusters do AKS ou do Windows Server Datacenter. O uso de 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 Active Directory, verifique se a implantação do AKS no Azure Stack HCI e no Windows Server está isenta da política.
Próximas etapas
Depois de atender a todos os pré-requisitos acima, você pode configurar um host do AKS no Azure Stack HCI usando:
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de