Conceitos de rede para implantar nós do Serviço Azure Kubernetes (AKS) no Azure Stack HCI


Existem dois modelos de atribuição de endereços IP para escolher, dependendo da arquitetura de rede AKS on Azure Stack HCI que você escolhe usar.

Nota

A arquitetura de networking virtual definida aqui para aKS em Azure Stack HCI implementações poderia ser diferente da arquitetura de networking físico subjacente em um centro de dados.

  • Rede IP estática - A rede virtual aloca endereços IP estáticos ao servidor API do cluster Kubernetes, nómadas Kubernetes, VMs subjacentes, equilibradores de carga e quaisquer serviços Kubernetes que funcionam em cima do cluster.

  • Rede DHCP - A rede virtual atribui endereços IP dinâmicos aos nós Kubernetes, VMs subjacentes e equilibradores de carga utilizando um servidor DHCP. O servidor API do cluster Kubernetes e quaisquer serviços Kubernetes que execute em cima do seu cluster, ainda são alocados endereços IP estáticos.

Piscina IP virtual

O pool IP virtual (VIP) é um conjunto de endereços IP que são obrigatórios para qualquer AKS na implementação HCI da Pilha de Azure. O pool VIP é uma gama de endereços IP reservados utilizados para alocar endereços IP ao servidor API do cluster Kubernetes e para os serviços Kubernetes para garantir que as suas aplicações são sempre alcançáveis. Independentemente do modelo de rede virtual e do modelo de atribuição de endereços que escolher, tem de fornecer uma piscina VIP para a sua implementação de anfitrião AKS.

O número de endereços IP na piscina VIP depende do número de aglomerados de carga de trabalho e serviços Kubernetes planeados para a sua implantação.

Dependendo do seu modelo de networking, a definição de piscina VIP diferirá das seguintes formas:

  • IP Estático - Se estiver a utilizar IP estático, certifique-se de que os seus endereços IP virtuais são da mesma sub-rede fornecida.
  • DHCP - Se a sua rede estiver configurada com DHCP, terá de trabalhar com o seu administrador de rede e excluir a gama IP do pool VIP do âmbito DHCP utilizado para a implementação AKS on Azure Stack HCI.

Kubernetes node VM IP pool

Os nós kubernetes são implantados como máquinas virtuais especializadas numa implantação AKS em Azure Stack HCI. AKS on Azure Stack HCI atribui endereços IP a estas máquinas virtuais para permitir a comunicação entre nós kubernetes.

  • IP estático - Você deve especificar uma gama de piscina de nó de NºS VM de Kubernetes. O número de endereços IP nesta gama depende do número total de nós Kubernetes que planeia implementar através dos clusters de hospedagens AKS e carga de trabalho dos clusters Kubernetes. Deve ter em conta que as atualizações consumirão um a três endereços IP adicionais durante a atualização.
  • DHCP - Não é necessário especificar um conjunto de VM de nó de Kubernetes, uma vez que os endereços IP dos nós Kubernetes são atribuídos dinamicamente pelo servidor DHCP na sua rede.

Este modelo de rede cria uma rede virtual que atribui endereços IP de uma piscina de endereços estáticamente definida a todos os objetos da sua implementação. Um benefício adicional da utilização de redes IP estáticas é que as implementações de longa duração e as cargas de trabalho das aplicações são garantidas para serem sempre alcançáveis.

Especifique os seguintes parâmetros ao definir uma rede virtual com configurações ip estáticas:

Importante

Nesta versão do AKS no Azure Stack HCI, não é possível alterar a configuração da rede uma vez que o hospedeiro AKS ou o cluster de carga de trabalho são implantados. A única maneira de alterar as definições de rede é começar de novo removendo o(s) cluster(s) de carga de trabalho e desinstalar AKS em Azure Stack HCI.

  • Nome: O nome da sua rede virtual.

  • Prefixo do endereço: O prefixo do endereço IP para utilizar para a sua sub-rede.

  • Gateway: O endereço IP do portal predefinido para a sub-rede.

  • Servidor DNS: Uma série de endereços IP que apontam para os servidores DNS a serem utilizados para a sub-rede. Um mínimo de um e um máximo de três servidores podem ser fornecidos.

  • Piscina de VM node Kubernetes: Uma gama contínua de endereços IP a serem utilizados para os seus VMs de nó de Kubernetes.

  • Piscina IP virtual: Uma gama contínua de endereços IP a serem utilizados para os seus serviços de API de cluster Kubernetes e serviços Kubernetes.

    Nota

    A piscina VIP deve fazer parte da mesma sub-rede que a piscina de nó vm de kubernetes.

  • vLAN ID: O iD vLAN para a rede virtual. Se omitido, a rede virtual não será marcada.

Rede virtual com rede DHCP

Este modelo de rede cria uma rede virtual que atribui endereços IP utilizando DHCP a todos os objetos na implementação.

Deve especificar os seguintes parâmetros ao definir uma rede virtual com configurações ip estáticas:

Importante

Nesta versão do AKS no Azure Stack HCI, não é possível alterar a configuração da rede uma vez que o hospedeiro AKS ou o cluster de carga de trabalho são implantados. A única maneira de alterar as definições de rede é começar de novo removendo o(s) cluster(s) de carga de trabalho e desinstalar AKS em Azure Stack HCI.

  • Nome: O nome da sua rede virtual.

  • Piscina IP virtual: A gama contínua de endereços IP a utilizar para os seus serviços de API de cluster Kubernetes e serviços Kubernetes.

    Nota

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

  • vLAN ID: O iD vLAN para a rede virtual. Se omitido, a rede virtual não será marcada.

Serviço Cloud microsoft on-in

Microsoft On-premises Cloud (MOC) é a pilha de gestão que permite que máquinas virtuais em Azure Stack HCI e Windows SDDC baseado em servidor seja gerido na nuvem. O MOC consiste em:

  • Uma única instância de um serviço altamente disponível cloud agent implantado no cluster. Este agente funciona em qualquer nó no cluster HCI da Pilha de Azure e está configurado para falhar em outro nó.
  • Uma node agent corrida em cada nó físico Azure Stack HCI.

Para ativar a comunicação com o MOC, é necessário fornecer o CIDR do Endereço IP para ser utilizado para o serviço. O -cloudserviceCIDR é um parâmetro no comando que é usado para atribuir o endereço IP ao serviço de agente de Set-AksHciConfig nuvem e permitir uma alta disponibilidade do serviço de agente de nuvem.

A escolha de um endereço IP para o serviço MOC depende do modelo de rede subjacente utilizado pela sua implantação do cluster HCI Azure Stack.

Nota

A atribuição de endereços IP para o serviço MOC é independente do seu modelo de rede virtual Kubernetes. A atribuição de endereços IP depende da rede física subjacente e os endereços IP configurados para os nós de cluster HCI da Pilha de Azure stack no seu centro de dados.

  • Os nós do cluster HCI da Azure Stack com um modo de atribuição de endereço IP baseado em DHCP: Se os seus nós HCI da Stack Azure Forem atribuídos um endereço IP a partir de um servidor DHCP presente na rede física, então não precisa de fornecer explicitamente um endereço IP ao serviço MOC, uma vez que o serviço MOC também receberá um endereço IP a partir do servidor DHCP.

  • Os nós do cluster HCI da Stack Azure Stack com um modelo estático de atribuição de IP: Se os seus nós de cluster HCI da Pilha de Azure forem atribuídos endereços IP estáticos, então deve fornecer explicitamente um endereço IP para o serviço de nuvem MOC. O endereço IP para o serviço MOC deve estar na mesma sub-rede que os endereços IP dos nós de cluster HCI da Stack Azure. Para atribuir explicitamente um endereço IP para o serviço MOC, utilize o -cloudserviceCIDR parâmetro no Set-AksHciConfig comando. Certifique-se de que introduz um endereço IP no formato CIDR, por exemplo: "10.11.23.45/16".

Comparar modelos de rede

Tanto o DHCP como o STATIC IP fornecem conectividade de rede para a sua implementação AKS na Azure Stack HCI. No entanto, há vantagens e desvantagens para cada um. A um nível elevado, aplicam-se as seguintes considerações:

DHCP - Não garante endereços IP de longa duração para alguns tipos de recursos numa implantação AKS on Azure Stack HCI. - Suporta a expansão de endereços IP DHCP reservados se a sua implementação for maior do que inicialmente previsto.

IP estático - Garante endereços IP de longa duração para todos os recursos numa implantação AKS on Azure Stack HCI. - Uma vez que a expansão automática do conjunto IP do nó de Kubernetes não é suportada, poderá não ser capaz de criar novos clusters se tiver esgotado o conjunto IP do nó de Kubernetes.

O quadro que se segue compara a atribuição de endereços IP para recursos entre modelos estáticos de PI e DHCP:

Funcionalidade IP estático DHCP
Servidor API de cluster Kubernetes Atribuído estática usando piscina VIP Atribuído estática usando piscina VIP
Nós kubernetes (em máquinas virtuais) Atribuído usando o conjunto IP do nó de Kubernetes Atribuído dinamicamente
Serviços do Kubernetes Atribuído estática usando piscina VIP Atribuído estática usando piscina VIP
VM equilibrador de carga HAProxy Atribuído usando o conjunto IP do nó de Kubernetes Atribuído dinamicamente
Microsoft On-Premise Cloud Service Depende da configuração física de networking para os nóns de cluster HCI da Azure Stack HCI Depende da configuração física de networking para os nóns de cluster HCI da Azure Stack HCI
Piscina VIP Obrigatório Obrigatório
Kubernetes node VM IP pool Obrigatório Não suportado

Reservas mínimas de endereço IP para uma implantação AKS em Azure Stack HCI

Independentemente do seu modelo de implementação, o número de endereços IP reservados permanece o mesmo. Esta secção fala sobre o número de endereços IP para reservar com base no seu modelo de implementação AKS no Azure Stack HCI.

Reserva mínima de endereço IP

No mínimo, deverá reservar o seguinte número de endereços IP para a sua implantação:

Tipo de cluster Nó de avião de controlo Nó do trabalhador Para operações de atualização Balanceador de carga
Anfitrião AKS 1 IP ND 2 IP ND
Cluster de carga de trabalho 1 IP por nó 1 IP por nó 5 IP 1 IP

Além disso, deverá reservar o seguinte número de endereços IP para a sua piscina VIP:

Tipo de recurso Número de endereços IP
Servidor API cluster 1 por aglomerado
Serviços do Kubernetes 1 por serviço
Application Services 1 por serviço planeado

Como pode ver, o número de endereços IP necessários é variável dependendo da AKS na arquitetura HCI Azure Stack e do número de serviços que executa no seu cluster Kubernetes. Recomendamos reservar um mínimo de 256 endereços IP (sub-rede/24) para a sua implantação.

Caminhando através de um exemplo de implantação

Jane é uma administradora de TI que começa com a AKS no Azure Stack HCI. Ela quer implantar dois clusters Kubernetes - o cluster A e Kubernetes cluster B no seu cluster Azure Stack HCI. Ela também quer fazer um pedido de voto em cima do seu agrupamento. Esta aplicação tem três instâncias da UI frontal que atravessa os dois clusters e uma instância da base de dados backend.

  • O cluster Kubernetes A tem 3 nóns de avião de controlo e 5 nóns de trabalhador
  • O cluster B de Kubernetes tem 1 nó de avião de controlo e 3 nóiros de trabalhadores
  • 3 instâncias da UI frontal (porta 443)
  • 1 instância da base de dados de backend (porta 80)

Com base na tabela acima, ela terá que reservar:

  • 3 endereços IP para o anfitrião AKS (um IP para nó de avião de controlo e dois IPs para operações de atualização em execução)
  • 3 endereços IP para os nós do plano de controlo no cluster A (um nó de plano IP por controlador)
  • 5 endereços IP para os nós do trabalhador no agrupamento A (um nó IP por trabalhador)
  • 6 endereços IP adicionalmente para o cluster A (cinco IPs para operações de atualização em execução e 1 IP para o balanceador de carga)
  • 1 Endereços IP para os nós do plano de controlo no grupo B (um nó de plano IP por plano de controlo)
  • 3 endereços IP para os nós do trabalhador no grupo B (um nó IP por trabalhador)
  • 6 endereços IP adicionalmente para o cluster B (cinco IPs para operações de atualização em execução e 1 IP para o balanceador de carga)
  • 2 endereços IP para os servidores API do cluster Kubernetes (um ip por cluster Kubernetes)
  • 3 endereços IP para o serviço Kubernetes (um endereço IP por exemplo da UI frontal, uma vez que todos utilizam a mesma porta. A base de dados backend pode usar qualquer um dos três endereços IP desde que utilize uma porta diferente)

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

Divisão de endereços IP reservados com base num modelo estático de rede IP

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

  • Kubernetes node VM IP pool - para Kubernetes node VMs e o equilibrador de carga VM. Este pool IP também inclui o endereço IP necessário para executar operações de atualização.
  • Piscina IP virtual - para os serviços kubernetes API e Kubernetes.

Trabalhando com o exemplo acima, a Jane deve dividir ainda mais estes endereços IP através de piscinas VIP e piscinas IP de nó kubernetes:

  • 5 (dois para o servidor API do cluster Kubernetes e três para os serviços Kubernetes) dos 32 endereços IP para a sua piscina VIP.
  • 27 (todos os endereços IP para os seus nós Kubernetes e VMs subjacentes, vMs do balançador de carga e operações de atualização) para o seu conjunto IP de nó de Kubernetes.

Divisão de endereços IP reservados com base num 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 estes endereços IP são divididos entre grupos IP.s. Como discutido anteriormente, o modelo de rede DHCP tem um âmbito IP:

  • Piscina IP virtual - para os serviços de API da Kubernetes e Kubernetes

Trabalhando com o exemplo acima:

  • A Jane deve reservar um total de 32 endereços IP ou uma sub-rede /26 no servidor DHCP.
  • Ela deve excluir 5 (dois para o servidor API cluster Kubernetes e três para os serviços Kubernetes) do âmbito DHCP de 32 endereços IP para a sua piscina VIP.

Controladores de entrada

Durante a implantação de um cluster alvo, é criado um HAProxy recurso de balançador de carga baseado. O balançador de carga está configurado para distribuir o tráfego para as cápsulas do seu serviço numa determinada porta. O equilibrador de carga só funciona na camada 4, o que significa que o Serviço desconhece as aplicações reais, e não pode fazer nenhuma consideração adicional de encaminhamento.

Os controladores ingress funcionam na camada 7 e podem usar regras mais inteligentes para distribuir o tráfego de aplicações. Um uso comum de um controlador Ingress é encaminhar o tráfego HTTP para diferentes aplicações com base no URL de entrada.

Diagram showing Ingress traffic flow in an AKS-HCI cluster

Passos seguintes

Este artigo abrange alguns dos conceitos de networking para a implementação de nós AKS no Azure Stack HCI. Para obter mais informações sobre os conceitos AKS sobre Azure Stack HCI, consulte os seguintes artigos: