Requisitos de planejamento de endereço IP
Aplica-se a: Azure Local, versão 23H2
O planejamento de endereços IP para AKS habilitado pelo Azure Arc envolve a criação de uma rede que ofereça suporte a aplicativos, pools de nós, redes pod, comunicação de serviço e acesso externo. Este artigo orienta você por algumas considerações importantes para um planejamento eficaz de endereços IP e o número mínimo de endereços IP necessários para implantar o AKS na produção. Consulte os conceitos e requisitos de rede 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 IP. | Reserve endereços IP através de pools de IP na rede lógica Arc VM. |
| IPs de atualização da versão do AKS Arc K8s | Como o AKS Arc executa atualizações contínuas, 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 através de pools de IP na rede lógica Arc VM. |
| IP do plano de controlo | Reserve um endereço IP para cada cluster Kubernetes em seu ambiente. Por exemplo, se você quiser criar 5 clusters no total, reserve 5 endereços IP, um para cada cluster Kubernetes. | Reserve endereços IP através de pools de IP na rede lógica Arc VM. |
| IPs do balanceador de carga | O número de endereços IP reservados depende do seu modelo de implantação de aplicativo. Como ponto de partida, você pode reservar um endereço IP para cada serviço Kubernetes. | Reserve endereços IP na mesma sub-rede que a rede lógica Arc VM, mas fora do pool de IP. |
Exemplo passo a passo para reserva de endereço IP para clusters e aplicativos Kubernetes
Jane é uma administradora de TI que está começando com o AKS habilitado pelo Azure Arc. Jane deseja implantar dois clusters Kubernetes: cluster A do Kubernetes e cluster B do Kubernetes no cluster Local do Azure. Jane também quer executar um aplicativo de votação em cima do cluster A. Este aplicativo tem três instâncias da interface do usuário front-end em execução nos dois clusters e uma instância do banco de dados back-end. Todos os clusters e serviços AKS são executados em uma única rede, com uma única sub-rede.
- O cluster A do Kubernetes tem 3 nós de 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 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ó AKS Arc no cluster A (um IP por VM do nó K8s).
- 4 endereços IP para as VMs do nó 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 AKS Arc).
- 2 endereços IP para o plano de controlo AKS Arc (um endereço IP por cluster AKS Arc)
- 3 endereços IP para o serviço Kubernetes (um endereço IP por instância da interface do usuário front-end, já que todos usam a mesma porta. O banco de dados 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 |
|---|---|---|
| AKS Arc VMs, atualização da versão do K8s e IP do plano de controle | Reserve 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 3ª parte. Certifique-se de que esse IP esteja na mesma sub-rede que a rede lógica Arc, mas fora do pool de IP definido na rede lógica Arc VM. |
Exemplo de comandos CLI para reserva de endereço IP para clusters e aplicativos 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âmetros 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 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 IP de 3 endereços IP, na mesma sub-rede que a rede lógica Arc VM. Você pode adicionar mais pools de IP posteriormente se seu aplicativo precisar de um aumento. Para obter 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 sobre LNETs para clusters AKS e VMs Arc
As redes lógicas no Azure Local são usadas por clusters AKS e VMs Arc. Você pode configurar redes lógicas de uma das 2 maneiras a seguir:
- Compartilhe uma rede lógica entre VMs AKS e Arc.
- Defina redes lógicas separadas para clusters AKS e VMs Arc.
Compartilhar uma rede lógica entre VMs AKS e 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 introduz desafios potenciais, como contenção de recursos, riscos de segurança e complexidade na solução de problemas.
| Critérios | Partilhar uma rede lógica | Definição de 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 AKS. |
| Escalabilidade | Possíveis limitações de escalabilidade, pois tanto as VMs Arc quanto os clusters AKS compartilham recursos de rede. | Mais escalável, uma vez que os recursos de rede são separados e podem ser dimensionados de forma independente. |
| Gestão de políticas de rede | Mais fácil de gerenciar com um conjunto de diretivas de rede, mas mais difícil de isolar cargas de trabalho. | É mais fácil 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 devidamente segmentadas. | Melhor segurança, pois cada rede pode ser segmentada e isolada de forma mais rigorosa. |
| Impacto das falhas de rede | Uma falha na rede compartilhada pode afetar as VMs AKS e 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 pod CIDR 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 dentro de um cluster. Esses intervalos de endereços IP são definidos durante o processo de criação do cluster AKS e são usados para atribuir endereços IP exclusivos a pods e serviços dentro do cluster.
Rede Pod CIDR
Pod network CIDR é um intervalo de endereços IP usados pelo Kubernetes para atribuir endereços IP exclusivos aos pods individuais em execução dentro de um cluster Kubernetes. Cada pod recebe seu próprio endereço IP dentro desse intervalo, permitindo que os pods se comuniquem entre si e com serviços dentro do cluster. No AKS, os endereços IP do pod são atribuídos via Calico CNI no modo VXLAN. Calico VXLAN ajuda a criar redes Overlay, onde os endereços IP de pods (da rede pod CIDR) são virtualizados e encapsulados através da rede física. Nesse modo, cada pod recebe um endereço IP do CIDR da rede pod, mas esse endereço IP não é diretamente roteável na rede física. Em vez disso, ele é encapsulado dentro dos pacotes de rede e enviado através da 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 pod. O AKS suporta personalizações para a rede pod CIDR. Você pode definir seu próprio valor usando o --pod-cidr parâmetro ao criar o cluster AKS. Certifique-se de que o intervalo de IP CIDR seja grande o suficiente para acomodar o número máximo de pods por nó e em todo o cluster do Kubernetes.
Rede de serviços CIDR
O CIDR da rede de serviço é o intervalo de endereços IP reservados para serviços Kubernetes como LoadBalancers, ClusterIP e NodePort dentro de um cluster. O Kubernetes suporta 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 a partir do CIDR da rede de serviço só é acessível dentro do cluster 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 é através 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. Atualmente, o AKS não suporta personalizações para o CIDR da rede de serviços.
Próximos passos
Criar redes lógicas para clusters Kubernetes no Azure Local, versão 23H2