AWS Solutions Architect · leksjon

Fargate-profiler for serverløse pods

Kjør Kubernetes-pods på Fargate uten å administrere EC2-noder, konfigurer Fargate-profiler, og forstå begrensningene for navnerom

Leksjon 2 av 413 trinn

Fargate-profiler for serverløse pods er en gratis leksjon i AWS Solutions Architect på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i AWS Solutions Architect, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i AWS Solutions Architect inneholder totalt 4 leksjoner.

Hva er Fargate-profiler?

AWS Fargate for EKS lar Dem kjøre Kubernetes-pods uten å klargjøre eller administrere EC2-noder. I stedet for å tenke på instanstyper og nodegrupper definerer De en Fargate-profil som forteller EKS hvilke pods som skal kjøre på Fargate, basert på navnerommet deres og valgfrie etikettselektorer. AWS klargjør automatisk riktig mengde datakapasitet for hver pod og avslutter den når poden stopper.

Konfigurasjon av Fargate-profil

En Fargate-profil er knyttet til en EKS-klynge og inneholder én eller flere selektorer – hver selektor angir et navnerom og valgfrie Kubernetes-etiketter som består av nøkkel-verdi-par. En pod må samsvare med minst én selektor for å bli planlagt på Fargate. Profilen angir også kjøringsrollen for pod (en IAM-rolle) og de private subnettene Fargate skal bruke til å starte 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"}}]'

Kjøringsrolle for pod

Kjøringsrollen for pod er en IAM-rolle som EKS antar når Fargate henter containeravbildninger og sender pod-logger til CloudWatch. Den må inneholde den AWS-administrerte policyen AmazonEKSFargatePodExecutionRolePolicy. Uten denne rollen vil pods som planlegges på Fargate, ikke kunne starte, fordi Fargate ikke kan autentisere mot ECR eller skrive til 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

Navneromsbegrensninger på Fargate

Fargate har viktige navneromsbegrensninger. Navnerommet kube-system er ikke tilgjengelig for de fleste Fargate-profiler, fordi system-pods som kube-proxy kjører der. CoreDNS er et unntak: AWS tilbyr en veiledet prosess for å oppdatere CoreDNS-distribusjonen og fjerne annotasjonen eks.amazonaws.com/compute-type: ec2, slik at den kan kjøre på Fargate. Pods i ekskluderte navnerom forblir ikke-planlagte hvis ingen EC2-noder er tilgjengelige.

# 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

Ressursdimensjonering for Fargate-pods

Fargate tildeler datakapasitet basert på CPU- og minneforespørslene som er definert i pod-spesifikasjonen. Verdiene rundes opp til nærmeste vCPU-/minnekombinasjon som støttes av Fargate (for eksempel fra 0,25 vCPU / 0,5 GB til 16 vCPU / 120 GB). De betaler bare for ressursene som er tildelt per sekund mens poden kjører. Angi alltid nøyaktige ressursforespørsler – for lave forespørsler fører til at prosesser avsluttes på grunn av utilstrekkelig minne, mens for høye forespørsler øker kostnadene.

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

Fargate kontra EC2-nodegrupper: avveininger

Fargate eliminerer nodeadministrasjon, men har begrensninger: ingen daemonsets (siden det ikke finnes vedvarende noder å planlegge dem på), ingen privilegerte containere og begrenset støtte for enkelte lagringstyper. EC2-nodegrupper støtter GPU-er, egendefinerte kjerner og tilstandsfulle arbeidsbelastninger med lokale NVMe-stasjoner. Et vanlig mønster er å kjøre tilstandsløse tjenester på Fargate og tilstandsfulle arbeidsbelastninger eller GPU-arbeidsbelastninger på dedikerte EC2-nodegrupper i samme EKS-klynge.

Fargate-nettverk og sikkerhetsgrupper

Hver Fargate-pod får sitt eget elastiske nettverksgrensesnitt (ENI) og en privat IP-adresse fra subnettet De angav i profilen. Dette betyr at De kan bruke en unik sikkerhetsgruppe for hver pod ved hjelp av funksjonen Security Groups for Pods. Fargate-pods støtter alle standardregler for VPC-sikkerhetsgrupper, noe som gir detaljert kontroll over innkommende og utgående trafikk på individuelt pod-nivå – en betydelig sikkerhetsfordel sammenlignet med delte sikkerhetsgrupper på nodenivå.

# 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

Fargate-logging til CloudWatch

Fargate-pods sender logger til Amazon CloudWatch Logs ved hjelp av den innebygde Fluent Bit-loggruteren. De konfigurerer logging ved å opprette en ConfigMap med navnet aws-logging i navnerommet aws-observability. Kjøringsrollen for poden må ha tillatelse til å opprette logggrupper og skrive logghendelser. Logger organiseres i CloudWatch-logggrupper per klynge og navnerom, noe som gjør sentralisert loggsamling enkelt uten å kjøre en separat loggagent.

# 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 på Fargate

Fargate støtter Kubernetes-ressursen Horizontal Pod Autoscaler (HPA). Når HPA skalerer ut antallet replikaer, klargjør Fargate automatisk nye mikro-VM-er uten at De må justere størrelsen på noen nodegruppe. Dette gir en ekte serverløs autoskaleringsopplevelse: HPA styrer antallet pods, mens Fargate håndterer datakapasiteten elastisk. De trenger likevel Metrics Server distribuert i klyngen for at HPA skal kunne lese CPU- og minnebruk.

# 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

Prisingsmodell for Fargate

De betaler for Fargate basert på forbrukte vCPU-sekunder og GB-sekunder, med en minimumsbetaling på ett minutt per pod. Det påløper ingen kostnader på nodenivå, kostnader for reservert kapasitet eller kostnader for oppdatering av AMI/operativsystem. Fargate er vanligvis dyrere per datakapasitetsenhet enn EC2-on-demand-instanser med riktig størrelse, men de totale eierkostnadene er ofte lavere når De tar hensyn til tiden utviklingsteamet sparer på nodeadministrasjon, oppdateringer og skaleringsbeslutninger.

Vanlige Fargate-begrensninger De bør kjenne til

Viktige Fargate-begrensninger for SAA-C03-eksamen: ingen støtte for DaemonSet (pods kan ikke plasseres på hver node fordi det ikke finnes vedvarende noder), ingen privilegerte containere, ingen hostNetwork-modus, og midlertidig lagring er begrenset til 20 GB per pod (kan utvides til 200 GB med en konfigurasjon). Vedvarende blokklagring med EBS støttes ikke – bruk EFS for delt, vedvarende fillagring med Fargate-pods.

# 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

Hurtigsjekk

Test forståelsen Deres av AWS Solutions Architect-konsepter (SAA-C03) fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen lærte De at: Fargate-profiler bruker navneroms- og etikettselektorer til å planlegge pods serverløst, kjøringsrollen for pod gir Fargate tillatelse til å hente avbildninger og skrive logger, og Fargate støtter ikke DaemonSets eller EBS – bruk EFS for vedvarende lagring. Neste tema er EKS-nettverk med VPC CNI-pluginen og AWS Load Balancer Controller.

Gratis å komme i gang

Lær deg AWS Solutions Architect med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 30
Leksjoner: 120

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Fargate-profiler for serverløse pods» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien AWS Solutions Architect, inkludert «Fargate-profiler for serverløse pods», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i AWS Solutions Architect inneholder totalt 4 leksjoner.

Hva lærer jeg i «Fargate-profiler for serverløse pods»?

Kjør Kubernetes-pods på Fargate uten å administrere EC2-noder, konfigurer Fargate-profiler, og forstå begrensningene for navnerom Du øver på AWS Solutions Architect med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med AWS Solutions Architect?

Ingen tidligere erfaring er nødvendig. AWS Solutions Architect på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Fargate-profiler for serverløse pods»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne AWS Solutions Architect-leksjonen?

Ja. Alle AWS Solutions Architect-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

EKS-kontrollplan og arbeidsnoder
Fargate-profiler for serverløse pods
EKS-nettverk: VPC CNI og lastbalansering
IAM-roller for tjenestekontoer (IRSA)

← Tilbake til AWS Solutions Architect