0Pricing
AWS Solutions Architect · Leçon

Profils Fargate pour les pods sans serveur

Exécutez des pods Kubernetes sur Fargate sans gérer de nœuds EC2, configurez des profils Fargate et comprenez leurs restrictions d’espace de noms.

Profils Fargate pour les pods sans serveur est une leçon AWS Solutions Architect gratuite sur CoddyKit. Ceci est la leçon 2 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.

Que sont les profils Fargate ?

AWS Fargate pour EKS vous permet d'exécuter des pods Kubernetes sans provisionner ni gérer de nœuds EC2. Au lieu de réfléchir aux types d'instances et aux groupes de nœuds, vous définissez un profil Fargate qui indique à EKS quels pods doivent s'exécuter sur Fargate en fonction de leur espace de noms et de sélecteurs d'étiquettes facultatifs. AWS provisionne automatiquement la quantité de ressources de calcul adaptée à chaque pod et la libère lorsque le pod s'arrête.

Configuration d'un profil Fargate

Un profil Fargate est associé à un cluster EKS et contient un ou plusieurs sélecteurs ; chaque sélecteur spécifie un espace de noms et d'éventuelles paires clé-valeur d'étiquettes Kubernetes. Un pod doit correspondre à au moins un sélecteur pour être planifié sur Fargate. Le profil spécifie également le rôle d'exécution du pod (un rôle IAM) ainsi que les sous-réseaux privés que Fargate doit utiliser pour lancer les pods.

# Create a Fargate profile for the 'production' namespace
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name production-profile \
  --pod-execution-role-arn arn:aws:iam::111122223333:role/EKSFargatePodExecutionRole \
  --subnets subnet-aaa subnet-bbb \
  --selectors '[{"namespace":"production"},{"namespace":"staging","labels":{"fargate":"true"}}]'

Rôle d'exécution du pod

Le rôle d'exécution du pod est un rôle IAM qu'EKS assume lorsque Fargate récupère les images de conteneurs et envoie les journaux des pods à CloudWatch. Il doit inclure la politique gérée par AWS AmazonEKSFargatePodExecutionRolePolicy. Sans ce rôle, les pods planifiés sur Fargate ne pourront pas démarrer, car Fargate ne pourra pas s'authentifier auprès d'ECR ni écrire dans CloudWatch Logs.

# Create the pod execution role trust policy
cat fargate-trust-policy.json
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {"Service": "eks-fargate-pods.amazonaws.com"},
#     "Action": "sts:AssumeRole"
#   }]
# }

aws iam attach-role-policy \
  --role-name EKSFargatePodExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy

Restrictions des espaces de noms sur Fargate

Fargate impose d'importantes restrictions sur les espaces de noms. L'espace de noms kube-system est interdit à la plupart des profils Fargate, car des pods système tels que kube-proxy y sont exécutés. CoreDNS fait exception : AWS fournit un processus guidé pour appliquer un correctif au déploiement CoreDNS et supprimer l'annotation eks.amazonaws.com/compute-type: ec2 afin qu'il puisse s'exécuter sur Fargate. Les pods des espaces de noms exclus resteront non planifiés si aucun nœud EC2 n'est disponible.

# Patch CoreDNS to allow Fargate scheduling
kubectl patch deployment coredns \
  -n kube-system \
  --type json \
  -p '[{"op":"remove","path":"/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

# Restart CoreDNS to apply the patch
kubectl rollout restart deployment coredns -n kube-system

Dimensionnement des ressources des pods Fargate

Fargate alloue les ressources de calcul en fonction des demandes de CPU et de mémoire définies dans la spécification du pod. Il arrondit à la combinaison vCPU/mémoire Fargate prise en charge la plus proche (par exemple, de 0,25 vCPU / 0,5 GB à 16 vCPU / 120 GB). Vous ne payez que les ressources allouées par seconde pendant l'exécution du pod. Définissez toujours des demandes de ressources précises : une demande insuffisante entraîne des arrêts pour manque de mémoire, tandis qu'une demande excessive augmente les coûts.

# Pod spec with explicit resource requests and limits
apiVersion: v1
kind: Pod
metadata:
  name: api-pod
  namespace: production
spec:
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-api:latest
    resources:
      requests:
        cpu: '500m'
        memory: '1Gi'
      limits:
        cpu: '1'
        memory: '2Gi'

Groupes de nœuds Fargate et EC2 : compromis

Fargate élimine la gestion des nœuds, mais présente certaines contraintes : aucun DaemonSet (puisqu'il n'existe pas de nœuds persistants sur lesquels les planifier), aucun conteneur privilégié et une prise en charge limitée de certains types de stockage. Les groupes de nœuds EC2 prennent en charge les GPU, les noyaux personnalisés et les charges de travail avec état utilisant des disques NVMe locaux. Un schéma courant consiste à exécuter les services sans état sur Fargate et les charges de travail avec état ou utilisant des GPU sur des groupes de nœuds EC2 dédiés au sein du même cluster EKS.

Mise en réseau de Fargate et groupes de sécurité

Chaque pod Fargate obtient sa propre interface réseau élastique (ENI) ainsi qu'une adresse IP privée provenant du sous-réseau spécifié dans le profil. Vous pouvez ainsi appliquer un groupe de sécurité unique à chaque pod grâce à la fonctionnalité Security Groups for Pods. Les pods Fargate prennent en charge toutes les règles standard des groupes de sécurité VPC, ce qui permet de contrôler finement le trafic entrant et sortant au niveau de chaque pod — un avantage majeur en matière de sécurité par rapport aux groupes de sécurité partagés au niveau des nœuds.

# Assign a security group to a pod via annotation
apiVersion: v1
kind: Pod
metadata:
  name: secure-api
  namespace: production
  annotations:
    vpc.amazonaws.com/pod-eni: 'true'
spec:
  securityGroups:
    groupIds:
    - sg-0abc1234def56789a
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/secure-api:v2

Journalisation Fargate vers CloudWatch

Les pods Fargate envoient leurs journaux vers Amazon CloudWatch Logs à l'aide du routeur de journaux Fluent Bit intégré. Vous configurez la journalisation en créant un ConfigMap nommé aws-logging dans l'espace de noms aws-observability. Le rôle d'exécution du pod doit être autorisé à créer des groupes de journaux et à écrire des événements de journal. Les journaux sont organisés dans des groupes de journaux CloudWatch par cluster et par espace de noms, ce qui facilite leur agrégation centralisée sans exécuter d'agent de journalisation distinct.

# ConfigMap to enable Fargate logging
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-logging
  namespace: aws-observability
data:
  flb_log_cw: 'true'
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match *
        region us-east-1
        log_group_name /aws/eks/my-cluster/fargate
        log_stream_prefix fargate-
        auto_create_group true

Horizontal Pod Autoscaler sur Fargate

Fargate prend en charge le Horizontal Pod Autoscaler (HPA) de Kubernetes. Lorsque HPA augmente le nombre de réplicas, Fargate provisionne automatiquement de nouvelles micro-machines virtuelles, sans que vous ayez à ajuster la taille d'un groupe de nœuds. Vous bénéficiez ainsi d'une véritable mise à l'échelle serverless : HPA contrôle le nombre de pods et Fargate gère les ressources de calcul de manière élastique. Vous devez toutefois déployer le Metrics Server dans le cluster pour que HPA puisse lire l'utilisation du CPU et de la mémoire.

# Deploy Metrics Server (required for HPA)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Create an HPA for a Fargate-scheduled deployment
kubectl autoscale deployment my-api \
  --namespace production \
  --cpu-percent=60 \
  --min=2 \
  --max=20

Modèle tarifaire de Fargate

Vous payez Fargate en fonction des vCPU-secondes et GB-secondes consommés, avec un minimum d'une minute par pod. Il n'y a aucun coût au niveau des nœuds, frais de capacité réservée ni coût de mise à jour des AMI/OS. Fargate est généralement plus coûteux par unité de calcul que des instances EC2 à la demande correctement dimensionnées, mais le coût total de possession est souvent inférieur si l'on tient compte du temps d'ingénierie économisé sur la gestion des nœuds, les mises à jour et les décisions de mise à l'échelle.

Principales limites de Fargate à connaître

Principales limites de Fargate à retenir pour l'examen SAA-C03 : aucune prise en charge de DaemonSet (les pods ne peuvent pas être placés sur chaque nœud puisqu'il n'existe pas de nœuds persistants), aucun conteneur privilégié, aucun mode hostNetwork, et un stockage éphémère limité à 20 GB par pod (extensible à 200 GB avec une configuration). Le stockage persistant en mode bloc avec EBS n'est pas pris en charge ; utilisez EFS pour le stockage persistant partagé de fichiers avec les pods Fargate.

# Mount EFS in a Fargate pod (EBS is NOT supported on Fargate)
apiVersion: v1
kind: Pod
metadata:
  name: efs-pod
  namespace: production
spec:
  volumes:
  - name: efs-storage
    persistentVolumeClaim:
      claimName: efs-pvc
  containers:
  - name: app
    image: my-image:latest
    volumeMounts:
    - name: efs-storage
      mountPath: /data

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 : les profils Fargate utilisent des sélecteurs d'espace de noms et d'étiquettes pour planifier les pods de manière serverless, que le rôle d'exécution du pod autorise Fargate à récupérer les images et à écrire les journaux, et que Fargate ne prend pas en charge DaemonSets ni EBS — utilisez EFS pour le stockage persistant. Nous allons maintenant découvrir la mise en réseau EKS avec le module CNI VPC et le AWS Load Balancer Controller.

Questions Fréquemment Posées

La leçon « Profils Fargate pour les pods sans serveur » est-elle gratuite ?

Oui — le texte complet de « Profils Fargate pour les pods sans serveur » 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 « Profils Fargate pour les pods sans serveur » ?

Exécutez des pods Kubernetes sur Fargate sans gérer de nœuds EC2, configurez des profils Fargate et comprenez leurs restrictions d’espace de noms. 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 2 sur 4.

Combien de temps prend la leçon « Profils Fargate pour les pods sans serveur » ?

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