0Pricing
AWS Solutions Architect · Leçon

Réseau EKS : CNI VPC et équilibrage de charge

Utilisez le plugin Amazon VPC CNI afin que les pods obtiennent des adresses IP VPC natives, puis exposez les services avec le contrôleur AWS Load Balancer.

Réseau EKS : CNI VPC et équilibrage de charge est une leçon AWS Solutions Architect gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AWS Solutions Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AWS Solutions Architect comprend 4 leçons au total.

Principes de base de la mise en réseau Kubernetes

Kubernetes exige que chaque pod possède une adresse IP unique et routable, et que les pods puissent communiquer entre eux sans NAT. Le module Container Network Interface (CNI) est chargé d'attribuer les IP et de configurer les routes réseau sur les nœuds de travail. Les différentes plateformes Kubernetes utilisent des implémentations CNI différentes ; AWS utilise le module Amazon VPC CNI pour intégrer directement la mise en réseau Kubernetes à la couche VPC.

Module Amazon VPC CNI

Le module Amazon VPC CNI attribue à chaque pod une adresse IP provenant directement de la plage CIDR du sous-réseau de votre VPC. Les pods sont ainsi des citoyens de première classe du VPC : ils sont accessibles par les autres ressources VPC, les systèmes sur site via VPN/Direct Connect et les groupes de sécurité, sans traduction par un réseau superposé. Chaque nœud de travail EC2 gère un pool d'IP privées secondaires (une par emplacement ENI), attribuées aux pods lors de leur planification.

# 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 d'adresses IP ENI en réserve

Le module VPC CNI gère sur chaque nœud un pool d'adresses IP préallouées en réserve afin d'accélérer la planification des pods. Lorsqu'un nœud démarre, le CNI lui associe plusieurs ENIs et attribue des IP secondaires jusqu'à atteindre la valeur des variables d'environnement WARM_IP_TARGET ou MINIMUM_IP_TARGET. Le nombre maximal de pods qu'un nœud peut exécuter est donc limité par le nombre d'ENIs de l'instance multiplié par le nombre d'IP par ENI, qui varie selon le type d'instance.

# 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

Groupes de sécurité pour les pods

Par défaut, tous les pods d'un nœud partagent le groupe de sécurité du nœud. Avec la fonctionnalité Security Groups for Pods, vous pouvez attribuer des groupes de sécurité individuels à certains pods à l'aide de la ressource personnalisée SecurityGroupPolicy. Cela permet un contrôle précis des accès réseau — par exemple, seul un pod de base de données peut recevoir du trafic sur le port 5432 depuis le groupe de sécurité du pod d'API. Cette fonctionnalité nécessite la version 1.7.7 ou ultérieure du VPC CNI ainsi qu'un ENI trunk sur le nœud.

# 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

Types de services Kubernetes sur EKS

Les services Kubernetes exposent un ensemble de pods sous un nom DNS et une IP stables. Sur EKS, les trois types de services pertinents sont : ClusterIP (communication interne au cluster uniquement), NodePort (ouvre un port sur chaque nœud — rarement utilisé sur EKS) et LoadBalancer (provisionne automatiquement un équilibreur de charge AWS). Le type LoadBalancer est celui qui permet d'exposer la plupart des services EKS accessibles depuis 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

Le AWS Load Balancer Controller est un contrôleur Kubernetes open source qui gère les ressources ALB et NLB pour le compte des clusters EKS. Lorsque vous créez un objet Kubernetes Ingress, le contrôleur provisionne un Application Load Balancer. Lorsque vous créez un Service de type LoadBalancer avec les annotations appropriées, il provisionne un Network Load Balancer. Le contrôleur remplace l'ancien fournisseur d'équilibrage de charge Kubernetes intégré.

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

Un objet Kubernetes Ingress définit des règles de routage HTTP/HTTPS — fondées sur le chemin et sur l'hôte — vers votre cluster. Le AWS Load Balancer Controller lit les objets Ingress annotés avec kubernetes.io/ingress.class: alb et crée un Application Load Balancer correspondant, avec des règles d'écoute adaptées. Cela évite de devoir créer manuellement des ALB et des groupes cibles pour chaque service applicatif.

# 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 pour les charges TCP/UDP

Lorsque votre charge de travail nécessite TCP ou UDP (et non HTTP), par exemple pour un serveur de jeu, un service gRPC ou un proxy de base de données, utilisez le NLB plutôt que l'ALB. Annotez le Service Kubernetes avec service.beta.kubernetes.io/aws-load-balancer-type: 'external' et service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'. Le contrôleur provisionne un NLB dont les adresses IP des pods sont les cibles directes, ce qui évite la redirection des ports au niveau des nœuds et réduit la latence.

# 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

Résolution DNS au sein du cluster

EKS utilise CoreDNS comme fournisseur DNS du cluster. Chaque service reçoit un nom DNS au format service-name.namespace.svc.cluster.local, qui se résout vers le ClusterIP du service. Les pods sont également accessibles via DNS. CoreDNS est déployé comme un Deployment (et non comme un DaemonSet), et le nombre de ses réplicas doit être adapté à la taille du cluster. EKS gère CoreDNS comme un module complémentaire, ce qui permet des mises à niveau automatisées.

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

Politiques réseau dans EKS

Les objets Kubernetes NetworkPolicy définissent des règles d'autorisation pour le trafic de pod à pod et de pod vers l'extérieur. Par défaut, tous les pods d'un cluster peuvent communiquer librement. Pour appliquer une mise en réseau zero trust, vous pouvez installer le contrôleur de politiques réseau Amazon VPC CNI (disponible depuis la version 1.14 du VPC CNI). Les politiques réseau sont évaluées au niveau du noyau Linux à l'aide d'eBPF, ce qui assure une application performante sans réseau superposé.

# 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

Conseils de dépannage du VPC CNI

Les problèmes courants de mise en réseau EKS comprennent l'épuisement des adresses IP (corrigez-le en activant la délégation de préfixes ou en ajoutant des sous-réseaux plus grands), les pods bloqués à l'état Pending parce que le nœud ne dispose plus d'IP secondaires disponibles, et les échecs intermittents de résolution DNS dus à un nombre insuffisant de réplicas CoreDNS. Utilisez kubectl describe pod pour vérifier les événements, kubectl describe node pour consulter le nombre d'IP allouées, et CloudWatch Container Insights pour surveiller le taux d'erreurs DNS à l'échelle du 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'

Vérification rapide

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que : le module Amazon VPC CNI attribue des IP VPC natives à chaque pod pour une intégration fluide au VPC, que le AWS Load Balancer Controller provisionne des ALB pour les Ingress HTTP et des NLB pour les Services TCP/UDP, et que Security Groups for Pods permet un contrôle des accès réseau au niveau des pods. Nous allons maintenant découvrir IRSA pour associer des rôles IAM précis aux comptes de service Kubernetes.

Questions Fréquemment Posées

La leçon « Réseau EKS : CNI VPC et équilibrage de charge » est-elle gratuite ?

Oui — le texte complet de « Réseau EKS : CNI VPC et équilibrage de charge » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AWS Solutions Architect, passe à CoddyKit PRO. Le cours AWS Solutions Architect comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Réseau EKS : CNI VPC et équilibrage de charge » ?

Utilisez le plugin Amazon VPC CNI afin que les pods obtiennent des adresses IP VPC natives, puis exposez les services avec le contrôleur AWS Load Balancer. Tu pratiques AWS Solutions Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer AWS Solutions Architect ?

Aucune expérience préalable n'est requise. AWS Solutions Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Réseau EKS : CNI VPC et équilibrage de charge » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon AWS Solutions Architect ?

Oui. Chaque leçon AWS Solutions Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Plan de contrôle et nœuds de travail EKS
  2. Profils Fargate pour les pods sans serveur
  3. Réseau EKS : CNI VPC et équilibrage de charge
  4. Rôles IAM pour les comptes de service (IRSA)
← Retour à AWS Solutions Architect