Cloud & IT Cert Prep · Lekcja

Sieci EKS: VPC CNI i równoważenie obciążenia

Używać wtyczki Amazon VPC CNI, aby pody otrzymywały natywne adresy IP VPC, oraz udostępniać usługi za pomocą AWS Load Balancer Controller.

Sieci EKS: VPC CNI i równoważenie obciążenia to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Podstawy sieci Kubernetes

Kubernetes wymaga, aby każdy pod miał unikalny, routowalny adres IP oraz aby pody mogły komunikować się ze sobą bez translacji NAT. Wtyczka Container Network Interface (CNI) odpowiada za przypisywanie adresów IP i konfigurowanie tras sieciowych na węzłach roboczych. Poszczególne platformy Kubernetes używają różnych implementacji CNI; AWS korzysta z wtyczki Amazon VPC CNI, aby bezpośrednio zintegrować sieć Kubernetes z warstwą VPC.

Wtyczka Amazon VPC CNI

Wtyczka Amazon VPC CNI przypisuje każdemu podowi adres IP bezpośrednio z zakresu CIDR podsieci VPC. Oznacza to, że pody są pełnoprawnymi zasobami VPC — można uzyskiwać do nich dostęp z innych zasobów VPC, systemów lokalnych za pośrednictwem VPN/Direct Connect oraz grup zabezpieczeń bez translacji w sieci nakładkowej. Każdy węzeł roboczy EC2 utrzymuje pulę dodatkowych prywatnych adresów IP (po jednym na każdy slot ENI), które są przypisywane podom podczas ich planowania.

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

Pula rozgrzewkowa ENI i adresów IP

Wtyczka VPC CNI utrzymuje na każdym węźle pulę wstępnie przydzielonych adresów IP w stanie gotowości, aby umożliwić szybkie planowanie podów. Po uruchomieniu węzła CNI dołącza wiele ENI i przypisuje dodatkowe adresy IP zgodnie ze zmiennymi środowiskowymi WARM_IP_TARGET lub MINIMUM_IP_TARGET. Maksymalna liczba podów, które może uruchomić węzeł, jest więc ograniczona przez liczbę ENI instancji pomnożoną przez liczbę adresów IP przypadających na ENI, która różni się w zależności od typu instancji.

# 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

Grupy zabezpieczeń dla podów

Domyślnie wszystkie pody na węźle współdzielą grupę zabezpieczeń tego węzła. Dzięki funkcji Security Groups for Pods można przypisywać indywidualne grupy zabezpieczeń określonym podom za pomocą zasobu niestandardowego SecurityGroupPolicy. Umożliwia to szczegółową kontrolę dostępu sieciowego — na przykład tylko pod bazy danych może odbierać ruch na porcie 5432 z grupy zabezpieczeń poda API. Ta funkcja wymaga wersji VPC CNI 1.7.7 lub nowszej oraz trunk ENI na węźle.

# 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

Typy usług Kubernetes w EKS

Kubernetesowe Services udostępniają zestaw podów pod stabilną nazwą DNS i adresem IP. W EKS istotne są trzy typy usług: ClusterIP (wyłącznie do komunikacji wewnątrz klastra), NodePort (otwiera port na każdym węźle — rzadko używany w EKS) oraz LoadBalancer (automatycznie aprowizuje moduł równoważenia obciążenia AWS). Typ LoadBalancer jest najczęściej wykorzystywany do udostępniania usług EKS dostępnych z Internetu.

# 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 to kontroler Kubernetes o otwartym kodzie źródłowym, który zarządza zasobami ALB i NLB w imieniu klastrów EKS. Po utworzeniu obiektu Kubernetes Ingress kontroler aprowizuje Application Load Balancer. Po utworzeniu elementu Service typu LoadBalancer z prawidłowymi adnotacjami aprowizuje Network Load Balancer. Kontroler zastępuje starszego dostawcę modułów równoważenia obciążenia Kubernetes wbudowanego w klaster.

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

Obiekt Kubernetes Ingress definiuje reguły routingu HTTP/HTTPS — oparte na ścieżce i hoście — do klastra. AWS Load Balancer Controller odczytuje obiekty Ingress z adnotacją kubernetes.io/ingress.class: alb i tworzy odpowiadający im Application Load Balancer z pasującymi regułami odbiornika. Eliminuje to konieczność ręcznego tworzenia ALB i grup docelowych dla każdej usługi aplikacji.

# 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 dla obciążeń TCP/UDP

Jeśli obciążenie wymaga protokołu TCP lub UDP (a nie HTTP), na przykład w przypadku serwera gry, usługi gRPC lub serwera proxy bazy danych, należy użyć NLB zamiast ALB. Usługę Kubernetes należy opatrzyć adnotacjami service.beta.kubernetes.io/aws-load-balancer-type: 'external' i service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. Kontroler aprowizuje NLB z adresami IP podów jako bezpośrednimi celami, omijając przekazywanie portów na poziomie węzła i zmniejszając opóźnienia.

# 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

Rozpoznawanie DNS w klastrze

EKS uruchamia CoreDNS jako dostawcę DNS klastra. Każda usługa otrzymuje nazwę DNS w formacie service-name.namespace.svc.cluster.local, która jest rozwiązywana na adres ClusterIP usługi. Pody również można odnajdywać za pomocą DNS. CoreDNS jest wdrażany jako Deployment (a nie DaemonSet), a liczbę jego replik należy dostosować do rozmiaru klastra. EKS zarządza CoreDNS jako dodatkiem, umożliwiając automatyczne aktualizacje wersji.

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

Zasady sieciowe w EKS

Obiekty Kubernetes NetworkPolicy definiują reguły zezwalające na ruch między podami i ruch z podów na zewnątrz. Domyślnie wszystkie pody w klastrze mogą swobodnie się komunikować. Aby wymusić sieć zero trust, można zainstalować kontroler zasad sieciowych Amazon VPC CNI (dostępny od wersji VPC CNI v1.14). Zasady sieciowe są oceniane na poziomie jądra systemu Linux za pomocą eBPF, co zapewnia wysoką wydajność egzekwowania reguł bez użycia sieci nakładkowej.

# 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

Wskazówki dotyczące rozwiązywania problemów z VPC CNI

Do typowych problemów z siecią EKS należą wyczerpanie adresów IP (można temu zaradzić, włączając delegowanie prefiksów lub dodając większe podsieci), pody pozostające w stanie Pending z powodu braku dostępnych dodatkowych adresów IP na węźle oraz sporadyczne błędy rozpoznawania DNS spowodowane niewystarczającą liczbą replik CoreDNS. Użyj kubectl describe pod, aby sprawdzić zdarzenia, kubectl describe node, aby wyświetlić liczbę przydzielonych adresów IP, oraz CloudWatch Container Insights, aby monitorować wskaźniki błędów DNS w całym klastrze.

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

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo: wtyczka Amazon VPC CNI przypisuje natywne adresy IP VPC każdemu podowi, zapewniając płynną integrację z VPC, AWS Load Balancer Controller aprowizuje ALB dla Ingress HTTP oraz NLB dla usług TCP/UDP, a Security Groups for Pods umożliwia kontrolę dostępu sieciowego na poziomie podów. Następnie omówimy IRSA, aby wiązać precyzyjnie określone role IAM z kontami usług Kubernetes.

Często zadawane pytania

Czy lekcja „Sieci EKS: VPC CNI i równoważenie obciążenia” jest bezpłatna?

Tak — pełny tekst „Sieci EKS: VPC CNI i równoważenie obciążenia” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Sieci EKS: VPC CNI i równoważenie obciążenia”?

Używać wtyczki Amazon VPC CNI, aby pody otrzymywały natywne adresy IP VPC, oraz udostępniać usługi za pomocą AWS Load Balancer Controller. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?

Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Sieci EKS: VPC CNI i równoważenie obciążenia”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?

Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Płaszczyzna sterowania EKS i węzły robocze
Profile Fargate dla bezserwerowych podów
Sieci EKS: VPC CNI i równoważenie obciążenia
Role IAM dla kont usług (IRSA)

← Powrót do Cloud & IT Cert Prep