0Pricing
Cloud & IT Cert Prep · Lektion

EKS-Netzwerk: VPC CNI und Load Balancing

Verwenden Sie das Amazon-VPC-CNI-Plugin, damit Pods native VPC-IP-Adressen erhalten, und machen Sie Services mit dem AWS Load Balancer Controller zugänglich.

EKS-Netzwerk: VPC CNI und Load Balancing ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Grundlagen der Kubernetes-Netzwerkfunktionen

Kubernetes erfordert, dass jeder Pod eine eindeutige, routbare IP-Adresse besitzt und Pods ohne NAT miteinander kommunizieren können. Das Container Network Interface (CNI)-Plugin ist dafür zuständig, IP-Adressen zuzuweisen und Netzwerkrouten auf Worker-Nodes zu konfigurieren. Verschiedene Kubernetes-Plattformen verwenden unterschiedliche CNI-Implementierungen; AWS nutzt das Amazon VPC CNI-Plugin, um die Kubernetes-Netzwerkfunktionen direkt in die VPC-Ebene zu integrieren.

Amazon VPC CNI-Plugin

Das Amazon VPC CNI-Plugin weist jedem Pod direkt aus dem CIDR-Bereich des VPC-Subnetzes eine IP-Adresse zu. Dadurch sind Pods vollwertige VPC-Teilnehmer — sie können von anderen VPC-Ressourcen, von lokalen Systemen über VPN/Direct Connect und über Security Groups erreicht werden, ohne Übersetzung durch ein Overlay-Netzwerk. Jeder EC2-Worker-Node verwaltet einen Pool sekundärer privater IP-Adressen (eine pro ENI-Steckplatz), die den Pods bei ihrer Einplanung zugewiesen werden.

# 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 und Warm-Pool für IP-Adressen

Das VPC-CNI-Plugin verwaltet auf jedem Node einen Warm-Pool vorab zugewiesener IP-Adressen, um eine schnelle Einplanung von Pods zu ermöglichen. Beim Start eines Nodes fügt das CNI mehrere ENIs hinzu und weist sekundäre IP-Adressen bis zum Wert der Umgebungsvariablen WARM_IP_TARGET oder MINIMUM_IP_TARGET zu. Die maximale Anzahl von Pods, die ein Node ausführen kann, wird daher durch die ENI-Anzahl der Instance multipliziert mit der Anzahl der IP-Adressen pro ENI begrenzt, die je nach Instance-Typ variiert.

# 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 für Pods

Standardmäßig verwenden alle Pods auf einem Node die Security Group des Nodes gemeinsam. Mit der Funktion Security Groups for Pods können Sie bestimmten Pods mithilfe der benutzerdefinierten Ressource SecurityGroupPolicy individuelle Security Groups zuweisen. Dies ermöglicht eine fein abgestimmte Netzwerkzugriffskontrolle — beispielsweise kann nur ein Datenbank-Pod Datenverkehr am Port 5432 aus der Security Group des API-Pods empfangen. Diese Funktion erfordert die VPC-CNI-Version 1.7.7 oder höher sowie eine Trunk-ENI auf dem Node.

# 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

Kubernetes-Service-Typen auf EKS

Kubernetes-Services stellen eine Gruppe von Pods unter einem stabilen DNS-Namen und einer stabilen IP-Adresse bereit. Auf EKS sind drei Service-Typen relevant: ClusterIP (nur für die interne Clusterkommunikation), NodePort (öffnet einen Port auf jedem Node — auf EKS selten verwendet) und LoadBalancer (stellt automatisch einen AWS Load Balancer bereit). Der Typ LoadBalancer ist die gängigste Methode, um internetseitig erreichbare EKS-Services bereitzustellen.

# 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

Der AWS Load Balancer Controller ist ein Open-Source-Kubernetes-Controller, der ALB- und NLB-Ressourcen im Auftrag von EKS-Clustern verwaltet. Wenn Sie ein Kubernetes-Ingress-Objekt erstellen, stellt der Controller einen Application Load Balancer bereit. Wenn Sie einen Service des Typs LoadBalancer mit den richtigen Annotationen erstellen, stellt er einen Network Load Balancer bereit. Der Controller ersetzt den älteren integrierten Kubernetes-Load-Balancer-Provider.

# 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

Kubernetes-Ingress mit ALB

Ein Kubernetes-Ingress-Objekt definiert HTTP-/HTTPS-Routing-Regeln — nach Pfad und Host — in Ihren Cluster. Der AWS Load Balancer Controller liest Ingress-Objekte mit der Annotation kubernetes.io/ingress.class: alb und erstellt einen entsprechenden Application Load Balancer mit passenden Listener-Regeln. Dadurch müssen Sie ALBs und Target Groups nicht mehr manuell für jeden Anwendungsservice erstellen.

# 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 für TCP-/UDP-Workloads

Wenn Ihr Workload TCP oder UDP (nicht HTTP) erfordert — beispielsweise ein Gameserver, ein gRPC-Service oder ein Datenbank-Proxy — verwenden Sie statt eines ALB einen NLB. Versehen Sie den Kubernetes-Service mit den Annotationen service.beta.kubernetes.io/aws-load-balancer-type: 'external' und service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. Der Controller stellt einen NLB bereit, der die IP-Adressen der Pods als direkte Ziele verwendet und die Portweiterleitung auf Node-Ebene umgeht, was eine geringere Latenz ermöglicht.

# 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

DNS-Auflösung innerhalb des Clusters

EKS führt CoreDNS als DNS-Provider des Clusters aus. Jeder Service erhält einen DNS-Namen im Format service-name.namespace.svc.cluster.local, der in die ClusterIP des Services aufgelöst wird. Auch Pods können über DNS gefunden werden. CoreDNS wird als Deployment (nicht als DaemonSet) bereitgestellt, und seine Replikatanzahl sollte anhand der Clustergröße skaliert werden. EKS verwaltet CoreDNS als Add-on und ermöglicht dadurch automatische Versionsupgrades.

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

Netzwerkrichtlinien in EKS

Kubernetes-NetworkPolicy-Objekte definieren Zulassungsregeln für Datenverkehr zwischen Pods und von Pods nach außen. Standardmäßig können alle Pods in einem Cluster frei miteinander kommunizieren. Für die Durchsetzung eines Zero-Trust-Netzwerks können Sie den Amazon VPC CNI Network Policy Controller installieren (verfügbar ab VPC CNI v1.14). Netzwerkrichtlinien werden auf Ebene des Linux-Kernels mithilfe von eBPF ausgewertet und ermöglichen so eine leistungsstarke Durchsetzung ohne Overlay-Netzwerk.

# 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

Tipps zur Fehlerbehebung beim VPC CNI

Zu den häufigen EKS-Netzwerkproblemen gehören erschöpfte IP-Adressen (beheben Sie dies durch Aktivieren der Präfixdelegierung oder Hinzufügen größerer Subnetze), Pods, die im Status Pending verbleiben, weil auf dem Node keine sekundären IP-Adressen verfügbar sind, sowie sporadische Fehler bei der DNS-Auflösung aufgrund einer unzureichenden Anzahl von CoreDNS-Replikaten. Verwenden Sie kubectl describe pod, um Ereignisse zu prüfen, kubectl describe node, um die Anzahl zugewiesener IP-Adressen anzuzeigen, und CloudWatch Container Insights, um DNS-Fehlerraten im gesamten Cluster zu überwachen.

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

Schnelltest

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

Lektionszusammenfassung

In dieser Lektion haben Sie gelernt: das Amazon VPC CNI-Plugin weist jedem Pod native VPC-IP-Adressen zu und ermöglicht so eine nahtlose VPC-Integration, der AWS Load Balancer Controller stellt ALBs für HTTP-Ingress und NLBs für TCP-/UDP-Services bereit, und Security Groups for Pods ermöglichen die Netzwerkzugriffskontrolle auf Pod-Ebene. Als Nächstes sehen wir uns IRSA an, um Kubernetes-Servicekonten differenziert IAM-Rollen zuzuweisen.

Häufig gestellte Fragen

Ist die Lektion „EKS-Netzwerk: VPC CNI und Load Balancing“ kostenlos?

Ja — der vollständige Text von „EKS-Netzwerk: VPC CNI und Load Balancing“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „EKS-Netzwerk: VPC CNI und Load Balancing“?

Verwenden Sie das Amazon-VPC-CNI-Plugin, damit Pods native VPC-IP-Adressen erhalten, und machen Sie Services mit dem AWS Load Balancer Controller zugänglich. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?

Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „EKS-Netzwerk: VPC CNI und Load Balancing“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?

Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. EKS-Control-Plane und Worker-Nodes
  2. Fargate-Profile für serverlose Pods
  3. EKS-Netzwerk: VPC CNI und Load Balancing
  4. IAM-Rollen für Servicekonten (IRSA)
← Zurück zu Cloud & IT Cert Prep