0Pricing
Cloud & IT Cert Prep · Aula

Rede do EKS: VPC CNI e balanceamento de carga

Use o plugin Amazon VPC CNI para que os pods recebam endereços IP nativos da VPC e exponha serviços com o AWS Load Balancer Controller.

Rede do EKS: VPC CNI e balanceamento de carga é uma aula grátis de Cloud & IT Cert Prep no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Cloud & IT Cert Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.

Noções básicas de rede do Kubernetes

O Kubernetes exige que cada pod tenha um endereço IP exclusivo e roteável e que os pods se comuniquem entre si sem NAT. O plug-in Container Network Interface (CNI) é responsável por atribuir IPs e configurar rotas de rede nos nós de trabalho. Diferentes plataformas Kubernetes usam diferentes implementações de CNI; a AWS usa o plug-in Amazon VPC CNI para integrar diretamente a rede do Kubernetes à camada da VPC.

Plug-in Amazon VPC CNI

O plug-in Amazon VPC CNI atribui a cada pod um endereço IP diretamente do intervalo CIDR da sub-rede da sua VPC. Isso faz dos pods cidadãos de primeira classe da VPC — eles podem ser acessados por outros recursos da VPC, sistemas locais por meio de VPN/Direct Connect e grupos de segurança, sem qualquer tradução por uma rede de sobreposição. Cada nó de trabalho do EC2 mantém um conjunto de IPs privados secundários (um por slot de ENI), que são atribuídos aos pods conforme eles são agendados.

# Check the VPC CNI version installed in your cluster
kubectl describe daemonset aws-node -n kube-system | grep Image

# View the secondary IPs assigned to a node
aws ec2 describe-network-interfaces \
  --filters 'Name=attachment.instance-id,Values=i-0abcdef1234567890' \
  --query 'NetworkInterfaces[].PrivateIpAddresses[].PrivateIpAddress'

ENI e conjunto de IPs em espera

O plug-in VPC CNI mantém em cada nó um conjunto de endereços IP pré-alocados em espera para permitir o agendamento rápido de pods. Quando um nó é iniciado, o CNI associa várias ENIs e atribui IPs secundários até os limites definidos pelas variáveis de ambiente WARM_IP_TARGET ou MINIMUM_IP_TARGET. Portanto, a quantidade máxima de pods que um nó pode executar é limitada pela quantidade de ENIs da instância multiplicada pelos IPs por ENI, o que varia conforme o tipo de instância.

# Check maximum pods supported by an instance type
aws ec2 describe-instance-types \
  --instance-types m5.large \
  --query 'InstanceTypes[].NetworkInfo.{MaxENIs:MaximumNetworkInterfaces,IPv4sPerENI:Ipv4AddressesPerInterface}'

# Max pods formula: (MaxENIs x (IPv4sPerENI - 1)) + 2
# m5.large: 3 ENIs x (10-1) + 2 = 29 pods

Grupos de segurança para pods

Por padrão, todos os pods de um nó compartilham o grupo de segurança do nó. Com o recurso Security Groups for Pods, você pode atribuir grupos de segurança individuais a pods específicos usando o recurso personalizado SecurityGroupPolicy. Isso permite um controle detalhado do acesso à rede — por exemplo, somente um pod de banco de dados pode receber tráfego na porta 5432 do grupo de segurança do pod da API. Esse recurso exige a versão 1.7.7 ou posterior do VPC CNI e uma ENI de tronco no nó.

# Define a SecurityGroupPolicy (custom resource)
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: db-pod-sg-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: database
  securityGroups:
    groupIds:
    - sg-0db1234567890abcd

Tipos de Service do Kubernetes no EKS

Os Services do Kubernetes expõem um conjunto de pods usando um nome DNS e um IP estáveis. No EKS, os três tipos de serviço relevantes são: ClusterIP (somente para comunicação interna do cluster), NodePort (abre uma porta em cada nó — raramente usado no EKS) e LoadBalancer (provisiona automaticamente um balanceador de carga da AWS). O tipo LoadBalancer é a forma como a maioria dos serviços do EKS voltados para a Internet é exposta.

# Expose a deployment with a LoadBalancer service
kubectl expose deployment my-api \
  --type=LoadBalancer \
  --name=my-api-svc \
  --port=80 \
  --target-port=8080

# Check the assigned AWS load balancer hostname
kubectl get svc my-api-svc -o wide

AWS Load Balancer Controller

O AWS Load Balancer Controller é um controller de código aberto do Kubernetes que gerencia recursos ALB e NLB em nome dos clusters do EKS. Quando você cria um objeto Kubernetes Ingress, o controller provisiona um Application Load Balancer. Quando você cria um Service do tipo LoadBalancer com as anotações corretas, ele provisiona um Network Load Balancer. O controller substitui o provedor de balanceamento de carga integrado anteriormente ao Kubernetes.

# Install AWS Load Balancer Controller with Helm
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=my-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=us-east-1 \
  --set vpcId=vpc-0abc1234def567890

Ingress do Kubernetes com ALB

Um objeto Ingress do Kubernetes define regras de roteamento HTTP/HTTPS — baseadas em caminho e em host — para dentro do cluster. O AWS Load Balancer Controller lê objetos Ingress anotados com kubernetes.io/ingress.class: alb e cria um Application Load Balancer correspondente, com regras de listener que correspondem a essas definições. Isso elimina a necessidade de criar manualmente ALBs e grupos de destino para cada serviço de aplicação.

# Ingress YAML that creates an ALB
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

NLB para cargas de trabalho TCP/UDP

Quando sua carga de trabalho exige TCP ou UDP (e não HTTP) — como um servidor de jogos, um serviço gRPC ou um proxy de banco de dados — use o NLB em vez do ALB. Anote o Service do Kubernetes com service.beta.kubernetes.io/aws-load-balancer-type: 'external' e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. O controller provisiona um NLB com os IPs dos pods como destinos diretos, ignorando o encaminhamento de portas no nível do nó para obter menor latência.

# Service YAML that creates an NLB with IP targets
apiVersion: v1
kind: Service
metadata:
  name: grpc-svc
  namespace: production
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: 'external'
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  selector:
    app: grpc-server
  ports:
  - port: 50051
    targetPort: 50051
    protocol: TCP

Resolução de DNS dentro do cluster

O EKS executa o CoreDNS como provedor de DNS do cluster. Cada serviço recebe um nome DNS no formato service-name.namespace.svc.cluster.local, que é resolvido para o ClusterIP do serviço. Os pods também podem ser descobertos por DNS. O CoreDNS é implantado como uma implantação (não como um DaemonSet), e suas réplicas devem ser dimensionadas de acordo com o tamanho do cluster. O EKS gerencia o CoreDNS como um complemento, permitindo atualizações automatizadas de versão.

# Verify DNS resolution from within a pod
kubectl run dns-test --image=busybox --rm -it --restart=Never -- \
  nslookup kubernetes.default.svc.cluster.local

# Expected output: Name: kubernetes.default.svc.cluster.local
# Address: 10.100.0.1 (ClusterIP of the kubernetes service)

Políticas de rede no EKS

Os objetos NetworkPolicy do Kubernetes definem regras de permissão para tráfego entre pods e entre pods e recursos externos. Por padrão, todos os pods de um cluster podem se comunicar livremente. Para aplicar uma rede de confiança zero, você pode instalar o controller de políticas de rede do Amazon VPC CNI (disponível desde o VPC CNI v1.14). As políticas de rede são avaliadas no nível do kernel Linux usando eBPF, proporcionando aplicação de alto desempenho sem uma rede de sobreposição.

# NetworkPolicy: allow traffic to api pods only from frontend pods
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Dicas para solucionar problemas do VPC CNI

Problemas comuns de rede no EKS incluem esgotamento de endereços IP (corrija ativando a delegação de prefixos ou adicionando sub-redes maiores), pods presos no estado Pending porque o nó não tem IPs secundários disponíveis e falhas intermitentes na resolução de DNS causadas por um número insuficiente de réplicas do CoreDNS. Use kubectl describe pod para verificar eventos, kubectl describe node para consultar as quantidades de IPs alocados e o CloudWatch Container Insights para monitorar as taxas de erros de DNS em escala de cluster.

# Enable prefix delegation to increase pod density per node
kubectl set env daemonset aws-node \
  -n kube-system \
  ENABLE_PREFIX_DELEGATION=true \
  WARM_PREFIX_TARGET=1

# Check current IP usage on a node
kubectl describe node ip-10-0-1-100.ec2.internal | grep -A5 'Allocatable'

Verificação rápida

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) desta lição.

Recapitulação da lição

Nesta lição, você aprendeu que: o plug-in Amazon VPC CNI atribui IPs nativos da VPC a cada pod para uma integração perfeita com a VPC; o AWS Load Balancer Controller provisiona ALBs para Ingress HTTP e NLBs para Services TCP/UDP; e os Security Groups for Pods permitem controlar o acesso à rede no nível dos pods. A seguir, exploraremos o IRSA para associar funções do IAM com permissões detalhadas a contas de serviço do Kubernetes.

Perguntas Frequentes

A aula “Rede do EKS: VPC CNI e balanceamento de carga” é grátis?

Sim — o texto completo de “Rede do EKS: VPC CNI e balanceamento de carga” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Cloud & IT Cert Prep, atualize para CoddyKit PRO. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.

O que vou aprender em “Rede do EKS: VPC CNI e balanceamento de carga”?

Use o plugin Amazon VPC CNI para que os pods recebam endereços IP nativos da VPC e exponha serviços com o AWS Load Balancer Controller. Você pratica Cloud & IT Cert Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Cloud & IT Cert Prep?

Nenhuma experiência prévia é necessária. Cloud & IT Cert Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.

Quanto tempo leva a aula “Rede do EKS: VPC CNI e balanceamento de carga”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Cloud & IT Cert Prep?

Sim. Cada aula de Cloud & IT Cert Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Plano de controle e nós de trabalho do EKS
  2. Perfis do Fargate para pods sem servidor
  3. Rede do EKS: VPC CNI e balanceamento de carga
  4. Funções do IAM para contas de serviço (IRSA)
← Voltar para Cloud & IT Cert Prep