Conceitos de rede para implantar nós do AKS

Aplica-se a: AKS no Windows Server

Você pode escolher entre dois modelos de atribuição de endereço IP para sua arquitetura de rede para AKS no Windows Server. O AKS dá suporte a várias opções de implantação para o AKS (Serviço de Kubernetes do Azure):

• Rede IP estática: a rede virtual aloca endereços IP estáticos para o servidor de API de cluster do Kubernetes, nós do Kubernetes, VMs subjacentes, balanceadores de carga e quaisquer 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 de cluster do Kubernetes e todos os serviços do Kubernetes executados além do cluster ainda são alocados endereços IP estáticos.

Pool de IP virtual

Um pool de IP virtual (VIP) é um conjunto de endereços IP obrigatórios para qualquer implantação no AKS Arc. O pool VIP é um intervalo de endereços IP reservados usados para alocar endereços IP para o servidor de API de cluster do Kubernetes. Ele garante que seus aplicativos nos serviços do Kubernetes estejam sempre acessíveis. Lembre-se de que, independentemente do modelo de rede virtual e do modelo de atribuição de endereço escolhido, você deve fornecer um pool VIP para a implantação do host do AKS.

O número de endereços IP no pool VIP depende do número de clusters de carga de trabalho e serviços do Kubernetes planejados para sua implantação.

Dependendo do seu modelo de rede, a definição do pool VIP é diferente nestes aspectos:

• IP estático: se você estiver usando IP estático, certifique-se de que seus endereços IP virtuais sejam da mesma sub-rede fornecida.
• DHCP: se sua rede estiver configurada com DHCP, trabalhe com o administrador de rede para excluir o intervalo de IP do pool VIP do escopo DHCP usado para a implantação do AKS.

Pool de IP da VM do nó do Kubernetes

Os nós do Kubernetes são implantados como máquinas virtuais especializadas no AKS Arc. O AKS aloca endereços IP a essas máquinas virtuais para habilitar a comunicação entre nós do Kubernetes.

• IP estático: é necessário especificar um intervalo de pool de IP da VM do nó do Kubernetes. O número de endereços IP nesse intervalo depende do número total de nós do Kubernetes que você planeja usar para implantar no host do AKS e nos clusters do Kubernetes de carga de trabalho. Lembre-se de que as atualizações consomem de um a três endereços IP adicionais durante a atualização.
• DHCP: você não precisa especificar um pool de VMs do nó do Kubernetes, pois os endereços IP para os nós do Kubernetes são alocados dinamicamente pelo servidor DHCP na sua rede.

Rede virtual com rede IP estática (recomendado)

Esse modelo de rede cria uma rede virtual que aloca endereços IP de um pool de endereços definido estaticamente para todos os objetos na sua implantação. Um benefício adicional do uso de redes IP estáticas é que as implantações de longa duração e cargas de trabalho de aplicativos têm a garantia de estar sempre acessíveis.

Especifique os seguintes parâmetros ao definir uma rede virtual com configurações de IP estático:

• Nome: o nome da sua rede virtual.

• Prefixo de endereço: o prefixo de endereço IP a ser usado para sua sub-rede.

• Gateway: o endereço IP do gateway padrão da sub-rede.

• Servidor DNS: uma matriz de endereços IP apontando para os servidores DNS a serem usados para a sub-rede. Um mínimo de um e um máximo de três servidores podem ser fornecidos.

• Pool de VMs do nó do Kubernetes: um intervalo contínuo de endereços IP a serem usados para suas VMs de nó do Kubernetes.

• Pool de IP Virtual: um intervalo contínuo de endereços IP a serem usados para o servidor de API de cluster do Kubernetes e os serviços do Kubernetes.

  Observação

  O pool VIP deve fazer parte da mesma sub-rede que o pool de VMs do nó do Kubernetes.

• ID da vLAN: o ID da vLAN da rede virtual. Se for omitida, a rede virtual não será marcada.

Rede virtual com rede DHCP

Esse modelo de rede cria uma rede virtual que aloca endereços IP usando DHCP para todos os objetos na implantação.

Você deve especificar os seguintes parâmetros ao definir uma rede virtual com configurações de IP estático:

• Nome: o nome da sua rede virtual.

• Pool de IP Virtual: o intervalo contínuo de endereços IP a serem usados para o servidor de API de cluster do Kubernetes e os serviços do Kubernetes.

  Observação

  Os endereços do pool VIP devem estar na mesma sub-rede que o escopo DHCP e devem ser excluídos do escopo DHCP para evitar conflitos de endereço.

• ID da vLAN: o ID da vLAN da rede virtual. Se for omitida, a rede virtual não será marcada.

Serviço de nuvem local da Microsoft

O MOC (Microsoft On-premises Cloud) é a pilha de gerenciamento que permite que as máquinas virtuais no SDDC baseado no Windows Server sejam gerenciadas na nuvem. O MOC consiste de:

• Uma única instância de um serviço cloud agent altamente disponível implantado no cluster. Esse agente é executado em qualquer nó no cluster do Windows Server e está configurado para fazer failover para outro nó.
• Um node agent em execução em cada nó físico.

Para habilitar a comunicação com o MOC, você deve fornecer o CIDR do endereço IP a ser usado para o serviço. O -cloudserviceCIDR é um parâmetro no comando Set-AksHciConfig usado para atribuir o endereço IP ao serviço do agente de nuvem e habilitar a alta disponibilidade do serviço do agente de nuvem.

A escolha de um endereço IP para o serviço MOC depende do modelo de rede subjacente usado pela implantação do cluster no Windows Server.

• Nós dos clusters do Windows Server com modo de alocação de endereço IP baseado em DHCP: Se os nós do cluster recebem um endereço IP de um servidor DHCP presente na rede física, você não precisará fornecer explicitamente um endereço IP para o serviço MOC, pois o serviço MOC também recebe um endereço IP do servidor DHCP.

• Nós do cluster do Windows Server com um modelo de alocação de IP estático: se os nós do cluster forem atribuídos endereços IP estáticos, então você deve fornecer explicitamente um endereço IP para o serviço de nuvem MOC. O endereço IP do serviço MOC deve estar na mesma sub-rede que os endereços IP dos nós de cluster do Windows Server. Para atribuir explicitamente um endereço IP para o serviço MOC, use o parâmetro -cloudserviceCIDR no comando Set-AksHciConfig. Insira um endereço IP no formato CIDR, por exemplo: 10.11.23.45/16.

Comparar modelos de rede

O DHCP e o IP estático fornecem conectividade de rede em seu AKS na implantação do Windows Server. Há vantagens e desvantagens em cada método. Em um alto nível, as seguintes considerações se aplicam:

DHCP – não garante endereços IP de longa duração para alguns tipos de recursos em uma implantação do AKS. - Oferece suporte à expansão de endereços IP DHCP reservados se a sua implantação ficar maior do que o previsto inicialmente.

IP estático – garante endereços IP de longa duração para todos os recursos em uma implantação do AKS. - Como não há suporte à expansão automática do pool de IPs do nó do Kubernetes, talvez você não consiga criar clusters se tiver esgotado o pool de IPs do nó do Kubernetes.

A tabela a seguir compara a alocação de endereços IP para recursos entre modelos de rede IP estático e DHCP:

Reservas mínimas de endereço IP para uma implantação do AKS

Independentemente do seu modelo de implantação, o número de endereços IP reservados permanece o mesmo. Esta seção descreve o número de endereços IP que você precisa reservar com base no modelo de implantação do AKS Arc.

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:

Você também deve reservar o seguinte número de endereços IP para o pool de VIP:

Como você pode ver, o número de endereços IP necessários é variável dependendo da arquitetura da implantação do AKS e do número de serviços executados no cluster do Kubernetes. É recomendável reservar um mínimo de 256 endereços IP (sub-rede /24) para sua implantação.

Apresentação de um exemplo de implantação

Jane é uma administradora de TI que está começando com o AKS no Windows Server. Ela deseja implantar dois clusters do Kubernetes: cluster do Kubernetes A e cluster do Kubernetes B em seu cluster do Windows Server. Ela também quer executar um aplicativo de votação além de seu cluster. Esse aplicativo tem três instâncias da interface do usuário de front-end em execução nos dois clusters e uma instância do banco de dados de back-end.

• O cluster A do Kubernetes tem três nós de plano de controle e cinco nós de trabalho.
• O cluster B do Kubernetes tem 1 nó de plano de controle e 3 nós de trabalho.
• Três (3) instâncias da interface do usuário de front-end (porta 443).
• 1 instância do banco de dados back-end (porta 80).

Com base na tabela anterior, ela deve reservar:

• 3 endereços IP para o host AKS (um IP para o nó do plano de controle e dois IPs para executar operações de atualização).
• 3 endereços IP para os nós do plano de controle no cluster A (um IP por nó).
• 5 endereços IP para os nós de trabalho no cluster A (um IP por nó de trabalho).
• 6 endereços IP adicionais para o cluster A (cinco IPs para executar operações de atualização e 1 IP para o balanceador de carga).
• 1 endereços IP para os nós do plano de controle no cluster B (um IP por nó).
• 3 endereços IP para os nós de trabalho no cluster B (um IP por nó de trabalho).
• 6 endereços IP adicionais para o cluster B (cinco IPs para executar operações de atualização e 1 IP para o balanceador de carga).
• 2 endereços IP para os servidores de API de cluster do Kubernetes (um IP por cluster do Kubernetes).
• 3 endereços IP para o serviço Kubernetes (um endereço IP por instância da interface do usuário de front-end, já que todos usam a mesma porta. O banco de dados de back-end pode usar qualquer um dos três endereços IP, desde que use uma porta diferente).

Conforme explicado anteriormente, Jane requer um total de 32 endereços IP para implantar o cluster. Jane deve, portanto, reservar uma sub-rede /26 para sua rede virtual.

Dividir endereços IP reservados com base em um modelo de rede IP estático

Embora o número total de endereços IP reservados permaneça o mesmo, o modelo de implantação determina como esses endereços IP são divididos entre os grupos de IP. O modelo de rede IP estático tem dois pools de IP:

• Pool de IPs de nó de VM do Kubernetes: para VMs de nó de Kubernetes e a VM do balanceador de carga. Esse pool de IP também inclui o endereço IP necessário para executar operações de atualização.
• Pool de IP Virtual : para o servidor de API do Kubernetes e os serviços do Kubernetes.

Ao trabalhar com este exemplo, Jane precisa dividir esses endereços IP ainda mais entre pools VIP e pools de IPs dos nós do Kubernetes.

• 5 (dois para o servidor de API de cluster do Kubernetes e três para os serviços do Kubernetes) dos 32 endereços IP do pool VIP.
• 27 (todos os endereços IP dos seus nós do Kubernetes e das VMs subjacentes, as VMs do balanceador de carga e as operações de atualização) do pool de IPs dos nós do Kubernetes.

Dividir endereços IP reservados com base em um modelo de rede DHCP

Embora o número total de endereços IP reservados permaneça o mesmo, o modelo de implantação determina como esses endereços IP são divididos entre o(s) grupo(s) de IP. Conforme discutido na seção anterior, o modelo de rede DHCP tem um escopo de IP:

• Pool de IP Virtual : para o servidor de API do Kubernetes e os serviços do Kubernetes.

Trabalhando com o exemplo anterior:

• Jane deve reservar um total de 32 endereços IP ou uma sub-rede /26 em seu servidor DHCP.
• Ela deve excluir 5 (dois para o servidor de API de cluster do Kubernetes e três para serviços do Kubernetes) do escopo DHCP de 32 endereços IP para seu pool VIP.

Controladores de entrada

Durante a implantação de um cluster de destino, um recurso de balanceador de carga baseado em HAProxy é criado. O balanceador de carga é configurado para distribuir o tráfego para os pods em seu serviço em uma determinada porta. O balanceador de carga só funciona na camada 4, o que indica que o serviço não está ciente do aplicativo real. Ou seja, ele não pode fazer nenhuma consideração de roteamento adicional.

Os controladores de entrada funcionam na camada 7 e podem usar regras mais inteligentes para distribuir o tráfego de aplicativos. Um uso comum de um controlador de entrada é rotear o tráfego HTTP para diferentes aplicativos com base na URL de entrada.

Próximas etapas

Este artigo aborda alguns dos conceitos de rede para implantar nós do AKS no Windows Server. Para obter mais informações, consulte os seguintes artigos:

• Conceitos de rede de contêiner
• Cluster e cargas de trabalho
• Implantar um cluster de carga de trabalho do Kubernetes