0Pricing
AWS Solutions Architect · บทเรียน

เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์

ใช้ปลั๊กอิน Amazon VPC CNI เพื่อให้พ็อดได้รับที่อยู่ IP ของ VPC โดยตรง และเปิดเผยบริการด้วย AWS Load Balancer Controller

เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์ เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

พื้นฐานเครือข่าย Kubernetes

Kubernetes กำหนดให้พ็อดทุกตัวมีที่อยู่ IP ที่ไม่ซ้ำกันและสามารถกำหนดเส้นทางได้ และให้พ็อดสื่อสารระหว่างกันได้โดยไม่ใช้ NAT ปลั๊กอิน Container Network Interface (CNI) มีหน้าที่กำหนด IP และกำหนดค่าเส้นทางเครือข่ายบนโหนดผู้ปฏิบัติงาน แพลตฟอร์ม Kubernetes แต่ละแบบใช้การทำงานของ CNI ที่แตกต่างกัน โดย AWS ใช้ Amazon VPC CNI plugin เพื่อผสานเครือข่าย Kubernetes เข้ากับชั้น VPC โดยตรง

ปลั๊กอิน Amazon VPC CNI

Amazon VPC CNI plugin กำหนดที่อยู่ IP ให้แต่ละพ็อดโดยตรงจากช่วง CIDR ของซับเน็ต VPC ของคุณ ซึ่งทำให้พ็อดเป็น สมาชิก VPC โดยตรง และสามารถเข้าถึงได้จากทรัพยากร VPC อื่น ระบบภายในองค์กรผ่าน VPN/Direct Connect และกลุ่มความปลอดภัย โดยไม่ต้องแปลงผ่านเครือข่ายซ้อนทับ โหนดผู้ปฏิบัติงาน EC2 แต่ละโหนดจะดูแลกลุ่ม IP ส่วนตัวสำรอง (หนึ่งรายการต่อช่อง ENI) ซึ่งจะถูกกำหนดให้พ็อดเมื่อพ็อดได้รับการจัดตาราง

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

กลุ่ม IP สำรองของ ENI และ IP Address

ปลั๊กอิน VPC CNI จะดูแล กลุ่ม IP ที่จัดสรรไว้ล่วงหน้าและพร้อมใช้งาน บนแต่ละโหนด เพื่อให้จัดตารางพ็อดได้อย่างรวดเร็ว เมื่อโหนดเริ่มทำงาน CNI จะเชื่อมต่อ ENI หลายรายการและกำหนด IP สำรองจนถึงค่าของตัวแปรสภาพแวดล้อม WARM_IP_TARGET หรือ MINIMUM_IP_TARGET ดังนั้นจำนวนพ็อดสูงสุดที่โหนดสามารถเรียกใช้ได้จึงจำกัดด้วยจำนวน ENI ของอินสแตนซ์คูณด้วยจำนวน IP ต่อ ENI ซึ่งแตกต่างกันไปตามประเภทอินสแตนซ์

# 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

กลุ่มความปลอดภัยสำหรับพ็อด

โดยค่าเริ่มต้น พ็อดทั้งหมดบนโหนดจะแชร์กลุ่มความปลอดภัยของโหนด เมื่อใช้คุณลักษณะ Security Groups for Pods คุณสามารถกำหนดกลุ่มความปลอดภัยแต่ละรายการให้กับพ็อดที่ระบุได้โดยใช้ทรัพยากรกำหนดเอง SecurityGroupPolicy ซึ่งช่วยให้ควบคุมการเข้าถึงเครือข่ายได้อย่างละเอียด เช่น อนุญาตให้เฉพาะพ็อดฐานข้อมูลรับการรับส่งข้อมูลบนพอร์ต 5432 จากกลุ่มความปลอดภัยของพ็อด API คุณลักษณะนี้ต้องใช้ VPC CNI เวอร์ชัน 1.7.7 ขึ้นไปและ ENI แบบ trunk บนโหนด

# 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

ประเภท Service ของ Kubernetes บน EKS

Services ของ Kubernetes ใช้เผยแพร่ชุดพ็อดภายใต้ชื่อ DNS และ IP ที่คงที่ บน EKS ประเภท Service ที่เกี่ยวข้องมีสามประเภท ได้แก่ ClusterIP (ใช้สื่อสารภายในคลัสเตอร์เท่านั้น) NodePort (เปิดพอร์ตบนทุกโหนด — ไม่ค่อยใช้บน EKS) และ LoadBalancer (จัดเตรียมตัวจัดสรรภาระงานของ AWS โดยอัตโนมัติ) ประเภท LoadBalancer เป็นวิธีที่ใช้เผยแพร่บริการ EKS ส่วนใหญ่ที่เปิดให้เข้าถึงจากอินเทอร์เน็ต

# 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

AWS Load Balancer Controller คือ Controller Kubernetes แบบโอเพนซอร์สที่จัดการทรัพยากร ALB และ NLB ในนามของคลัสเตอร์ EKS เมื่อคุณสร้างออบเจ็กต์ Kubernetes Ingress Controller จะจัดเตรียม Application Load Balancer เมื่อคุณสร้าง Service ประเภท LoadBalancer พร้อมคำอธิบายประกอบที่ถูกต้อง ระบบจะจัดเตรียม Network Load Balancer Controller นี้เข้ามาแทนที่ผู้ให้บริการตัวจัดสรรภาระงาน Kubernetes แบบ in-tree รุ่นเก่า

# 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

Kubernetes Ingress ด้วย ALB

ออบเจ็กต์ Kubernetes Ingress จะกำหนดกฎการกำหนดเส้นทาง HTTP/HTTPS — ตามเส้นทางและตามโฮสต์ — เข้าสู่คลัสเตอร์ของคุณ AWS Load Balancer Controller จะอ่านออบเจ็กต์ Ingress ที่มีคำอธิบายประกอบ kubernetes.io/ingress.class: alb และสร้าง Application Load Balancer ที่สอดคล้องกัน พร้อมกฎ Listener ที่ตรงตามเงื่อนไข วิธีนี้ช่วยขจัดความจำเป็นในการสร้าง ALB และกลุ่มเป้าหมายสำหรับบริการแต่ละแอปพลิเคชันด้วยตนเอง

# 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 สำหรับงาน TCP/UDP

เมื่อปริมาณงานของคุณต้องใช้ TCP หรือ UDP (ไม่ใช่ HTTP) เช่น เซิร์ฟเวอร์เกม บริการ gRPC หรือพร็อกซีฐานข้อมูล ให้ใช้ NLB แทน ALB เพิ่มคำอธิบายประกอบให้ Kubernetes Service ด้วย service.beta.kubernetes.io/aws-load-balancer-type: 'external' และ service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip' Controller จะจัดเตรียม NLB โดยใช้ IP ของพ็อดเป็นเป้าหมายโดยตรง จึงข้ามการส่งต่อพอร์ตระดับโหนดและมีเวลาแฝงต่ำลง

# 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

การแก้ไข DNS ภายในคลัสเตอร์

EKS เรียกใช้ CoreDNS เป็นผู้ให้บริการ DNS ของคลัสเตอร์ Service ทุกตัวจะได้รับชื่อ DNS ในรูปแบบ service-name.namespace.svc.cluster.local ซึ่งแก้ไขไปยัง ClusterIP ของ Service พ็อดก็สามารถค้นหาได้ผ่าน DNS เช่นกัน CoreDNS ถูกติดตั้งเป็น Deployment (ไม่ใช่ DaemonSet) และควรปรับขนาดเรพลิกาตามขนาดคลัสเตอร์ EKS จัดการ CoreDNS ในฐานะแอดออน ทำให้สามารถอัปเกรดเวอร์ชันโดยอัตโนมัติได้

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

นโยบายเครือข่ายใน EKS

ออบเจ็กต์ Kubernetes NetworkPolicy ใช้กำหนดกฎการอนุญาตสำหรับการรับส่งข้อมูลระหว่างพ็อดและจากพ็อดไปยังภายนอก โดยค่าเริ่มต้น พ็อดทั้งหมดในคลัสเตอร์สามารถสื่อสารกันได้อย่างอิสระ หากต้องการบังคับใช้เครือข่ายแบบไม่ไว้วางใจสิ่งใดโดยอัตโนมัติ คุณสามารถติดตั้ง ตัวควบคุมนโยบายเครือข่าย Amazon VPC CNI (พร้อมใช้งานตั้งแต่ VPC CNI v1.14) นโยบายเครือข่ายจะได้รับการประเมินในระดับเคอร์เนล Linux โดยใช้ eBPF จึงบังคับใช้นโยบายได้อย่างมีประสิทธิภาพสูงโดยไม่ต้องใช้เครือข่ายซ้อนทับ

# 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

เคล็ดลับการแก้ไขปัญหา VPC CNI

ปัญหาเครือข่าย EKS ที่พบบ่อย ได้แก่ ที่อยู่ IP ไม่เพียงพอ (แก้ไขโดยเปิดใช้การมอบหมายคำนำหน้าหรือเพิ่มซับเน็ตที่มีขนาดใหญ่ขึ้น) พ็อดค้างอยู่ในสถานะ Pending เนื่องจากโหนดไม่มี IP สำรองที่พร้อมใช้งาน และ การแก้ไข DNS ล้มเหลวเป็นระยะ เนื่องจากมีเรพลิกา CoreDNS ไม่เพียงพอ ใช้ kubectl describe pod เพื่อตรวจสอบเหตุการณ์ ใช้ kubectl describe node เพื่อดูจำนวน IP ที่จัดสรร และใช้ CloudWatch Container Insights เพื่อติดตามอัตราข้อผิดพลาด DNS ในระดับคลัสเตอร์

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

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า ปลั๊กอิน Amazon VPC CNI กำหนด IP ของ VPC โดยตรงให้กับทุกพ็อดเพื่อการผสานรวมกับ VPC อย่างราบรื่น AWS Load Balancer Controller จัดเตรียม ALB สำหรับ HTTP Ingress และ NLB สำหรับ TCP/UDP Services และ Security Groups for Pods ช่วยควบคุมการเข้าถึงเครือข่ายในระดับพ็อด ต่อไปเราจะสำรวจ IRSA เพื่อผูกบทบาท IAM ที่กำหนดสิทธิ์อย่างละเอียดกับบัญชีบริการ Kubernetes

คำถามที่พบบ่อย

บทเรียน “เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์”

ใช้ปลั๊กอิน Amazon VPC CNI เพื่อให้พ็อดได้รับที่อยู่ IP ของ VPC โดยตรง และเปิดเผยบริการด้วย AWS Load Balancer Controller คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ระนาบควบคุมและโหนดผู้ปฏิบัติงานของ EKS
  2. โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์
  3. เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์
  4. บทบาท IAM สำหรับบัญชีบริการ (IRSA)
← กลับไปที่ AWS Solutions Architect