As informações contidas nesta página e suas subseções se aplicam a você quando decide migrar seu pod de primeira geração usando o tipo AKS para a implantação do Horizon Edge Gateway.
Introdução
Estas seções descrevem os requisitos específicos relacionados ao AKS que você deve atender antes de executar o assistente de migração.
As informações aqui pressupõem que você já leu a seção Decidir sobre seu tipo de implantação e atender aos seus requisitos, respondeu às perguntas e decidiu usar o tipo AKS para a migração do pod.
Caso especial: se você tiver determinado que a VNet do pod, incluindo outras redes conectadas, contém IPs restritos ao AKS
Conforme descrito na seção Determinar se a VNet do pod ou as redes conectadas contêm endereços IP restritos ao AKS, quando você quiser implantar usando o tipo AKS, mas a VNet do pod de primeira geração ou a rede local conectada a essa VNet contiver endereços IP dos intervalos de IP restritos do AKS, então, para um tipo de implantação AKS, você deverá:
- Configurar outra VNet na assinatura do pod, que não contém endereços IP dos intervalos com restrição de AKS.
- Criar uma nova sub-rede de gerenciamento nessa VNet, com a sub-rede com um CIDR mínimo de /26.
- Certifique-se de que a nova VNet e a sub-rede de gerenciamento permitam a comunicação de rede com os endpoints necessários do serviço de próxima geração, para suas portas e protocolos necessários, de acordo com as páginas:
- Emparelhe essa nova VNet com a VNet existente do pod.
Depois que as quatro etapas anteriores forem concluídas, use essa nova sub-rede e a VNet de gerenciamento ao atender aos requisitos descritos nas seções a seguir.
Os intervalos de IP restritos do AKS a serem evitados são:
- 169.254.0.0/16
- 172.30.0.0./16
- 172.31.0.0/16
- 192.0.2.0/24
Além de evitar os intervalos acima com a nova VNet, você também deve evitar usar os CIDRs que você e sua equipe decidiram usar para os intervalos de IP virtuais da implantação, descritos em Tipo AKS: reservar intervalos de IP virtuais necessários para evitar conflitos com o AKS.
Tipo de AKS: confirmar provedores de recursos do Azure e registrar os novos necessários
O tipo de AKS de implantação do Horizon Edge Gateway requer um conjunto específico de provedores de recursos na assinatura do Microsoft Azure.
Na assinatura do pod de primeira geração, confirme se todos os provedores de recursos a seguir têm o status Registered.
Algumas delas são as mesmas necessárias para uma implantação de pod de primeira geração. A tabela indica quais são as adicionalmente necessárias para o registro do tipo de implantação AKS.
| Provedor de recursos | |
|---|---|
| Additional new ones to register for next-gen AKS deployment type |
|
| Needed by next-gen which would've been previously registered for your first-gen pod |
|
Para verificar os provedores de recursos na assinatura do Microsoft Azure do pod de primeira geração:
- Faça login no portal do Azure e procure a assinatura do pod.
- Clique no nome da assinatura e role para baixo até ver
(Provedores de recursos). - Procure o recurso fornecido na tabela anterior e verifique se cada um deles exibe
(Registrado). Use o portal do Azure para registrar quaisquer provedores de recursos da tabela que tenha um status de
NotRegistered.
Você pode ver que a assinatura do pod tem os provedores de recursos necessários para o Edge Gateway de próxima geração que já estão no status Registered. Você também pode ver provedores de recursos registrados, como Microsoft.Billing, que não estão relacionados a esses que são exigidos pelo Horizon Cloud Service. Essa variação potencial no status é resultado do comportamento padrão do Microsoft Azure, em que eles têm um conjunto de provedores de recursos normalmente registrados para todas as assinaturas do Azure.
Tipo AKS: configurar um gateway NAT ou uma tabela de rotas e associá-lo à sub-rede de gerenciamento
Para sua comunicação de saída com a camada de controle de nuvem, o tipo AKS de implantação do Horizon Edge Gateway requer um dos seguintes itens: gateway NAT ou tabela de rotas: associado à sua sub-rede de gerenciamento.
Na assinatura do Microsoft Azure do pod, crie aquele que você deseja usar e associe-o à sub-rede de gerenciamento do pod.
- Gateway NAT
- Tabela de rotas (Essa é uma opção mais avançada, normalmente usada apenas quando a VNet do seu pod já tem tabelas de rota sendo usadas com seus pods de primeira geração)
Usar um gateway NAT: criá-lo e associá-lo à sub-rede de gerenciamento
De acordo com a documentação do Microsoft Azure, a criação de um gateway NAT requer um endereço IP público ou um prefixo IP público, ou ambos, à sua escolha.
O assistente para Criar Gateway NAT do portal do Azure exigirá que você faça uma escolha. Nas etapas abaixo, optamos por criar um novo IP público a ser usado para o nosso gateway NAT.
- Faça login no portal do Azure e use a barra de pesquisa para procurar gateways NAT e selecione essa categoria.
- Clique em + Criar para iniciar o assistente para Criar Gateway NAT.
- Nesta primeira etapa do assistente para Criar Gateway NAT, certifique-se de que a assinatura do pod esteja selecionada e escolha um grupo de recursos no qual o gateway NAT resida.
- Dê um nome ao gateway NAT e certifique-se de que a região selecionada seja a região do Azure do pod. Quando preenchido, clique na etapa IP de Saída.
A captura de tela a seguir é um exemplo no qual nomeamos nosso gateway NAT como first-pod-migration. Ele reside na região do Azure West US 2.
- Na etapa IP de Saída, siga as instruções na tela para selecionar se deseja usar um endereço IP público ou prefixos de IP públicos para esse gateway NAT.
A captura de tela a seguir é uma ilustração dessa etapa em que escolhemos criar um novo IP público para esse gateway NAT usar e demos a ele o nome first-pod-NAT-gtway.
Quando essa etapa estiver preenchida, clique na próxima etapa do assistente Sub-rede.
- Na etapa Sub-rede do assistente:
- Se você não está contornando o problema de ter endereços IP restritos ao AKS na sua VNet, selecione a VNet do pod e sua sub-rede de gerenciamento.
- Caso contrário, se você tiver criado uma nova VNet e uma sub-rede de gerenciamento para contornar a VNet do pod com endereços IP restritos ao AKS, selecione a nova VNet e a nova sub-rede de gerenciamento.
A captura de tela a seguir ilustra essa etapa de seleção da VNet do pod e sua sub-rede de gerenciamento, associando a sub-rede a esse gateway NAT.
- Clique em Revisar + criar.
Se a validação for aprovada, clique em Criar para finalmente criar esse gateway NAT.
Agora, o gateway NAT está associado à sub-rede de gerenciamento e está pronto para você selecionar no assistente de migração.
Se você escolher a tabela de rotas: criar uma tabela de rotas e associá-la à sub-rede de gerenciamento
Configure esta tabela de rotas com a rota padrão 0.0.0.0/0 apontando para um próximo salto do tipo Virtual appliance ou Virtual network gateway.
- Faça login no portal do Azure e use a barra de pesquisa para procurar a tabela de rotas e selecione essa categoria.
- Clique em + Criar para iniciar o assistente da tabela Criar Rota.
- Nesta primeira etapa do assistente da tabela Criar Rota, certifique-se de que a assinatura do pod esteja selecionada e escolha um grupo de recursos para a tabela de rotas na qual residir.
Observação: Tenha em mente que, se você optar por fazer com que a tabela de rotas resida em um grupo de recursos diferente do grupo de recursos da VNet e a entidade de serviço do pod de primeira geração usar uma função personalizada, a função personalizada precisará ter permissão Network Contributor no grupo de recursos dessa tabela de rotas. O uso de uma função personalizada para uma implantação de primeira geração é atípico. O motivo para precisar dessa permissão para o grupo de recursos da tabela de rotas é porque um tipo de implantação do AKS precisa adicionar entradas à tabela de rotas associada à sub-rede de gerenciamento. Essas entradas são para o roteamento interno dos pods do Kubernetes no tipo AKS de implantação do Horizon Edge Gateway.
- Dê um nome à tabela de rotas e certifique-se de que a região selecionada seja a região do Azure do pod.
Para Propagar rotas de gateway, selecione Não.
A captura de tela a seguir é um exemplo no qual nomeamos a tabela de rotas como first-pod-migration. Ele reside na região do Azure West US 2.
- Quando o formulário da tabela Criar Rota estiver preenchido, clique em Revisar + criar.
Se a validação for aprovada, clique em Criar para finalmente criar esta tabela de rotas.
- Agora navegue até a tabela de rotas recém-criada para configurá-la com a rota padrão 0.0.0.0/0 apontando para um próximo salto do tipo Virtual network gateway ou Virtual appliance.
Como o AKS oferece suporte apenas a esses dois tipos de próximo salto, o tipo AKS de implantação do Horizon Edge Gateway oferece suporte a esses dois especificamente.
Normalmente, o Virtual Appliance é usado quando você tem um Dispositivo Virtual de Rede (NVA) do Azure controlando o fluxo de tráfego de saída entre a VNet do pod e a Internet pública. No formulário Adicionar Rota, você precisará fornecer o endereço IP desse NVA, que pode fornecer conectividade de saída à Internet. Você deve garantir que o endereço IP seja acessível pela sub-rede de gerenciamento (aquela em que a implantação do Horizon Edge Gateway será implantada). Esse NVA deve permitir tráfego para os endpoints que o ambiente de próxima geração requer para o tipo de implantação do AKS.
- Clique em Rotas e + Adicionar para adicionar essa rota padrão.
A captura de tela a seguir ilustra essa etapa. O menu Próximo tipo de salto é expandido nesta ilustração para mostrar onde as opções compatíveis Virtual network gateway e Virtual appliance aparecem. Além disso, digitamos um nome para a rota e o endereço IP de destino 0.0.0.0/0.
A captura de tela a seguir ilustra o formulário Adicionar rota preenchido com o próximo salto de Virtual Network Gateway.
- Clique em Adicionar para adicionar essa rota à tabela de rotas.
- Agora, associe a nova tabela de rotas à sub-rede de gerenciamento clicando em Sub-redes e + Associar.
A captura de tela a seguir ilustra essa etapa. Selecione a VNet e a sub-rede de gerenciamento apropriadas de acordo com o seguinte:
- Se você não está contornando o problema de ter endereços IP restritos ao AKS na sua VNet, selecione a VNet do pod e sua sub-rede de gerenciamento.
- Caso contrário, se você tiver criado uma nova VNet e uma sub-rede de gerenciamento para contornar a VNet do pod com endereços IP restritos ao AKS, selecione a nova VNet e a nova sub-rede de gerenciamento.
- Depois de selecionar a sub-rede, clique em OK.
Agora, a tabela de rotas está associada à sub-rede de gerenciamento e está pronta para ser selecionada no assistente de migração.
Tipo AKS: criar uma identidade gerenciada atribuída pelo usuário e atribuir permissões de função necessárias
Ao usar o tipo AKS de implantação do Horizon Edge Gateway, a assinatura do Microsoft Azure do pod deve ter uma identidade gerenciada atribuída pelo usuário.
Você ou sua equipe de TI podem criar e configurar essa identidade usando o Portal do Azure.
Essa identidade gerenciada atribuída pelo usuário deve ser configurada com as seguintes características:
- Função do Network Contributor no escopo do grupo de recursos da VNet. A VNet aplicável é:
- Se você não está contornando o problema de ter endereços IP restritos ao AKS na sua VNet, a VNet do pod.
- Caso contrário, se você tiver criado uma nova VNet para contornar a VNet do pod com endereços IP restritos ao AKS, essa VNet.
- Função do Managed Identity Operator no escopo da assinatura do Microsoft Azure do pod.
O motivo pelo qual essa identidade gerenciada é necessária para o tipo de implantação do AKS é porque o cluster do Serviço do Azure Kubernetes (AKS) no gateway implantado exigirá uma identidade para acessar os recursos do Azure. Portanto, essa identidade é necessária para que o fluxo de trabalho de migração implante esse tipo.
Criar a identidade gerenciada atribuída pelo usuário
- Faça login no portal do Azure e use a barra de pesquisa para procurar usuário atribuído e selecione o resultado Identidade Gerenciada Atribuída ao Usuário.
A captura de tela a seguir ilustra essa etapa de pesquisa no portal.
- Quando você clica no resultado da pesquisa de Identidade Gerenciada Atribuída pelo Usuário, o assistente para Criar Identidade Gerenciada Atribuída pelo Usuário é iniciado.
Escolha a assinatura do pod e um grupo de recursos no qual armazenar esse recurso de identidade após sua criação.
Escolha a região do Azure do pod e digite um nome para essa identidade gerenciada atribuída pelo usuário.
A captura de tela a seguir ilustra essa etapa, com partes redigidas para privacidade. Aqui, nomeamos nossa identidade gerenciada atribuída pelo usuário como AKS-Edge-identity.
- Clique em Revisar + criar para ir para a etapa final do assistente.
- Examine as informações e clique em Criar para concluir o assistente e criar a identidade gerenciada atribuída pelo usuário.
Esta captura de tela ilustra essa etapa final antes de clicar em Criar.
- Em seguida, adicione as permissões de função à identidade recém-criada, conforme descrito na próxima seção.
Atribuir as permissões de função necessárias: método de visualização do Azure
As etapas desta seção ilustram o método de uso das etapas de Visualização do Azure para atribuir uma função a uma identidade gerenciada. Se você seguir as etapas abaixo e não vir o botão + Adicionar atribuição de função (Visualização) ao analisar a área de atribuições de função do Azure da sua identidade gerenciada atribuída pelo usuário, poderá atribuir as permissões de função usando o método alternativo na seção após esse.
As permissões para adicionar à identidade gerenciada atribuída pelo usuário são:
| Permissão da Função | Escopo |
|---|---|
| Função do Managed Identity Operator | A assinatura do Microsoft Azure do pod |
| Função do Network Contributor | O grupo de recursos da VNet. A VNet aplicável é:
|
- No portal do Azure, navegue até sua identidade gerenciada recém-criada atribuída ao usuário e clique em Atribuições de função do Azure e Adicionar atribuição de função (Visualização) até ver o formulário Adicionar atribuição de função (Visualização).
A captura de tela a seguir ilustra essa etapa.
- No formulário Adicionar atribuição de função (Visualização), selecione Escopo como Assinatura, selecione a assinatura do pod e selecione Função de Managed Identity Operator.
- Clique em Salvar para salvar essa atribuição de função do Managed Identity Operator para a identidade.
- Clique em Atualizar para ver a função recém-adicionada listada.
- Reabra o formulário Adicionar atribuição de função (Visualização) clicando Adicionar atribuição de função (Visualização).
- Desta vez, selecione Escopo como Grupo de Recursos, selecione o grupo de recursos da VNet aplicável e selecione Função do Network Contributor.
- Clique em Salvar para salvar essa atribuição de função do Network Contributor para a identidade.
- Clique em Atualizar para ver a função recém-adicionada. Agora, as duas funções devem ser listadas.
Agora, a identidade gerenciada atribuída pelo usuário necessária existe e tem as permissões de função exigidas pelo tipo de implantação do AKS.
Método alternativo de atribuir as permissões de função necessárias
Quando você não vir o botão + Adicionar atribuição de função (Visualização) ao analisar a área de atribuições de função do Azure da sua identidade gerenciada atribuída pelo usuário, poderá atribuir as permissões de função usando o método alternativo.
As permissões para adicionar à identidade gerenciada atribuída pelo usuário são:
| Permissão da Função | Escopo |
|---|---|
| Função do Managed Identity Operator | A assinatura do Microsoft Azure do pod |
| Função do Network Contributor | O grupo de recursos da VNet. A VNet aplicável é:
|
- Primeiro, adicione a permissão do Managed Identity Operator ao escopo da assinatura do pod:
- No portal do Azure, navegue até a assinatura.
- Na página dessa assinatura, clique em Acessar controle (IAM) e, em seguida, clique na guia Atribuições de função.
- Clique em .
O assistente de Adicionar atribuição de função é exibido.
- Nesse assistente, na guia Função, procure e selecione a função do Managed Identity Operator. Certifique-se de que sua linha esteja selecionada antes de clicar em Avançar.
- Clique em Avançar para ir até a guia Membros.
- Na guia Membros, selecione Identidade gerenciada e, em seguida, + Selecionar membros, que exibe o formulário Selecionar identidades gerenciadas.
A próxima etapa aqui tem a captura de tela de exemplo.
- No formulário Selecionar identidades gerenciadas no menu Identidade gerenciadas, selecione Identidade gerenciada atribuída pelo usuário.
- Em seguida, selecione a identidade gerenciada atribuída pelo usuário que você criou e clique no botão Selecionar para adicioná-la à guia Membros.
- Agora clique em Revisar + atribuir para mover para a guia Revisar + atribuir do assistente.
- Na guia Revisar + atribuir, clique no botão final Revisar + atribuir para concluir a atribuição dessa função à identidade no escopo da assinatura.
- Agora, adicione a permissão do Network Contributor ao escopo do grupo de recursos da VNet:
- No portal do Azure, navegue até o grupo de recursos da VNet aplicável. A VNet aplicável é:
- Se você não está contornando o problema de ter endereços IP restritos ao AKS na sua VNet, o grupo de recursos da VNet do pod.
- Caso contrário, se você tiver criado uma nova VNet para contornar a VNet do pod com endereços IP restritos ao AKS, esse grupo de recursos da VNet.
- Na página desse grupo de recursos, use etapas semelhantes ao que você fez acima para as permissões da assinatura.
Clique em Controle de acesso (IAM) e clique na guia Atribuições de função.
Esta captura de tela ilustra essa etapa para o grupo de recursos da VNet chamado hcsvnet-RG.
- Clique em . O assistente de Adicionar atribuição de função é exibido.
- Nesse assistente, na guia Função, procure e selecione a função do Network Contributor. Certifique-se de que sua linha esteja selecionada antes de clicar em Avançar.
- Em seguida, da mesma forma que antes para a outra permissão, clique em Avançar para ir até a guia Membros e selecione Identidade gerenciada e, em seguida, + Selecionar membros, que exibe o formulário Selecionar identidades gerenciadas.
- No formulário Selecionar identidades gerenciadas no menu Identidade gerenciadas, selecione Identidade gerenciada atribuída pelo usuário.
- Em seguida, selecione a identidade gerenciada atribuída pelo usuário que você criou e clique no botão Selecionar para adicioná-la à guia Membros.
- Agora vá para a guia Revisar + atribuir do assistente e clique no botão Revisar + atribuir para concluir a atribuição dessa função à identidade no escopo do grupo de recursos da VNet.
Esta captura de tela ilustra essa etapa para o grupo de recursos da VNet chamado hcsvnet-RG.
- No portal do Azure, navegue até o grupo de recursos da VNet aplicável. A VNet aplicável é:
Agora, a identidade gerenciada atribuída pelo usuário necessária existe e tem as permissões de função exigidas pelo tipo de implantação do AKS.
Para confirmar que a identidade gerenciada atribuída pelo usuário tem as duas funções, navegue até a identidade no portal do Azure e exiba sua página de atribuições de função do Azure.
A captura de tela a seguir ilustra nossa identidade gerenciada atribuída pelo usuário com as duas funções listadas em suas atribuições de função do Azure.
Tipo AKS: reservar intervalos de IP virtuais necessários para evitar conflitos com o AKS
Essas informações serão aplicáveis quando você decidir migrar o pod usando o tipo AKS para a implantação do Horizon Edge Gateway. O tipo de implantação do AKS requer que alguns intervalos de IPs virtuais sejam reservados no seu método de gerenciamento de IP de escolha, seu sistema de IPAM (sistema de gerenciamento de endereços IP).
Introdução
Esses intervalos são intervalos de IPs virtuais que devem ser reservados para o uso exclusivo do tipo AKS do Horizon Edge Gateway
Por padrão, o Kubernetes cria redes virtuais no cluster Kubernetes contido no Horizon Edge Gateway.
Essas redes virtuais hospedam os contêineres que são executados dentro do cluster.
Por que esses intervalos precisam ser reservados se são internos ao Edge?
O objetivo de reservar esses intervalos é evitar que quaisquer outras máquinas no seu espaço de rede façam com que esses endereços IP sejam atribuídos a elas e usem esses endereços IP.
Mesmo que as redes virtuais do cluster Kubernetes do Edge sejam internas ao Horizon Edge Gateway e não estejam na rede de gerenciamento, as redes virtuais do cluster se conectam à sub-rede de gerenciamento na sua VNet do Azure.
Serviços que são executados fora do tráfego de rota do cluster do AKS para as redes internas do AKS-cluster. Por exemplo, os Horizon Agents em áreas de trabalho VDI precisam enviar dados para serviços em execução neste cluster AKS.
Portanto, se os intervalos não estiverem reservados e outra máquina na sua rede receber um endereço IP dos intervalos, isso poderá afetar o roteamento e causar conflitos no tráfego de serviço necessário para as redes internas-cluster-AKS.
Reservando os intervalos de IP no seu sistema de gerenciamento de endereços IP antes da migração do pod, você evita esses possíveis conflitos.
Preciso criar sub-redes desses intervalos?
Não, você não precisa criar sub-redes desses intervalos.
Esses intervalos de IPs virtuais ficarão ativos na rede virtual do cluster AKS do Horizon Edge Gateway quando o Horizon Edge for implantado como parte do processo de migração.
Para a migração de pods, preciso saber quais são meus intervalos reservados?
Sim. Quando você planeja escolher o tipo de implantação do AKS, precisa conhecer os intervalos que você e sua equipe reservaram para os fins dessa implantação.
A UI do assistente de migração exigirá que você insira dois intervalos de IPs (CIDRs) nos campos denominados CIDR de Serviço e CIDR de Pod.
Portanto, você deve decidir sobre quais intervalos você e sua equipe optaram por reservar antes de executar o assistente de migração.
Que tipo de intervalo devo reservar?
O tipo AKS do Horizon Edge Gateway requer que dois intervalos de IPs virtuais sejam reservados para seu uso.
- Um intervalo CIDR mínimo de /27 para o que é chamado de CIDR de Serviço
- Um intervalo CIDR mínimo de /21 para o que é chamado de CIDR de Pod
Esses dois intervalos de IP não devem se sobrepor ou colidir um com o outro.
- 169.254.0.0/16
- 172.30.0.0./16
- 172.31.0.0/16
- 192.0.2.0/24
| Intervalo de IPs a ser reservado | Detalhes |
|---|---|
| CIDR de Serviço | Decida sobre um intervalo de IPs para CIDR de Serviço e reserve esse espaço de IP no seu IPAM para que nenhuma outra máquina possa usar endereços IP desse intervalo. É necessário um intervalo mínimo de /27.
Lembrete: Conforme declarado acima, esse é um intervalo de IP virtual e você não tem que criar uma sub-rede com esse intervalo. Você só precisa garantir que nenhuma outra máquina na rede receba esses endereços.
Ao decidir sobre o intervalo de IPs, tenha em mente estes pontos:
O objetivo desse CIDR para o tipo do Horizon Edge do AKS é que os endereços desse intervalo de IPs virtuais sejam atribuídos aos serviços em execução no cluster do AKS do Edge. |
| CIDR do Pod | Decida sobre um intervalo de IPs para CIDR de Serviço e reserve esse espaço de IP no seu IPAM para que nenhuma outra máquina possa usar endereços IP desse intervalo. É necessário um intervalo mínimo de /21.
Lembrete: Conforme declarado acima, esse é um intervalo de IP virtual e você não tem que criar uma sub-rede com esse intervalo. Você só precisa garantir que nenhuma outra máquina na rede receba esses endereços.
Ao decidir sobre o intervalo de IPs, tenha em mente estes pontos:
O objetivo desse CIDR no tipo do Horizon Edge do AKS é que os endereços desse intervalo de IPs virtuais sejam atribuídos aos serviços em execução no cluster do AKS do Edge. O tamanho do intervalo /21 é necessário porque está relacionado ao número de nós que o cluster AKS terá. Cada nó do cluster do AKS obtém a pré-alocação com 256 endereços IP desse intervalo. |
