Requisitos de sistema para o AKS ativado 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 Azure Kubernetes Service (AKS) ativado pelo Azure Arc. Para obter uma descrição geral do AKS ativado pelo Arc, veja a Descrição geral do AKS.
Requisitos de hardware
A Microsoft recomenda a compra de uma solução de hardware/software do Azure Stack HCI validada dos nossos parceiros. Estas soluções foram concebidas, montadas e validadas para executar a nossa arquitetura de referência e verificar a compatibilidade e fiabilidade para que comece a trabalhar rapidamente. Deve verificar se os sistemas, componentes, dispositivos e controladores que está a utilizar são Certificados pelo Windows Server de acordo com o Catálogo do Windows Server. Veja o site de soluções do Azure Stack HCI para obter soluções validadas.
Importante
Os sistemas anfitriões para implementações de produção têm de ser hardware físico. A virtualização aninhada, caracterizada por implementar o Azure Stack HCI ou o Windows Server numa máquina virtual e instalar o AKS nessa máquina virtual, não é suportada.
Especificações de hardware máximas suportadas
As implementações do AKS no Azure Stack HCI e no Windows Server que excedam as seguintes especificações não são suportadas:
| Recurso | Máximo |
|---|---|
| Servidores físicos por cluster | 8 (versão 22H2 e Windows Server do Azure Stack HCI) |
| Número total de VMs | 200 |
Requisitos de computação
Requisitos mínimos de memória
Pode configurar o cluster do AKS da seguinte forma para executar o AKS num único nó do Windows Server com RAM limitada:
| Tipo de cluster | Tamanho da VM do plano de controlo | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| Anfitrião do AKS | Standard_A4_v2 tamanho da VM = 8 GB | N/D - O anfitrião do AKS não tem nós de trabalho. | 8 GB | N/D - O anfitrião do AKS utiliza o kubevip para balanceamento de carga. |
| Cluster de cargas de trabalho | Standard_A4_v2 tamanho da VM = 8 GB | Standard_K8S3_v1 para 1 nó de trabalho = 6 GB | Pode reutilizar estes 8 GB reservados para a atualização do cluster de cargas de trabalho. | N/D se o kubevip for utilizado para balanceamento de carga (em vez do balanceador de carga HAProxy predefinido). |
Requisito mínimo total: 30 GB de RAM.
Este requisito mínimo destina-se a uma implementação do AKS com um nó de trabalho para executar aplicações em contentores. Se optar por adicionar nós de trabalho ou um balanceador de carga HAProxy, o requisito final da RAM será alterado em conformidade.
Requisitos de computação recomendados
| Ambiente | Núcleos de CPU por servidor | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 GB |
| Cluster de ativação pós-falha do Windows Server | 32 | 256 GB |
| Windows Server de nó único | 16 | 128 GB |
Para um ambiente de produção, o dimensionamento final depende da aplicação e do número de nós de trabalho que está a planear implementar no cluster do Azure Stack HCI ou do Windows Server. Se optar por executar o AKS num Windows Server de nó único, não obtém funcionalidades como a elevada disponibilidade fornecida com a execução do AKS num cluster do Azure Stack HCI, do Windows Server ou do cluster de ativação pós-falha do Windows Server.
Outros requisitos de computação do AKS no Azure Stack HCI e no Windows Server estão em conformidade com os requisitos do Azure Stack HCI. Veja Requisitos de sistema do Azure Stack HCI para obter mais informações sobre os requisitos do servidor do Azure Stack HCI.
Tem de instalar o mesmo sistema operativo em cada servidor no cluster. Se estiver a utilizar o Azure Stack HCI, o mesmo SO e a mesma versão têm de estar em cada servidor no cluster. Se estiver a utilizar o Windows Server Datacenter, o mesmo SO e versão têm de ser os mesmos em cada servidor no cluster. Cada SO tem de utilizar as seleções de região e idioma en-us . Não pode alterar estas definições após a instalação.
Requisitos de armazenamento
O AKS no Azure Stack HCI e no Windows Server suporta as seguintes implementações de armazenamento:
| Name | Tipo de armazenamento | Capacidade necessária |
|---|---|---|
| Cluster do Azure Stack HCI | Volumes partilhados de cluster | 1 TB |
| Cluster de ativação pós-falha do Windows Server Datacenter | Volumes partilhados de cluster | 1 TB |
| Windows Server Datacenter de nó único | Armazenamento ligado diretamente | 500 GB |
Para um cluster do Azure Stack HCI ou do Windows Server, existem duas configurações de armazenamento suportadas para executar cargas de trabalho de máquinas virtuais:
- O armazenamento híbrido equilibra o desempenho e a capacidade com o armazenamento flash e as unidades de disco rígido (HDDs).
- O armazenamento all-flash maximiza o desempenho com 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, pelo que 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, veja a documentação do Azure Stack HCI. Todos os sistemas validados no catálogo do Azure Stack HCI enquadram-se numa destas duas configurações de armazenamento suportadas.
O Kubernetes utiliza etcd para armazenar o estado dos clusters. Etcd armazena a configuração, as especificações e o estado dos pods em execução. Além disso, o Kubernetes utiliza o arquivo para deteção de serviços. Como componente coordenador do funcionamento do Kubernetes e das cargas de trabalho que suporta, a latência e o débito para etc., são fundamentais. Tem de executar o AKS num SSD. Para obter mais informações, veja Performance at etcd.io ( Desempenho em etcd.io).
Para um cluster baseado no Windows Server Datacenter, pode implementar com armazenamento local ou armazenamento baseado em SAN. Para o armazenamento local, recomenda-se que utilize o Espaços de Armazenamento Direto incorporado ou uma solução SAN virtual certificada equivalente para criar uma infraestrutura hiperconvergida que apresenta Volumes Partilhados de Cluster para utilização por cargas de trabalho. Para Espaços de Armazenamento Direto, é necessário que o seu armazenamento seja híbrido (flash + HDD) que equilibre o desempenho e a capacidade ou tudo flash (SSD, NVMe) que maximize o desempenho. Se optar por implementar com o armazenamento baseado em SAN, certifique-se de que o armazenamento SAN pode fornecer 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 limite.
Para implementações do Windows Server de nó único com armazenamento local, a utilização do armazenamento all-flash (SSD, NVMe) é altamente recomendada para fornecer o desempenho necessário para alojar várias máquinas virtuais num único anfitrião físico. Sem o armazenamento flash, os níveis mais baixos de desempenho em HDDs podem causar problemas de implementação e tempos limite.
Requisitos da rede
Os seguintes requisitos aplicam-se 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, veja Requisitos de rede.
- Para o Azure Stack HCI 22H2 e o Windows Server, verifique se tem um comutador virtual externo existente configurado se estiver a utilizar Windows Admin Center. Para clusters HCI ou Windows Server, este comutador e o respetivo nome têm de ser os mesmos em todos os nós de cluster. Para HCI 23H2, veja os requisitos do sistema de rede.
- Verifique se desativou o IPv6 em todas as placas de rede.
- Para uma implementação bem-sucedida, os nós de cluster do Azure Stack HCI ou do Windows Server e as VMs do cluster do Kubernetes têm de ter conectividade externa à Internet.
- Certifique-se de que todas as sub-redes definidas para o cluster são encaminháveis entre si e para a Internet.
- Certifique-se de que existe conectividade de rede entre os anfitriões do Azure Stack HCI e as VMs de inquilino.
- A resolução de nomes DNS é necessária para que todos os nós possam comunicar entre si.
- (Recomendado) Ative atualizações DNS dinâmicas no seu ambiente DNS para permitir que o AKS registe o nome do cluster genérico do agente da cloud no sistema DNS para deteção.
Atribuição de endereços IP
No AKS ativado pelo Arc, as redes virtuais são utilizadas para alocar endereços IP aos recursos do Kubernetes que os necessitam, conforme listado anteriormente. Existem dois modelos de rede à escolha, consoante a arquitetura de rede do AKS pretendida.
Nota
A arquitetura de rede virtual definida aqui para as suas implementações do AKS é diferente da arquitetura de rede física subjacente no seu datacenter.
- Rede IP estática: a rede virtual aloca endereços IP estáticos ao servidor de API do cluster do Kubernetes, aos nós do Kubernetes, às VMs subjacentes, aos balanceadores de carga e a todos os serviços do Kubernetes que executar em cima do cluster.
- Rede DHCP: a rede virtual atribui endereços IP dinâmicos aos nós do Kubernetes, VMs subjacentes e balanceadores de carga com um servidor DHCP. O servidor de API do cluster do Kubernetes e todos os serviços do Kubernetes que executar em cima do cluster continuam a ser endereços IP estáticos alocados.
Reserva mínima de endereços IP
No mínimo, deve reservar o seguinte número de endereços IP para a sua implementação:
| Tipo de cluster | Nó do plano de controlo | Nó de trabalho | Para operações de atualização | Balanceador de carga |
|---|---|---|---|---|
| Anfitrião do AKS | 1 IP | ND | 2 IP | ND |
| Cluster de cargas de trabalho | 1 IP por nó | 1 IP por nó | 5 IP | 1 IP |
Além disso, deve reservar o seguinte número de endereços IP para o conjunto 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 pode ver, o número de endereços IP necessários é variável consoante a arquitetura do AKS e o número de serviços executados no cluster do Kubernetes. Recomendamos que reserve um total de 256 endereços IP (/24 sub-rede) para a sua implementação.
Para obter mais informações sobre os requisitos de rede, veja Conceitos de rede de nós no AKS e conceitos de rede de contentores no AKS.
Requisitos de porta de rede e URL
AKS ativado 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 do cluster do Azure Kubernetes estiverem em duas vlans isoladas, estas portas têm de ser abertas na firewall entre elas:
| Porta | Origem | Descrição | Notas de Firewall |
|---|---|---|---|
| 22 | AKS VMs | Necessário para recolher registos ao utilizar Get-AksHciLogs. |
Se utilizar VLANs separadas, os Anfitriões Hyper-V físicos têm de aceder às VMs do AKS nesta porta. |
| 6443 | AKS VMs | Necessário para comunicar com as APIs do Kubernetes. | Se utilizar VLANs separadas, os Anfitriões Hyper-V físicos têm de aceder às VMs do AKS nesta porta. |
| 45000 | Anfitriões Hyper-V Físicos | wssdAgent gRPC server. | Não são necessárias regras entre VLAN. |
| 45001 | Anfitriões Hyper-V Físicos | wssdAgent gRPC authentication. | Não são necessárias regras entre VLAN. |
| 46000 | AKS VMs | wssdCloudAgent para lbagent. | Se utilizar VLANs separadas, os Anfitriões Hyper-V físicos têm de aceder às VMs do AKS nesta porta. |
| 55000 | Recurso de cluster (-CloudServiceCIDR) | Servidor gRPC do Cloud Agent. | Se utilizar VLANs separadas, as VMs do AKS têm de aceder ao IP do recurso do cluster nesta porta. |
| 65000 | Recurso de cluster (-CloudServiceCIDR) | Autenticação gRPC do Agente da Cloud. | Se utilizar VLANs separadas, as VMs do AKS têm de aceder ao IP do recurso do cluster nesta porta. |
Se a sua rede exigir a utilização de um servidor proxy para ligar à Internet, consulte Utilizar definições do servidor proxy no AKS.
Os seguintes URLs têm de ser adicionados à sua lista de permissões:
| URL | Porta | Notas |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Utilizado ao transferir o AKS no catálogo de produtos do Azure Stack HCI, bits de produto e imagens do SO a partir do SFS. Ocorre quando está em execução Set-AksHciConfig e sempre que transfere a partir do SFS. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Utilizado ao transferir o AKS no catálogo de produtos do Azure Stack HCI, bits de produto e imagens do SO a partir do SFS. Ocorre quando está em execução Set-AksHciConfig e sempre que transfere a partir do SFS. |
login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net |
443 | Utilizado para iniciar sessão no Azure ao executar Set-AksHciRegistration. |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net ponto final dos EUA: wus2replica*.blob.core.windows.net |
443 | Necessário para extrair imagens de contentor ao executar Install-AksHci. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | Necessário para integrar clusters híbridos do AKS no Azure Arc. |
| gbl.his.arc.azure.com | 443 | Necessário para obter o ponto final regional para solicitar certificados de Identidade Gerida atribuídos pelo sistema. |
| *.his.arc.azure.com | 443 | Necessário para solicitar certificados de Identidade Gerida atribuídos pelo sistema. |
| k8connecthelm.azureedge.net | 443 | O Kubernetes compatível com o Arc utiliza o Helm 3 para implementar agentes do Azure Arc no cluster de gestão do AKS-HCI. Este ponto final é necessário para a transferência do cliente Helm para facilitar a implementação do gráfico helm do agente. |
| *.arc.azure.net | 443 | Necessário para gerir clusters híbridos do AKS no portal do Azure. |
| dl.k8s.io | 443 | Necessário para transferir e atualizar os binários do Kubernetes para o Azure Arc. |
| akshci.azurefd.net | 443 | Necessário para o AKS na faturação do Azure Stack HCI ao executar Install-AksHci. |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Utilizado periodicamente para enviar dados de diagnóstico necessários da Microsoft a partir do anfitrião do Azure Stack HCI ou do Windows Server. |
Nota
O AKS ativado pelo Arc armazena e processa os dados dos clientes. Por predefinição, os dados do cliente permanecem na região na qual o cliente implementa a instância de serviço. Estes 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 de URL adicionais para funcionalidades do Azure Arc
A lista de URLs anteriores abrange os URLs mínimos necessários para ligar o serviço AKS ao Azure para faturação. Tem de permitir URLs adicionais se quiser utilizar o cluster connect, localizações personalizadas, RBAC do Azure e outros serviços do Azure, como o Azure Monitor, etc., no cluster de cargas de trabalho do AKS. Para obter uma lista completa dos URLs do Arc, veja Requisitos de rede do Kubernetes compatíveis com o Azure Arc.
Também deve rever os URLs do Azure Stack HCI. Uma vez que o Arc para agentes de servidor está agora instalado por predefinição nos nós do Azure Stack HCI a partir do Azure Stack HCI 21H2 e superior, também deve rever os URLs do Arc para agentes de servidor.
Clusters dispersos no AKS
Conforme descrito na descrição geral de Clusters dispersos, a implementação do AKS no Azure Stack HCI e no Windows Server com clusters dispersos do Windows não é suportada. Recomendamos que utilize uma abordagem de cópia de segurança e recuperação após desastre para a continuidade operacional do datacenter. Para obter mais informações, veja Executar a cópia de segurança ou restauro do cluster de cargas de trabalho com o Velero e o armazenamento de Blobs do Azure Stack no Azure Stack HCI e No Windows Server e Implementar configurações no AksHci com o GitOps com o Flux v2 para continuidade da aplicação.
Windows Admin Center requisitos
Windows Admin Center é a interface de utilizador para criar e gerir o AKS ativado pelo Azure Arc. Para utilizar Windows Admin Center com o AKS no Azure Stack HCI e no Windows Server, tem de cumprir todos os critérios na lista seguinte.
Estes são os requisitos para o computador que está a executar o gateway de Windows Admin Center:
- Windows 10 ou Windows Server.
- Registado no Azure.
- No mesmo domínio que o cluster do Azure Stack HCI ou do Windows Server Datacenter.
- Uma subscrição do Azure na qual tem direitos de Proprietário. Pode verificar o nível de acesso ao navegar para a sua subscrição e selecionar Controlo de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecionar Ver o meu acesso.
Requisitos do Azure
Tem de ligar à 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 pay as you go com cartão de crédito.
- Subscrição obtida através de um Contrato Enterprise (EA).
- Subscrição obtida através do programa Fornecedor de Soluções Cloud (CSP).
Microsoft Entra permissões, função e nível de acesso
Tem de ter permissões suficientes para registar uma aplicação no seu inquilino Microsoft Entra.
Para verificar se tem permissões suficientes, siga as informações abaixo:
- Aceda ao portal do Azure e selecione Funções e administradoresem Microsoft Entra ID para verificar a sua função.
- Se a sua função for Utilizador, tem de se certificar de que os não administradores podem registar aplicações.
- Para verificar se consegue registar aplicações, aceda a Definições de utilizador no serviço Microsoft Entra para verificar se tem permissão para registar uma aplicação.
Se a definição de registos de aplicações estiver definida como Não, apenas os utilizadores com uma função de administrador podem registar estes tipos de aplicações. Para saber mais sobre as funções de administrador disponíveis e as permissões específicas em Microsoft Entra ID atribuídas a cada função, veja Microsoft Entra funções incorporadas. Se a sua conta tiver a função Utilizador atribuída, mas a definição de registo de aplicações estiver limitada aos utilizadores administradores, peça ao administrador para lhe atribuir uma das funções de administrador que pode criar e gerir todos os aspetos dos registos de aplicações ou para permitir que os utilizadores registem aplicações.
Se não tiver permissões suficientes para registar uma aplicação e o seu administrador não lhe conseguir conceder estas permissões, a forma mais fácil de implementar o AKS é pedir ao administrador do Azure para criar um principal de serviço com as permissões certas. Os administradores podem verificar a secção seguinte para saber como criar um principal de serviço.
Função de subscrição do Azure e nível de acesso
Para verificar o 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 Windows Admin Center para implementar um anfitrião do AKS ou um cluster de cargas de trabalho do AKS, tem de ter uma subscrição do Azure na qual é Proprietário.
- Se estiver a utilizar o PowerShell para implementar um anfitrião do AKS ou um cluster de cargas de trabalho do AKS, o utilizador que está a registar o cluster tem de ter, pelo menos, um dos seguintes:
- Uma conta de utilizador com a função de Proprietário incorporada.
- Um principal de serviço com um dos seguintes níveis de acesso:
- A função contribuidor incorporada.
- 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 um principal de serviço com as permissões certas. Os administradores podem verificar a secção seguinte sobre como criar um principal de serviço.
Opcional: criar um novo principal de serviço
Execute os seguintes passos para criar um novo principal de serviço com a função de Proprietário incorporada. Apenas os proprietários de subscrições podem criar principais de serviço com a atribuição de função correta. Pode verificar o nível de acesso ao navegar para a sua subscrição, selecionar Controlo de acesso (IAM) no lado esquerdo do portal do Azure e, em seguida, selecionar ver o meu acesso.
Defina as seguintes variáveis do PowerShell numa janela de administração do PowerShell. Verifique se a subscrição e o inquilino são o que pretende utilizar para registar o anfitrião do AKS para faturação:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Instale e importe o módulo do AKS PowerShell:
Install-Module -Name AksHci
Inicie sessão no Azure com o comando Connect-AzAccount powerShell:
Connect-AzAccount -tenant $tenantID
Defina a subscrição que pretende utilizar para registar o anfitrião do AKS para faturação como a subscrição predefinida ao executar o comando Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Verifique se o contexto de início de sessão está correto ao executar o comando Get-AzContext powerShell. Verifique se a subscrição, o inquilino e a conta são o que pretende utilizar para registar o anfitrião do AKS para faturação:
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Crie um principal de serviço ao executar o comando New-AzADServicePrincipal powerShell. Este comando cria um principal de serviço com a função Proprietário e define o âmbito ao nível da subscrição. Para obter mais informações sobre como criar principais de serviço, veja Criar um principal de serviço do Azure com Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Obtenha a palavra-passe do principal de serviço ao executar o seguinte comando. Tenha em atenção que este comando só funciona para Az.Accounts 2.6.0 ou abaixo. Transferimos automaticamente o módulo Az.Accounts 2.6.0 quando instala o módulo do AksHci PowerShell:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
A partir do resultado anterior, tem agora o ID da aplicação e o segredo disponíveis ao implementar o AKS. Deve tomar nota destes itens e armazená-los em segurança. Com isso criado, no portal do Azure, em Subscrições, Controlo de Acesso e, em seguida, Atribuições de Funções, deverá ver o novo principal de serviço.
Grupo de recursos do Azure
Tem de ter um grupo de recursos do Azure na região Leste da Austrália, E.U.A. Leste, Sudeste Asiático ou Europa Ocidental do Azure disponível antes do registo.
Regiões do Azure
Aviso
Atualmente, o AKS Arc suporta a criação de clusters exclusivamente nas seguintes regiões especificadas do Azure. Se tentar implementar numa região fora desta lista, ocorrerá uma falha de implementação.
O serviço AKS Arc é utilizado para registo, faturação e gestão. Atualmente, é suportado nas seguintes regiões:
- E.U.A. Leste
- E.U.A. Centro-Sul
- Europa Ocidental
Requisitos do Active Directory
Para que um cluster de ativação pós-falha do AKS com 2 ou mais nós físicos funcione da melhor forma num ambiente do Active Directory, certifique-se de que os seguintes requisitos são cumpridos:
Nota
O Active Directory não é necessário para implementaçõ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 superior a 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 hora, consulte Serviço de hora do Windows.
- Certifique-se de que as contas de utilizador utilizadas para adicionar atualizações e gerir clusters do AKS ou do Windows Server Datacenter têm as permissões corretas no Active Directory. Se estiver a utilizar Unidades Organizacionais (UOs) para gerir políticas de grupo para servidores e serviços, as contas de utilizador requerem permissões de lista, leitura, modificação e eliminação em todos os objetos na UO.
- Utilize uma unidade organizacional (UO) separada para os servidores e serviços pelos clusters do AKS ou do Windows Server Datacenter. A utilização de uma UO separada permite-lhe controlar o acesso e as permissões com mais granularidade.
- Se estiver a utilizar modelos de GPO em contentores no Active Directory, confirme que a implementação do AKS no Azure Stack HCI e no Windows Server está isenta da política.
Passos seguintes
Depois de cumprir todos os pré-requisitos acima, pode configurar um anfitrião do AKS no Azure Stack HCI com:
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários