Requisitos de planejamento de endereço IP
Aplica-se a: Azure Local, versão 23H2
O planejamento de endereço IP para o AKS habilitado pelo Azure Arc envolve a criação de uma rede que dá suporte a aplicativos, pools de nós, redes de pod, comunicação de serviço e acesso externo. Este artigo orienta você por algumas considerações importantes para o planejamento eficaz de endereços IP e o número mínimo de endereços IP necessários para implantar o AKS em produção. Consulte os conceitos e requisitos de rede do AKS antes de ler este artigo.
Planejamento simples de endereços IP para clusters e aplicativos Kubernetes
No passo a passo do cenário a seguir, você reserva endereços IP de uma única rede para seus clusters e serviços do Kubernetes. Este exemplo é o cenário mais direto e simples para atribuição de endereço IP.
| Requisito de endereço IP | Número mínimo de endereços IP | Como e onde fazer esta reserva |
|---|---|---|
| AKS Arc VM IPs | Reserve um endereço IP para cada nó de trabalho no cluster do Kubernetes. Por exemplo, se você quiser criar 3 pools de nós com 3 nós em cada pool de nós, precisará de 9 endereços IP em seu pool de IPs. | Reserve endereços IP por meio de pools de IP na rede lógica da VM do Arc. |
| IPs de atualização de versão do AKS Arc K8s | Como o AKS Arc executa atualizações sem interrupção, reserve um endereço IP para cada cluster do AKS Arc para operações de atualização de versão do Kubernetes. | Reserve endereços IP por meio de pools de IP na rede lógica da VM do Arc. |
| IP do plano de controle | Reserve um endereço IP para cada cluster do Kubernetes em seu ambiente. Por exemplo, se você quiser criar 5 clusters no total, reserve 5 endereços IP, um para cada cluster do Kubernetes. | Reserve endereços IP por meio de pools de IP na rede lógica da VM do Arc. |
| IPs do balanceador de carga | O número de endereços IP reservados depende do modelo de implantação do aplicativo. Como ponto de partida, você pode reservar um endereço IP para cada serviço do Kubernetes. | Reserve endereços IP na mesma sub-rede que a rede lógica da VM do Arc, mas fora do pool de IP. |
Exemplo de passo a passo para reserva de endereço IP para clusters e aplicativos do Kubernetes
Jane é uma administradora de TI que está começando com o AKS habilitado pelo Azure Arc. Jane deseja implantar dois clusters do Kubernetes: cluster A do Kubernetes e cluster B do Kubernetes no cluster local do Azure. Jane também deseja executar um aplicativo de votação sobre o cluster A. 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. Todos os clusters e serviços do AKS estão em execução em uma única rede, com uma única sub-rede.
- O cluster A do Kubernetes tem 3 nós do plano de controle e 5 nós de trabalho.
- O cluster B do Kubernetes tem 1 nó de plano de controle e 3 nós de trabalho.
- 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, Jane deve reservar um total de 19 endereços IP na sub-rede de Jane:
- 8 endereços IP para as VMs do nó do AKS Arc no cluster A (um IP por VM do nó K8s).
- 4 endereços IP para as VMs do nó do AKS Arc no cluster B (um IP por VM do nó K8s).
- 2 endereços IP para executar a operação de atualização do AKS Arc (um endereço IP por cluster do AKS Arc).
- 2 endereços IP para o painel de controle do AKS Arc (um endereço IP por cluster do AKS Arc)
- 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).
Continuando com este exemplo e adicionando-o à tabela a seguir, você obtém:
| Parâmetro | Número de endereços IP | Como e onde fazer esta reserva |
|---|---|---|
| VMs do AKS Arc, atualização de versão do K8s e IP do painel de controle | Reservar 16 endereços IP | Faça essa reserva por meio de pools de IP na rede lógica local do Azure. |
| IPs do balanceador de carga | 3 Endereço IP para serviços Kubernetes, para o aplicativo de votação de Jane. | Esses endereços IP são usados quando você instala um balanceador de carga no cluster A. Você pode usar a extensão MetalLB Arc ou trazer seu próprio balanceador de carga de terceiros. Certifique-se de que esse IP esteja na mesma sub-rede que a rede lógica do Arc, mas fora do pool de IPs definido na rede lógica da VM do Arc. |
Exemplo de comandos da CLI para reserva de endereço IP para clusters e aplicativos do Kubernetes
Esta seção descreve o conjunto de comandos que Jane executa para seu cenário. Primeiro, crie uma rede lógica com um pool de IP que tenha pelo menos 16 endereços IP. Criamos o pool de IP com 20 endereços IP para fornecer a opção de escalar no dia N. Para obter informações detalhadas sobre opções de parâmetro em redes lógicas, consulte az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Em seguida, crie um cluster do AKS Arc com a rede lógica anterior:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Agora você pode habilitar o balanceador de carga MetalLB com um pool de IP de 3 endereços IP, na mesma sub-rede que a rede lógica Arc VM. Você pode adicionar mais pools de IPs posteriormente se seu aplicativo precisar de um aumento. Para requisitos detalhados, consulte a visão geral da extensão MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Considerações de LNETs para clusters do AKS e VMs do Arc
As redes lógicas no Azure Local são usadas por clusters do AKS e VMs do Arc. Você pode configurar redes lógicas de uma das 2 maneiras a seguir:
- Compartilhe uma rede lógica entre VMs do AKS e do Arc.
- Defina redes lógicas separadas para clusters do AKS e VMs do Arc.
O compartilhamento de uma rede lógica entre VMs do AKS e do Arc no Azure Local oferece o benefício de comunicação simplificada, economia de custos e gerenciamento de rede simplificado. No entanto, essa abordagem também apresenta desafios potenciais, como contenção de recursos, riscos de segurança e complexidade na solução de problemas.
| Critérios | Compartilhando uma rede lógica | Definindo redes lógicas separadas |
|---|---|---|
| Complexidade da configuração | Configuração mais simples com uma única rede, reduzindo a complexidade da configuração. | Configuração mais complexa, pois você precisa configurar várias redes lógicas para VMs e clusters do AKS. |
| Escalabilidade | Possíveis limitações de escalabilidade, pois as VMs do Arc e os clusters do AKS compartilham recursos de rede. | Mais escalável, pois os recursos de rede são separados e podem ser dimensionados de forma independente. |
| Gerenciamento de políticas de rede | Mais fácil de gerenciar com um conjunto de políticas de rede, mas mais difícil de isolar cargas de trabalho. | Mais fácil de isolar cargas de trabalho, pois políticas separadas podem ser aplicadas por rede lógica. |
| Considerações de segurança | Aumento do risco de vulnerabilidades de comunicação cruzada se não forem segmentadas adequadamente. | Melhor segurança, pois cada rede pode ser segmentada e isolada com mais rigor. |
| Impacto de falhas de rede | Uma falha na rede compartilhada pode afetar as VMs do AKS e do Arc simultaneamente. | Uma falha em uma rede afeta apenas as cargas de trabalho dentro dessa rede, reduzindo o risco geral. |
Alocação de intervalo de endereços IP para CIDR de pod e CIDR de serviço
Esta seção descreve os intervalos de endereços IP usados pelo Kubernetes para comunicação de pod e serviço em um cluster. Esses intervalos de endereços IP são definidos durante o processo de criação do cluster do AKS e são usados para atribuir endereços IP exclusivos a pods e serviços dentro do cluster.
CIDR de rede de pod
O CIDR da rede de pods é um intervalo de endereços IP usados pelo Kubernetes para designar endereços IP exclusivos aos pods individuais em execução em um cluster do Kubernetes. Cada pod obtém seu próprio endereço IP dentro desse intervalo, permitindo que os pods se comuniquem entre si e com os serviços dentro do cluster. No AKS, os endereços IP do pod são atribuídos por meio do Calico CNI no modo VXLAN. O Calico VXLAN ajuda a criar redes de sobreposição, em que os endereços IP dos pods (do CIDR da rede do pod) são virtualizados e encapsulados por meio da rede física. Nesse modo, cada pod recebe um endereço IP do CIDR da rede do pod, mas esse endereço IP não é roteável diretamente na rede física. Em vez disso, ele é encapsulado nos pacotes de rede e enviado pela rede física subjacente para alcançar seu pod de destino em outro nó.
O AKS fornece um valor padrão de 10.244.0.0/16 para o CIDR da rede do pod. O AKS dá suporte a personalizações para o CIDR da rede do pod. Você pode definir seu próprio valor usando o --pod-cidr parâmetro ao criar o cluster do AKS. Certifique-se de que o intervalo de IP do CIDR seja grande o suficiente para acomodar o número máximo de pods por nó e em todo o cluster do Kubernetes.
CIDR da rede de serviços
O CIDR da rede de serviço é o intervalo de endereços IP reservados para serviços do Kubernetes, como LoadBalancers, ClusterIP e NodePort em um cluster. O Kubernetes é compatível com os seguintes tipos de serviço:
- ClusterIP: o tipo de serviço padrão, que expõe o serviço dentro do cluster. O IP atribuído do CIDR da rede de serviço só pode ser acessado no cluster do Kubernetes.
- NodePort: expõe o serviço em uma porta específica no endereço IP de cada nó. O ClusterIP ainda é usado internamente, mas o acesso externo é feito por meio dos IPs do nó e de uma porta específica.
- LoadBalancer: esse tipo cria um balanceador de carga gerenciado pelo provedor de nuvem e expõe o serviço externamente. O provedor de nuvem normalmente gerencia a atribuição de IP externo, enquanto o ClusterIP interno permanece dentro do CIDR da rede de serviço.
O AKS fornece um valor padrão de 10.96.0.0/12 para o CIDR da rede de serviço. O AKS não dá suporte a personalizações para o CIDR da rede de serviço atualmente.
Próximas etapas
Criar redes lógicas para clusters do Kubernetes no Azure Local, versão 23H2