โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์
เรียกใช้พ็อด Kubernetes บน Fargate โดยไม่ต้องจัดการโหนด EC2 กำหนดค่าโปรไฟล์ Fargate และทำความเข้าใจข้อจำกัดด้านเนมสเปซ
โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์ เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน
Fargate Profiles คืออะไร
AWS Fargate for EKS ช่วยให้คุณเรียกใช้พ็อด Kubernetes ได้โดยไม่ต้องจัดเตรียมหรือจัดการโหนด EC2 แทนที่จะพิจารณาประเภทอินสแตนซ์และกลุ่มโหนด คุณสามารถกำหนด Fargate profile เพื่อบอก EKS ว่าพ็อดใดควรทำงานบน Fargate โดยพิจารณาจากเนมสเปซและตัวเลือกป้ายกำกับเพิ่มเติม AWS จะจัดเตรียมทรัพยากรคอมพิวท์ในปริมาณที่เหมาะสมสำหรับแต่ละพ็อดโดยอัตโนมัติ และยุติทรัพยากรนั้นเมื่อพ็อดหยุดทำงาน
การกำหนดค่า Fargate Profile
Fargate profile จะเชื่อมโยงกับคลัสเตอร์ EKS และมี ตัวเลือกการคัดเลือก อย่างน้อยหนึ่งรายการ โดยแต่ละรายการจะระบุเนมสเปซและคู่คีย์-ค่าของป้ายกำกับ Kubernetes ที่เป็นตัวเลือก พ็อดต้องตรงกับตัวเลือกอย่างน้อยหนึ่งรายการจึงจะถูกจัดตารางให้ทำงานบน Fargate ได้ นอกจากนี้ Profile ยังระบุ บทบาทการเรียกใช้พ็อด (บทบาท IAM) และซับเน็ตส่วนตัวที่ Fargate ควรใช้เพื่อเปิดใช้พ็อด
# 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"}}]'บทบาทการเรียกใช้พ็อด
บทบาทการเรียกใช้พ็อด คือบทบาท IAM ที่ EKS ใช้เมื่อ Fargate ดึงอิมเมจคอนเทนเนอร์และส่งบันทึกของพ็อดไปยัง CloudWatch บทบาทนี้ต้องมีนโยบายที่ AWS จัดการชื่อ AmazonEKSFargatePodExecutionRolePolicy หากไม่มีบทบาทนี้ พ็อดที่ถูกจัดตารางบน Fargate จะเริ่มทำงานไม่สำเร็จ เนื่องจาก Fargate ไม่สามารถยืนยันตัวตนกับ ECR หรือเขียนข้อมูลไปยัง 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ข้อจำกัดของเนมสเปซบน Fargate
Fargate มี ข้อจำกัดของเนมสเปซ ที่สำคัญ เนมสเปซ kube-system ไม่สามารถใช้กับ Fargate profile ส่วนใหญ่ได้ เนื่องจากพ็อดระบบ เช่น kube-proxy ทำงานอยู่ในเนมสเปซนี้ ข้อยกเว้นคือ CoreDNS โดย AWS มีกระบวนการแนะนำสำหรับแก้ไขการติดตั้ง CoreDNS เพื่อลบคำอธิบายประกอบ eks.amazonaws.com/compute-type: ec2 ทำให้สามารถทำงานบน Fargate ได้ พ็อดในเนมสเปซที่ถูกยกเว้นจะยังคงไม่ได้รับการจัดตาราง หากไม่มีโหนด 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การกำหนดขนาดทรัพยากรของพ็อดบน Fargate
Fargate จัดสรรทรัพยากรคอมพิวท์ตาม คำขอ CPU และหน่วยความจำ ที่กำหนดไว้ในข้อมูลจำเพาะของพ็อด ระบบจะปัดขึ้นเป็นชุด vCPU/หน่วยความจำที่ Fargate รองรับซึ่งใกล้เคียงที่สุด (เช่น 0.25 vCPU / 0.5 GB ถึง 16 vCPU / 120 GB) คุณจะถูกเรียกเก็บเงินเฉพาะทรัพยากรที่จัดสรรต่อวินาทีในขณะที่พ็อดทำงานเท่านั้น ควรกำหนดคำขอทรัพยากรให้ถูกต้องเสมอ การขอทรัพยากรต่ำเกินไปจะทำให้โปรแกรมถูกหยุดเนื่องจากหน่วยความจำไม่เพียงพอ ส่วนการขอทรัพยากรมากเกินไปจะเพิ่มค่าใช้จ่าย
# 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 เทียบกับกลุ่มโหนด EC2: ข้อแลกเปลี่ยน
Fargate ช่วยขจัดภาระการจัดการโหนด แต่มีข้อจำกัด ได้แก่ ไม่รองรับ daemonsets (เนื่องจากไม่มีโหนดถาวรสำหรับจัดตารางให้ทำงาน) ไม่รองรับคอนเทนเนอร์ที่มีสิทธิ์พิเศษ และรองรับประเภทพื้นที่จัดเก็บบางชนิดอย่างจำกัด กลุ่มโหนด EC2 รองรับ GPU เคอร์เนลแบบกำหนดเอง และงานที่มีสถานะซึ่งใช้ไดรฟ์ NVMe ในเครื่อง รูปแบบการใช้งานที่พบบ่อยคือเรียกใช้บริการไร้สถานะบน Fargate และเรียกใช้งานที่มีสถานะหรืองาน GPU บนกลุ่มโหนด EC2 เฉพาะภายในคลัสเตอร์ EKS เดียวกัน
เครือข่าย Fargate และกลุ่มความปลอดภัย
พ็อด Fargate แต่ละรายการจะได้รับ อินเทอร์เฟซเครือข่ายแบบยืดหยุ่น (ENI) ของตนเองและ IP ส่วนตัวจากซับเน็ตที่คุณระบุไว้ใน Profile ซึ่งหมายความว่าคุณสามารถใช้ กลุ่มความปลอดภัย ที่ไม่ซ้ำกันกับแต่ละพ็อดได้โดยใช้คุณลักษณะ Security Groups for Pods พ็อด Fargate รองรับกฎกลุ่มความปลอดภัย VPC มาตรฐานทั้งหมด ทำให้ควบคุมการรับส่งข้อมูลขาเข้าและขาออกในระดับพ็อดแต่ละรายการได้อย่างละเอียด ซึ่งเป็นข้อได้เปรียบด้านความปลอดภัยที่สำคัญเมื่อเทียบกับกลุ่มความปลอดภัยที่ใช้ร่วมกันในระดับโหนด
# 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 ไปยัง CloudWatch
พ็อด Fargate ส่งบันทึกไปยัง Amazon CloudWatch Logs โดยใช้ตัวกำหนดเส้นทางบันทึก Fluent Bit ในตัว คุณกำหนดค่าการบันทึกข้อมูลได้โดยสร้าง ConfigMap ชื่อ aws-logging ในเนมสเปซ aws-observability บทบาทการเรียกใช้พ็อดต้องมีสิทธิ์สร้างกลุ่มบันทึกและเขียนเหตุการณ์บันทึก บันทึกจะถูกจัดระเบียบเป็นกลุ่มบันทึก CloudWatch แยกตามคลัสเตอร์และเนมสเปซ ทำให้รวมบันทึกไว้ที่ศูนย์กลางได้ง่ายโดยไม่ต้องเรียกใช้ตัวแทนบันทึกแยกต่างหาก
# 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 trueHorizontal Pod Autoscaler บน Fargate
Fargate รองรับ Horizontal Pod Autoscaler (HPA) ของ Kubernetes เมื่อ HPA เพิ่มจำนวนเรพลิกา Fargate จะจัดเตรียมไมโคร VM ใหม่โดยอัตโนมัติ โดยที่คุณไม่ต้องปรับขนาดกลุ่มโหนด ประสบการณ์การปรับขนาดอัตโนมัติแบบไร้เซิร์ฟเวอร์นี้ทำให้ HPA ควบคุมจำนวนพ็อด และ Fargate จัดการทรัพยากรคอมพิวท์ให้ยืดหยุ่นตามความต้องการ อย่างไรก็ตาม คุณยังต้องติดตั้ง Metrics Server ในคลัสเตอร์เพื่อให้ HPA อ่านการใช้งาน CPU และหน่วยความจำได้
# 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รูปแบบค่าบริการของ Fargate
คุณจ่ายค่าบริการ Fargate ตาม vCPU-second และ GB-second ที่ใช้ โดยมีค่าขั้นต่ำ 1 นาทีต่อพ็อด ไม่มีค่าใช้จ่ายระดับโหนด ค่าความจุที่จองไว้ หรือค่าใช้จ่ายในการแก้ไข AMI/OS โดยทั่วไป Fargate มีค่าใช้จ่ายต่อหน่วยคอมพิวท์สูงกว่าอินสแตนซ์ EC2 แบบตามการใช้งานที่มีขนาดเหมาะสม แต่ต้นทุนรวมตลอดอายุการใช้งานมักต่ำกว่าเมื่อคำนึงถึงเวลาของวิศวกรที่ประหยัดได้จากการไม่ต้องจัดการโหนด แก้ไขระบบ และตัดสินใจเรื่องการปรับขนาด
ข้อจำกัดสำคัญของ Fargate ที่ควรทราบ
ข้อจำกัดสำคัญของ Fargate สำหรับการสอบ SAA-C03 ได้แก่ ไม่รองรับ DaemonSet (ไม่สามารถวางพ็อดไว้บนแต่ละโหนดได้ เนื่องจากไม่มีโหนดถาวร) ไม่รองรับคอนเทนเนอร์ที่มีสิทธิ์พิเศษ ไม่รองรับโหมด hostNetwork และพื้นที่จัดเก็บชั่วคราวจำกัดที่ 20 GB ต่อพ็อด (ขยายได้ถึง 200 GB ด้วยการกำหนดค่า) ไม่รองรับพื้นที่จัดเก็บแบบบล็อกถาวรด้วย EBS — ให้ใช้ EFS สำหรับพื้นที่จัดเก็บไฟล์ถาวรที่ใช้ร่วมกันกับพ็อด 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ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า Fargate profiles ใช้ตัวเลือกการคัดเลือกตามเนมสเปซและป้ายกำกับเพื่อจัดตารางพ็อดแบบไร้เซิร์ฟเวอร์ บทบาทการเรียกใช้พ็อด มอบสิทธิ์ให้ Fargate ดึงอิมเมจและเขียนบันทึก และ Fargate ไม่รองรับ DaemonSets หรือ EBS — ให้ใช้ EFS สำหรับพื้นที่จัดเก็บถาวร ต่อไปเราจะสำรวจเครือข่าย EKS ด้วยปลั๊กอิน VPC CNI และ AWS Load Balancer Controller
คำถามที่พบบ่อย
บทเรียน “โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์”
เรียกใช้พ็อด Kubernetes บน Fargate โดยไม่ต้องจัดการโหนด EC2 กำหนดค่าโปรไฟล์ Fargate และทำความเข้าใจข้อจำกัดด้านเนมสเปซ คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม
ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ระนาบควบคุมและโหนดผู้ปฏิบัติงานของ EKS
- โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์
- เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์
- บทบาท IAM สำหรับบัญชีบริการ (IRSA)