0Pricing
AWS Solutions Architect · Lezione

Networking EKS: VPC CNI e bilanciamento del carico

Utilizzare il plugin Amazon VPC CNI affinché i pod ricevano indirizzi IP VPC nativi ed esporre i servizi con AWS Load Balancer Controller

Networking EKS: VPC CNI e bilanciamento del carico è una lezione AWS Solutions Architect gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento AWS Solutions Architect, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso AWS Solutions Architect include 4 lezioni in totale.

Concetti fondamentali del networking Kubernetes

Kubernetes richiede che ogni pod disponga di un indirizzo IP univoco e instradabile e che i pod possano comunicare tra loro senza NAT. Il plugin Container Network Interface (CNI) è responsabile dell'assegnazione degli IP e della configurazione delle route di rete sui nodi worker. Le diverse piattaforme Kubernetes utilizzano implementazioni CNI differenti; AWS utilizza il plugin Amazon VPC CNI per integrare direttamente il networking Kubernetes con il livello VPC.

Plugin Amazon VPC CNI

Il plugin Amazon VPC CNI assegna a ogni pod un indirizzo IP direttamente dall'intervallo CIDR della subnet VPC. I pod sono quindi cittadini di prima classe del VPC: possono essere raggiunti da altre risorse VPC, da sistemi on-premises tramite VPN/Direct Connect e dai gruppi di sicurezza, senza alcuna traduzione tramite rete overlay. Ogni nodo worker EC2 mantiene un pool di IP privati secondari (uno per slot ENI), assegnati ai pod durante la pianificazione.

# 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'

Pool warm di ENI e indirizzi IP

Il plugin VPC CNI mantiene su ogni nodo un pool warm di indirizzi IP preallocati per consentire una pianificazione rapida dei pod. Quando un nodo viene avviato, il CNI collega più ENI e assegna IP secondari fino ai valori specificati nelle variabili d'ambiente WARM_IP_TARGET o MINIMUM_IP_TARGET. Il numero massimo di pod che un nodo può eseguire è quindi limitato al numero di ENI dell'istanza moltiplicato per il numero di IP per ENI, che varia in base al tipo di istanza.

# 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

Security Groups for Pods

Per impostazione predefinita, tutti i pod su un nodo condividono il gruppo di sicurezza del nodo. Con la funzionalità Security Groups for Pods è possibile assegnare gruppi di sicurezza singoli a pod specifici utilizzando la risorsa personalizzata SecurityGroupPolicy. Ciò consente un controllo dettagliato degli accessi di rete: ad esempio, solo un pod del database può ricevere traffico sulla porta 5432 dal gruppo di sicurezza del pod API. Questa funzionalità richiede la versione 1.7.7 o successiva di VPC CNI e un ENI trunk sul nodo.

# 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

Tipi di Service Kubernetes su EKS

I Service Kubernetes espongono un insieme di pod tramite un nome DNS e un indirizzo IP stabili. In EKS, i tre tipi di service rilevanti sono: ClusterIP (solo per la comunicazione interna al cluster), NodePort (apre una porta su ogni nodo, usato raramente in EKS) e LoadBalancer (effettua automaticamente il provisioning di un load balancer AWS). Il tipo LoadBalancer è il metodo con cui viene esposta la maggior parte dei servizi EKS accessibili da Internet.

# 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

AWS Load Balancer Controller è un controller Kubernetes open source che gestisce le risorse ALB e NLB per conto dei cluster EKS. Quando si crea un oggetto Kubernetes Ingress, il controller effettua il provisioning di un Application Load Balancer. Quando si crea un Service di tipo LoadBalancer con le annotazioni corrette, effettua il provisioning di un Network Load Balancer. Il controller sostituisce il precedente provider di load balancer Kubernetes integrato nel codice.

# 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 Kubernetes con ALB

Un oggetto Kubernetes Ingress definisce regole di routing HTTP/HTTPS, basate sul percorso e sull'host, verso il cluster. AWS Load Balancer Controller legge gli oggetti Ingress con l'annotazione kubernetes.io/ingress.class: alb e crea un Application Load Balancer corrispondente, con regole del listener che applicano le corrispondenze. In questo modo non è necessario creare manualmente ALB e target group per ogni servizio applicativo.

# 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 per carichi di lavoro TCP/UDP

Quando il carico di lavoro richiede TCP o UDP (non HTTP), ad esempio per un server di gioco, un servizio gRPC o un proxy di database, utilizzi NLB invece di ALB. Aggiunga al Service Kubernetes le annotazioni service.beta.kubernetes.io/aws-load-balancer-type: 'external' e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. Il controller effettua il provisioning di un NLB con gli IP dei pod come target diretti, evitando il port forwarding a livello di nodo per ridurre la latenza.

# 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

Risoluzione DNS all'interno del cluster

EKS esegue CoreDNS come provider DNS del cluster. Ogni service riceve un nome DNS nel formato service-name.namespace.svc.cluster.local, che viene risolto nell'indirizzo ClusterIP del service. Anche i pod sono individuabili tramite DNS. CoreDNS viene distribuito come Deployment (non come DaemonSet) e il numero di repliche dovrebbe essere dimensionato in base alle dimensioni del cluster. EKS gestisce CoreDNS come add-on, consentendo aggiornamenti automatici della versione.

# 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)

Network policy in EKS

Gli oggetti Kubernetes NetworkPolicy definiscono regole di autorizzazione per il traffico tra pod e per il traffico dai pod verso l'esterno. Per impostazione predefinita, tutti i pod di un cluster possono comunicare liberamente. Per applicare un networking zero trust, è possibile installare il controller delle network policy Amazon VPC CNI (disponibile a partire da VPC CNI v1.14). Le network policy vengono valutate a livello del kernel Linux utilizzando eBPF, garantendo un'applicazione ad alte prestazioni senza una rete overlay.

# 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

Suggerimenti per la risoluzione dei problemi di VPC CNI

I problemi comuni di networking EKS includono l'esaurimento degli indirizzi IP (risolvibile abilitando la delega dei prefissi o aggiungendo subnet più grandi), i pod bloccati nello stato Pending perché il nodo non dispone di IP secondari disponibili e gli errori intermittenti nella risoluzione DNS causati da un numero insufficiente di repliche CoreDNS. Utilizzi kubectl describe pod per controllare gli eventi, kubectl describe node per visualizzare il numero di IP assegnati e CloudWatch Container Insights per monitorare la frequenza degli errori DNS su scala di 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 rapida

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

Riepilogo della lezione

In questa lezione ha imparato che: il plugin Amazon VPC CNI assegna IP VPC nativi a ogni pod per un'integrazione trasparente con il VPC, AWS Load Balancer Controller effettua il provisioning di ALB per gli Ingress HTTP e di NLB per i Service TCP/UDP, e Security Groups for Pods consente il controllo degli accessi di rete a livello di pod. Ora esamineremo IRSA per associare ruoli IAM dettagliati agli account di servizio Kubernetes.

Domande Frequenti

La lezione «Networking EKS: VPC CNI e bilanciamento del carico» è gratuita?

Sì — il testo completo di «Networking EKS: VPC CNI e bilanciamento del carico» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso AWS Solutions Architect, passa a CoddyKit PRO. Il corso AWS Solutions Architect include 4 lezioni in totale.

Cosa imparerò in «Networking EKS: VPC CNI e bilanciamento del carico»?

Utilizzare il plugin Amazon VPC CNI affinché i pod ricevano indirizzi IP VPC nativi ed esporre i servizi con AWS Load Balancer Controller Eserciti AWS Solutions Architect con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare AWS Solutions Architect?

Non è richiesta alcuna esperienza precedente. AWS Solutions Architect su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Networking EKS: VPC CNI e bilanciamento del carico»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione AWS Solutions Architect?

Sì. Ogni lezione AWS Solutions Architect include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Piano di controllo e nodi di lavoro EKS
  2. Profili Fargate per pod serverless
  3. Networking EKS: VPC CNI e bilanciamento del carico
  4. Ruoli IAM per gli account di servizio (IRSA)
← Torna a AWS Solutions Architect