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ê leu a seção Decidir sobre seu tipo de implantação e atender a seus requisitos, respondeu às perguntas e decidiu usar o tipo AKS para a migração do pod.
Importante: ao planejar usar o tipo de implantação AKS, além de atender aos pré-requisitos descritos nas seções abaixo, você também deve garantir que atenderá aos pré-requisitos descritos nas seções da página Pré-requisitos para migrar um pod do Horizon Cloud de primeira geração.
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ê deseja implantar usando o tipo AKS, mas a VNet do pod de primeira geração ou a rede local conectada a essa VNet contém endereços IP dos intervalos de IP restritos ao AKS, para um tipo de implantação do AKS, você deve:
- 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 tendo um CIDR mínimo
/26. - Verifique se a nova VNet e a sub-rede de gerenciamento permitem a comunicação de rede com os endpoints necessários do serviço do Horizon Cloud, 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.
Nota:
Os intervalos de IP restritos do AKS a serem evitados são:
169.254.0.0/16172.30.0.0./16172.31.0.0/16192.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 de 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 | |
|---|---|
| Novos adicionais para registrar o tipo de implantação do Horizon Cloud AKS |
|
| Necessário para o Horizon Cloud que teria sido registrado anteriormente para seu pod de primeira geração |
|
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 a opção de menu
(Provedores de recursos). -
Procure os provedores de recursos na tabela anterior e verifique se cada um deles exibe o ícone
(Registrado).Use o portal do Azure para registrar quaisquer provedores de recursos da tabela que tenha um status de
NotRegistered.
Importante: não cancele o registro de provedores de recursos já registrados.
Você pode ver que a assinatura do pod já tem os provedores de recursos necessários para o Horizon Cloud Edge Gateway em status Registered. Você também pode ver provedores de recursos registrados, como Microsoft.Billing, que não estão relacionados àqueles exigidos pelo serviço do Horizon Cloud. 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)
Importante: qualquer que seja a sub-rede que você criar, verifique se associá-la à sub-rede de gerenciamento apropriada: seja à sub-rede de gerenciamento existente do pod ou à nova sub-rede de gerenciamento, caso você tenha que criar uma nova para contornar sua VNet com endereços IP restritos do AKS.
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 em que nomeamos nosso gateway NAT como
first-pod-migration. Ele reside na região do AzureWest 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 desta etapa, em que escolhemos criar um novo IP público para este gateway NAT usar e demonstrações 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: lembre-se de que, se você decidir 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 Contributorno 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 em que nomeamos nossa tabela de rotas como
first-pod-migration. Ele reside na região do AzureWest 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/0apontando para um próximo salto do tipoVirtual network gatewayouVirtual 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.
Virtual Applianceé normalmente usado quando você tem um Azure Network Virtual Appliance (NVA) 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). Essa NVA deve permitir tráfego para os endpoints que o ambiente do Horizon Cloud 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 do tipo Avançar salto é expandido nesta ilustração para mostrar onde as opções com suporte
Virtual network gatewayeVirtual appliancesão mostradas. Além disso, digitamos um nome para a rota e o endereço IP de destino0.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
Network Contributorno 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 Operatorno 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 de Operador de Identidade Gerenciada | A assinatura do Microsoft Azure do pod |
| Função de Colaborador de Rede | O grupo de recursos da VNet. A VNet aplicável é:
|
Observação: de acordo com a documentação do Microsoft RBAC, você deve ter permissões Microsoft.Authorization/roleAssignments/write para atribuir funções do Azure.
-
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 Operatorpara 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 Contributorpara 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 de Operador de Identidade Gerenciada | A assinatura do Microsoft Azure do pod |
| Função de Colaborador de Rede | O grupo de recursos da VNet. A VNet aplicável é:
|
Observação: de acordo com a documentação do Microsoft RBAC, sua ID de usuário no Azure deve ter permissões Microsoft.Authorization/roleAssignments/write para atribuir funções do Azure.
-
Primeiro, adicione a permissão do
Managed Identity Operatorao 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 + Adicionar > Adicionar atribuição de função.

O assistente de Adicionar atribuição de função é exibido.
-
No assistente, na guia Função, procure e selecione a função
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 Contributorao 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.
Essa captura de tela ilustra esta etapa para o grupo de recursos de nossa VNet chamado
hcsvnet-RG.
-
Clique em + Adicionar > Adicionar atribuição de função. O assistente de Adicionar atribuição de função é exibido.
-
No assistente, na guia Função, procure e selecione a função
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.
Essa captura de tela ilustra esta etapa para o grupo de recursos de nossa VNet chamado
hcsvnet-RG.
-
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: reserve intervalos de IP virtuais obrigató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
/27para o que é chamado de CIDR de serviço - Um intervalo CIDR mínimo de
/21para o que é chamado de Pod CIDR
Esses dois intervalos de IP não devem se sobrepor ou colidir um com o outro.
Importante: de acordo com a documentação do Azure, esses CIDRs não devem usar os seguintes intervalos restritos do AKS:
- 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 um intervalo de IP para o CIDR de serviço e reserve esse espaço de IP em seu IPAM para que nenhuma outro computador possa usar endereços IP desse intervalo.
É necessário um intervalo mínimo de /27.Lembre-se: como mencionado acima, este é um intervalo de IP virtual e você não precisa criar uma sub-rede com este 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:
|
| CIDR do POD | Decida um intervalo de IP para o Pod CIDR e reserve esse espaço de IP em seu IPAM para que nenhuma outro computador possa usar endereços IP desse intervalo.
É necessário um intervalo mínimo de /21.Lembre-se: como mencionado acima, este é um intervalo de IP virtual e você não precisa criar uma sub-rede com este 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:
|
Esta página foi útil?