AWS Solutions Architect · Lekcja

Profile Fargate dla bezserwerowych podów

Uruchamiać pody Kubernetes na Fargate bez zarządzania węzłami EC2, konfigurować profile Fargate oraz poznawać ograniczenia dotyczące przestrzeni nazw.

Lekcja 2 z 413 kroki

Profile Fargate dla bezserwerowych podów to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 2 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 AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Czym są profile Fargate?

AWS Fargate dla EKS umożliwia uruchamianie podów Kubernetes bez aprowizowania i zarządzania węzłami EC2. Zamiast zajmować się typami instancji i grupami węzłów, definiują Państwo profil Fargate, który informuje EKS, które pody powinny działać na Fargate na podstawie ich przestrzeni nazw i opcjonalnych selektorów etykiet. AWS automatycznie aprowizuje odpowiednią ilość zasobów obliczeniowych dla każdego poda i usuwa ją po zatrzymaniu poda.

Konfiguracja profilu Fargate

Profil Fargate jest przypisany do klastra EKS i zawiera co najmniej jeden selektor — każdy selektor określa przestrzeń nazw oraz opcjonalne pary klucz-wartość etykiet Kubernetes. Pod musi pasować do co najmniej jednego selektora, aby mógł zostać zaplanowany na Fargate. Profil określa również rolę wykonywania poda (rolę IAM) oraz prywatne podsieci, których Fargate powinien używać do uruchamiania podów.

# 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"}}]'

Rola wykonywania poda

Rola wykonywania poda to rola IAM, którą EKS przyjmuje podczas pobierania obrazów kontenerów przez Fargate i wysyłania dzienników podów do CloudWatch. Musi ona zawierać zarządzaną przez AWS politykę AmazonEKSFargatePodExecutionRolePolicy. Bez tej roli pody zaplanowane na Fargate nie uruchomią się, ponieważ Fargate nie będzie mógł uwierzytelnić się w ECR ani zapisywać danych w 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

Ograniczenia przestrzeni nazw w Fargate

Fargate nakłada ważne ograniczenia przestrzeni nazw. Przestrzeń nazw kube-system jest niedostępna dla większości profili Fargate, ponieważ działają w niej pody systemowe, takie jak kube-proxy. Wyjątkiem jest CoreDNS: AWS udostępnia przeprowadzany krok po kroku proces modyfikowania wdrożenia CoreDNS w celu usunięcia adnotacji eks.amazonaws.com/compute-type: ec2, aby mogło ono działać na Fargate. Pody w wykluczonych przestrzeniach nazw pozostaną niezaplanowane, jeśli nie będą dostępne węzły EC2.

# 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

Dobór zasobów podów Fargate

Fargate przydziela zasoby obliczeniowe na podstawie żądań CPU i pamięci zdefiniowanych w specyfikacji poda. Zaokrągla je w górę do najbliższej obsługiwanej kombinacji vCPU/pamięci Fargate (na przykład od 0,25 vCPU / 0,5 GB do 16 vCPU / 120 GB). Opłaty są naliczane wyłącznie za zasoby przydzielone na sekundę działania poda. Zawsze należy ustawiać dokładne żądania zasobów — zbyt niskie żądania prowadzą do zakończenia procesu z powodu braku pamięci, a zbyt wysokie zwiększają koszty.

# 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 a grupy węzłów EC2: kompromisy

Fargate eliminuje konieczność zarządzania węzłami, ale ma ograniczenia: brak obsługi daemonsetów (ponieważ nie ma trwałych węzłów, na których można je zaplanować), brak kontenerów uprzywilejowanych oraz ograniczona obsługa niektórych typów pamięci masowej. Grupy węzłów EC2 obsługują procesory GPU, niestandardowe jądra oraz obciążenia stanowe z lokalnymi dyskami NVMe. Często stosowanym rozwiązaniem jest uruchamianie bezstanowych usług na Fargate, a obciążeń stanowych lub GPU na dedykowanych grupach węzłów EC2 w ramach tego samego klastra EKS.

Sieci Fargate i grupy zabezpieczeń

Każdy pod Fargate otrzymuje własny elastyczny interfejs sieciowy (ENI) oraz prywatny adres IP z podsieci określonej w profilu. Oznacza to, że za pomocą funkcji Security Groups for Pods można przypisać każdemu podowi unikalną grupę zabezpieczeń. Pody Fargate obsługują wszystkie standardowe reguły grup zabezpieczeń VPC, zapewniając szczegółową kontrolę ruchu przychodzącego i wychodzącego na poziomie pojedynczego poda — to istotna przewaga w zakresie bezpieczeństwa nad współdzielonymi grupami zabezpieczeń na poziomie węzłów.

# 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

Rejestrowanie podów Fargate w CloudWatch

Pody Fargate wysyłają dzienniki do Amazon CloudWatch Logs za pomocą wbudowanego routera dzienników Fluent Bit. Konfigurację rejestrowania przeprowadza się, tworząc element ConfigMap o nazwie aws-logging w przestrzeni nazw aws-observability. Rola wykonywania poda musi mieć uprawnienia do tworzenia grup dzienników i zapisywania zdarzeń dziennika. Dzienniki są porządkowane w grupach dzienników CloudWatch według klastra i przestrzeni nazw, co ułatwia centralne agregowanie dzienników bez uruchamiania osobnego agenta.

# 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 na Fargate

Fargate obsługuje Kubernetesowy Horizontal Pod Autoscaler (HPA). Gdy HPA zwiększa liczbę replik, Fargate automatycznie aprowizuje nowe mikromaszyny wirtualne, bez konieczności zmiany rozmiaru grupy węzłów. Zapewnia to rzeczywiście bezserwerowe automatyczne skalowanie: HPA steruje liczbą podów, a Fargate elastycznie obsługuje zasoby obliczeniowe. W klastrze nadal trzeba wdrożyć Metrics Server, aby HPA mógł odczytywać użycie CPU i pamięci.

# 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

Model cenowy Fargate

Opłaty za Fargate są naliczane za zużyte vCPU-sekundy i GB-sekundy, przy czym minimalny czas rozliczenia wynosi 1 minutę na pod. Nie ma kosztów na poziomie węzłów, opłat za zarezerwowaną przepustowość ani kosztów aktualizowania AMI/systemu operacyjnego. Fargate jest zwykle droższy za jednostkę zasobów obliczeniowych niż odpowiednio dobrane instancje EC2 na żądanie, ale całkowity koszt posiadania często jest niższy po uwzględnieniu zaoszczędzonego czasu inżynierów na zarządzaniu węzłami, aktualizacjach i decyzjach dotyczących skalowania.

Najważniejsze ograniczenia Fargate

Najważniejsze ograniczenia Fargate na egzaminie SAA-C03: brak obsługi DaemonSet (pody nie mogą być umieszczane na każdym węźle, ponieważ nie ma trwałych węzłów), brak kontenerów uprzywilejowanych, brak trybu hostNetwork oraz pamięć ulotna ograniczona do 20 GB na pod (z możliwością zwiększenia do 200 GB za pomocą konfiguracji). Trwała pamięć blokowa EBS nie jest obsługiwana — w przypadku podów Fargate należy używać EFS do współdzielonego trwałego przechowywania plików.

# 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

Szybkie sprawdzenie

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

Odpowiedz w interaktywnej lekcji

Podsumowanie lekcji

W tej lekcji poznali Państwo: profile Fargate używają selektorów przestrzeni nazw i etykiet do bezserwerowego planowania podów, rola wykonywania poda przyznaje Fargate uprawnienia do pobierania obrazów i zapisywania dzienników, a Fargate nie obsługuje DaemonSet ani EBS — do trwałego przechowywania danych należy używać EFS. Następnie omówimy sieci EKS z wtyczką VPC CNI i kontrolerem AWS Load Balancer Controller.

Bezpłatny start

Ucz się AWS Solutions Architect dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 30
Lekcje: 120

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Profile Fargate dla bezserwerowych podów” jest bezpłatna?

Tak — pełny tekst „Profile Fargate dla bezserwerowych podów” 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 AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Co nauczysz się w „Profile Fargate dla bezserwerowych podów”?

Uruchamiać pody Kubernetes na Fargate bez zarządzania węzłami EC2, konfigurować profile Fargate oraz poznawać ograniczenia dotyczące przestrzeni nazw. Ćwiczysz AWS Solutions Architect 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ąć AWS Solutions Architect?

Nie wymagamy żadnego doświadczenia. AWS Solutions Architect 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 2 z 4.

Ile czasu zajmuje lekcja „Profile Fargate dla bezserwerowych podów”?

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 AWS Solutions Architect?

Tak. Każda lekcja AWS Solutions Architect 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 AWS Solutions Architect