AWS Solutions Architect · Lektion

EKS-netværk: VPC CNI og belastningsfordeling

Brug Amazon VPC CNI-pluginet, så pods får oprindelige VPC-IP-adresser, og eksponér tjenester med AWS Load Balancer Controller

Lektion 3 af 413 trin

EKS-netværk: VPC CNI og belastningsfordeling er en gratis AWS Solutions Architect-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i AWS Solutions Architect, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Grundlæggende Kubernetes-netværk

Kubernetes kræver, at hver pod har en unik IP-adresse, der kan routes til, og at pods kan kommunikere med hinanden uden NAT. Container Network Interface (CNI)-pluginet er ansvarligt for at tildele IP-adresser og konfigurere netværksruter på worker-noder. Forskellige Kubernetes-platforme bruger forskellige CNI-implementeringer; AWS bruger Amazon VPC CNI-pluginet til at integrere Kubernetes-netværk direkte med VPC-laget.

Amazon VPC CNI-plugin

Amazon VPC CNI-pluginet tildeler hver pod en IP-adresse direkte fra CIDR-området for dit VPC-subnet. Det betyder, at pods er førsteklasses VPC-deltagere — de kan tilgås af andre VPC-ressourcer, lokale systemer via VPN/Direct Connect og sikkerhedsgrupper uden oversættelse via et overlay-netværk. Hver EC2-worker-node vedligeholder en pulje af sekundære private IP-adresser (én pr. ENI-plads), som tildeles pods, når de planlægges.

# 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 og varm IP-adressepulje

VPC CNI-pluginet vedligeholder en varm pulje af forhåndstildelte IP-adresser på hver node for at muliggøre hurtig planlægning af pods. Når en node starter, tilknytter CNI flere ENI'er og tildeler sekundære IP-adresser op til miljøvariablen WARM_IP_TARGET eller MINIMUM_IP_TARGET. Det maksimale antal pods, en node kan køre, er derfor begrænset af instansens antal ENI'er ganget med antallet af IP-adresser pr. ENI, hvilket varierer efter instanstype.

# 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

Sikkerhedsgrupper til pods

Som standard deler alle pods på en node nodens sikkerhedsgruppe. Med funktionen Security Groups for Pods kan du tildele individuelle sikkerhedsgrupper til bestemte pods ved hjælp af den brugerdefinerede ressource SecurityGroupPolicy. Det giver detaljeret kontrol over netværksadgang — for eksempel kan kun en databasepod modtage trafik på port 5432 fra API-poddens sikkerhedsgruppe. Funktionen kræver VPC CNI version 1.7.7 eller nyere samt en trunk-ENI på noden.

# 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-tjenestetyper på EKS

Kubernetes-tjenester eksponerer et sæt pods under et stabilt DNS-navn og en stabil IP-adresse. På EKS er de tre relevante tjenestetyper: ClusterIP (kun intern kommunikation i klyngen), NodePort (åbner en port på hver node — bruges sjældent på EKS) og LoadBalancer (klargør automatisk en AWS-loadbalancer). Typen LoadBalancer er den måde, de fleste internetvendte EKS-tjenester eksponeres på.

# 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 er en open source-Kubernetes-controller, der administrerer ALB- og NLB-ressourcer på vegne af EKS-klynger. Når du opretter et Kubernetes-Ingress-objekt, klargør controlleren en Application Load Balancer. Når du opretter en Service af typen LoadBalancer med de korrekte annoteringer, klargør den en Network Load Balancer. Controlleren erstatter den ældre indbyggede Kubernetes-loadbalancerudbyder.

# 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 med ALB

Et Kubernetes-Ingress-objekt definerer HTTP/HTTPS-routingregler — sti- og værtsbaserede — ind i din klynge. AWS Load Balancer Controller læser Ingress-objekter med annoteringen kubernetes.io/ingress.class: alb og opretter en tilsvarende Application Load Balancer med matchende lytterregler. Det fjerner behovet for manuelt at oprette ALB'er og targetgrupper til hver applikationstjeneste.

# 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 til TCP-/UDP-arbejdsbelastninger

Når din arbejdsbelastning kræver TCP eller UDP (ikke HTTP) — for eksempel en spilserver, en gRPC-tjeneste eller en databaseproxy — skal du bruge NLB i stedet for ALB. Annotér Kubernetes-tjenesten med service.beta.kubernetes.io/aws-load-balancer-type: 'external' og service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. Controlleren klargør en NLB med poddets IP-adresser som direkte mål, så videresendelse via porte på noden undgås, hvilket giver lavere latenstid.

# 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-opløsning i klyngen

EKS kører CoreDNS som DNS-udbyder for klyngen. Hver tjeneste får et DNS-navn i formatet service-name.namespace.svc.cluster.local, som opløses til tjenestens ClusterIP. Pods kan også findes via DNS. CoreDNS er installeret som en Deployment (ikke et DaemonSet), og antallet af replikaer bør skaleres efter klyngens størrelse. EKS administrerer CoreDNS som en add-on, hvilket muliggør automatiske versionsopgraderinger.

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

Netværkspolitikker i EKS

Kubernetes-objekter af typen NetworkPolicy definerer tilladelsesregler for trafik mellem pods og fra pods til eksterne mål. Som standard kan alle pods i en klynge kommunikere frit. Hvis du vil håndhæve netværk efter en zero-trust-model, kan du installere Amazon VPC CNI network policy controller (tilgængelig siden VPC CNI v1.14). Netværkspolitikker evalueres på Linux-kerneniveau ved hjælp af eBPF, hvilket giver effektiv håndhævelse uden et overlay-netværk.

# 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

Tips til fejlfinding af VPC CNI

Almindelige EKS-netværksproblemer omfatter udtømning af IP-adresser (løses ved at aktivere præfiksdelegering eller tilføje større subnet), pods, der sidder fast i tilstanden Pending, fordi noden ikke har ledige sekundære IP-adresser, samt periodiske fejl ved DNS-opløsning på grund af for få CoreDNS-replikaer. Brug kubectl describe pod til at kontrollere hændelser, kubectl describe node til at se antallet af tildelte IP-adresser og CloudWatch Container Insights til at overvåge DNS-fejlprocenter på klyngeniveau.

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

Hurtigt tjek

Test din forståelse af AWS Solutions Architect-koncepterne (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion lærte du, at Amazon VPC CNI-pluginet tildeler native VPC-IP-adresser til hver pod, så VPC-integrationen bliver problemfri, at AWS Load Balancer Controller klargør ALB'er til HTTP Ingress og NLB'er til TCP-/UDP-tjenester, og at Security Groups for Pods muliggør netværksadgangskontrol på podniveau. Næste emne er IRSA, hvor du knytter detaljeret afgrænsede IAM-roller til Kubernetes-servicekonti.

Gratis at komme i gang

Lær AWS Solutions Architect med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “EKS-netværk: VPC CNI og belastningsfordeling” gratis?

Ja — alle 3 lektioner i læringssporet AWS Solutions Architect, inklusive “EKS-netværk: VPC CNI og belastningsfordeling”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “EKS-netværk: VPC CNI og belastningsfordeling”?

Brug Amazon VPC CNI-pluginet, så pods får oprindelige VPC-IP-adresser, og eksponér tjenester med AWS Load Balancer Controller Du øver dig i AWS Solutions Architect med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på AWS Solutions Architect?

Der kræves ingen tidligere erfaring. AWS Solutions Architect på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.

Hvor lang tid tager lektionen “EKS-netværk: VPC CNI og belastningsfordeling”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne AWS Solutions Architect-lektion?

Ja. Alle AWS Solutions Architect-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

EKS-kontrolplan og workernoder
Fargate-profiler til serverløse pods
EKS-netværk: VPC CNI og belastningsfordeling
IAM-roller til servicekonti (IRSA)

← Tilbage til AWS Solutions Architect