Requisitos do sistema para o 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 comprar uma solução de hardware/software validada do Azure Stack HCI de 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 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 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 suportadas
Não há suporte para 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ó 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 |
|---|---|---|---|---|
| Host do AKS | Standard_A4_v2 Tamanho da VM = 8 GB | N/A – O host do AKS não tem nós de trabalho. | 8GB | N/A – 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 reutilizar esses 8 GB reservados para atualização do cluster de carga de trabalho. | N/A 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
| 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ê planeja 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 acompanham a execução do AKS em um cluster do Azure Stack HCI ou do Windows Server ou no 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. Consulte Requisitos do sistema do Azure Stack HCI para obter mais informações sobre os requisitos do 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 as seleções de região e idioma en-us . Você não pode 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 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 desempenho e capacidade usando armazenamento flash e unidades de disco rígido (HDDs).
- 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 têm suporte no 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 o 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 o repositório 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 o etcd são críticas. Você deve executar o AKS em um SSD. Para obter mais informações, consulte Desempenho no 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 internos 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 Espaços de Armazenamento Diretos, é necessário que seu armazenamento seja híbrido (flash + HDD) que equilibra desempenho e 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 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 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 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 obter os 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 do sistema de rede.
- Verifique se você desativou 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 sejam roteáveis entre si e para a Internet.
- Verifique se há conectividade de rede entre os hosts do Azure Stack HCI e as VMs do locatário.
- A resolução de nomes DNS é necessária para que todos os nós possam se comunicar entre si.
- (Recomendado) Habilite as 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. 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 do cluster do Kubernetes, nós do Kubernetes, VMs subjacentes, balanceadores de carga e todos os serviços do Kubernetes executados no 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 do cluster do Kubernetes e todos os serviços do Kubernetes executados sobre o cluster ainda são endereços IP estáticos alocados.
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 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 o 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 dose |
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 (sub-rede /24) para sua implantação.
Para obter mais informações sobre os 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 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 do Firewall |
|---|---|---|---|
| 22 | AKS VMs | Necessário para coletar logs ao usar Get-AksHciLogso . |
Se estiver usando VLANs separadas, os hosts Hyper-V físicos 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 Hyper-V físicos deverão acessar as VMs do AKS nessa porta. |
| 45000 | Hosts Hyper-V físicos | wssdAgent servidor gRPC. | Nenhuma regra de VLAN cruzada é necessária. |
| 45001 | Hosts Hyper-V físicos | Autenticação gRPC wssdAgent. | Nenhuma regra de VLAN cruzada é necessária. |
| 46000 | AKS VMs | wssdCloudAgent para lbagent. | Se estiver usando VLANs separadas, os hosts Hyper-V físicos 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.
Os seguintes URLs devem ser adicionados à sua lista de permissões:
| URL | Porta | Observações |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Usado ao baixar o AKS no catálogo de produtos local do Azure, bits de produto e imagens do sistema operacional do SFS. Ocorre durante a execução Set-AksHciConfig e sempre 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 local do Azure, bits de produto e imagens do sistema operacional do SFS. Ocorre durante a execução Set-AksHciConfig e sempre 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-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 ao executar Install-AksHcio . |
| <região.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 AKS no cluster de gerenciamento local do Azure. Esse endpoint é 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 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 cobrança local do Azure ao executar Install-AksHcio . |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Usado periodicamente para enviar dados de diagnóstico necessários à Microsoft do host local do Azure ou do Windows Server. |
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 em que 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 aborda 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., 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 é instalado por padrão nos nós do Azure Stack HCI do Azure Stack HCI 21H2 e superior, 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 no 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 o 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.
Estes são os requisitos para o computador que executa o gateway do 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 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.
Uma conta e uma 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 estudantes ou assinantes do Visual Studio.
- Assinatura pré-paga com cartão de crédito.
- Assinatura obtida por meio de um EA (Contrato Enterprise).
- Assinatura obtida por meio do programa CSP (Provedor de Soluções na Nuvem).
Permissões, função e nível de acesso do Microsoft Entra
Você precisa ter permissões suficientes para registrar um aplicativo no seu locatário do Microsoft Entra.
Para verificar se você tem permissões suficientes, siga as informações abaixo:
- Acesse 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ê deverá certificar-se de que os não administradores possam 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 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 na ID do Microsoft Entra que são concedidas a cada função, consulte Funções internas do Microsoft Entra. Se sua conta tiver a função de usuário , mas a configuração de registro de aplicativo for limitada a usuários administradores, peça ao administrador para atribuir a você uma das funções de administrador que podem criar e gerenciar todos os aspectos dos registros de aplicativos 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 conceder 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 corretas. 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 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 o 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 seja um proprietário.
- Se você estiver usando o PowerShell para implantar um host do AKS ou um cluster de carga de trabalho do AKS, o usuário que registra o cluster deverá ter pelo menos um dos seguintes:
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 corretas. 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 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 verificar seu nível de acesso navegando até sua assinatura, selecionando Controle de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecionando Exibir 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 do PowerShell do AKS:
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 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 do 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 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 o 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 quando você instala o módulo 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, em seguida, 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 Asiático ou Europa Ocidental do Azure disponível antes do registro.
Regiões do Azure
Aviso
Atualmente, o AKS Arc dá suporte à criação de cluster 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, cobrança e gerenciamento. Atualmente, ele tem suporte 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 maneira ideal em um ambiente do Active Directory, verifique se os seguintes requisitos foram 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 horário, consulte Serviço de horário do Windows.
- Verifique se as contas de usuário usadas para adicionar, atualizar e gerenciar clusters do AKS ou do Windows Server Datacenter têm as permissões corretas no Active Directory. Se você estiver usando unidades organizacionais (UOs) para gerenciar políticas de grupo para servidores e serviços, as contas de usuário exigirão permissões de lista, 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: