สถาปัตยกรรมเครือข่ายสำหรับ EKS

ทฤษฎีและกลไกการทำงาน (How it works):
ใน Kubernetes (K8s) ทั่วไปที่รันบน Data Center คลัสเตอร์มักจะใช้เครือข่ายซ้อนทับ (Overlay Network เช่น Flannel หรือ Calico) ในการสร้าง IP จำลอง (Virtual IPs) แจกให้ Pods ทำให้ Pod IP มีตัวตนอยู่แค่ในคลัสเตอร์เท่านั้น โลกภายนอกหรือระบบในคอร์ปอเรทไม่รู้จัก IP เหล่านี้

แต่ Amazon EKS เปลี่ยนกฎเกมนี้ด้วย Amazon VPC CNI (Container Network Interface)
VPC CNI เป็นปลั๊กอินเครือข่ายเฉพาะของ AWS ที่ทำหน้าที่ขโมย (Allocate) IP Address พื้นเมืองจริงๆ จาก VPC Subnet มาแจกให้กับ Pods โดยตรง ทำให้ ทุก Pod ใน EKS มีศักดิ์และสิทธิ์เทียบเท่าเครื่อง EC2 หนึ่งเครื่อง มี IP จริง (Native IP) อยู่บน VPC จริงๆ สามารถคุยกับ EC2 เครื่องอื่น คุยกับ RDS หรือดึงข้อมูลข้าม VPC Peering ได้ทันทีโดยไม่ต้องทำ NAT ใดๆ

เบื้องหลัง VPC CNI จะสั่งให้ Worker Node (EC2) สร้าง Elastic Network Interface (ENI) เสริมขึ้นมา (Secondary ENIs) และดึง Secondary Private IPs มาตุนเก็บไว้ในสระน้ำ (Warm Pool) บนตัว Node เพื่อให้เมื่อเวลา Pod ใหม่เกิดปุ๊บ จะมี IP จริงจ่ายให้ใช้งานปั๊บ (Fast Pod startup)

# ตัวอย่างการ Patch `aws-node` DaemonSet 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: aws-node
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: aws-node
        env:
        # กำหนดให้ตุน Secondary IP เผื่อไว้ 5 IPs เสมอ (ป้องกัน Pod รอนาน)
        - name: WARM_IP_TARGET
          value: "5"
        # กำหนดให้ขอกลุ่ม IP น้อยที่สุดที่จำเป็น (ช่วยประหยัด IP ของ Subnet)
        - name: MINIMUM_IP_TARGET
          value: "2"
        

Use Case ในชีวิตจริง (Real-world Scenario):
ทีม Data Engineering รัน Airflow บน EKS เพื่อทำ ETL Pipeline หาก Pods ของ Airflow ต้องการดึงข้อมูลข้ามบัญชีจากฐานข้อมูล Redshift ใน Account อื่น การใช้ VPC CNI ตอบโจทย์ทันที เพราะ IP ของ Pod สามารถถูกนำไปทำ Whitelist ใน Security Group ของฝั่ง Redshift ได้โดยตรง (ต่างจาก Overlay Network ที่ฝั่ง Redshift จะมองเห็นแต่ IP ของ Node เท่านั้น ซึ่งกว้างเกินไป)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): "IP หมด VPC (IP Exhaustion)" คือศัตรูอันดับหนึ่งของ VPC CNI เพราะถ้าคุณสร้าง Subnet ขนาด /24 (251 IPs) และคุณดีพลอย Microservices ที่ Scale ขึ้นไป 300 Pods IP ในวงนั้นจะหมดเกลี้ยงทันที ทำให้ Pod ที่เหลือตกค้างอยู่ในสถานะ Pending (NetworkPluginNotReady) ตลอดกาล
* Mitigation (วิธีแก้): เมื่อสถาปัตยกรรมใช้ EKS ห้ามงก IP เด็ดขาด ต้องออกแบบ Subnet ของ Worker Node ให้กว้างอย่างน้อย /21 (2,000+ IPs) หรือใช้เทคนิค Custom Networking ควบคู่ไปกับ Secondary CIDR (เนื้อหาในหัวข้อถัดไป) เพื่อผลัก Pod ไปอยู่ในย่าน IP อื่น

ทฤษฎีและกลไกการทำงาน (How it works):
เมื่อ VPC เดิมมี IP จำกัด เช่น ได้รับสิทธิใช้แค่ /16 จากองค์กรใหญ่ และไม่สามารถขยายได้อีก การรัน EKS ที่สูบ IP เป็นน้ำกลายเป็นความเป็นไปไม่ได้ เทคนิคกอบกู้สถานการณ์คือ VPC Custom Networking ร่วมกับ Secondary CIDR Block

AWS อนุญาตให้คุณแปะ (Associate) เครือข่ายสำรองระดับ 100.64.0.0/10 (ซึ่งสงวนไว้สำหรับการทำ Carrier-Grade NAT ตามมาตรฐาน RFC 6598) เข้าไปใน VPC เครือข่ายนี้ไม่เคยซ้ำซ้อนกับ IP ภายในองค์กรใดๆ เพราะมันเป็น IP ที่ถูกกักไว้ใช้สำหรับสภาพแวดล้อมเสมือน

จากนั้น ด้วยฟีเจอร์ Custom Networking เราสามารถสั่ง VPC CNI ว่า "Node (EC2) ยังคงใช้ IP จากวงหลัก (เช่น 10.0.0.0/16) ต่อไปนะ แต่สำหรับ Pods ทั้งหมดที่เกิดบน Node นี้ ให้บังคับดึง IP จากวง 100.64.0.0/10 มาแจกเท่านั้น" ส่งผลให้เราแยกวง IP ระหว่างเซิร์ฟเวอร์หลักกับคอนเทนเนอร์ (Pod) ออกจากกันอย่างเด็ดขาด แก้ปัญหา IP Exhaustion ได้ 100%

# สร้าง ENIConfig ระบุ Subnet ย่าน 100.64.x.x และ Security Group
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
  name: ap-southeast-1a-pod-subnet
spec:
  securityGroups:
    - sg-0123456789abcdef0 # SG สำหรับ Pods โดยเฉพาะ
  subnet: subnet-0abcd12345ef67890 # Subnet ย่าน 100.64.0.0/18 (CGNAT)

---
# จากนั้นเซต env บน VPC CNI ให้ใช้ Custom Networking
# AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = true
# ENI_CONFIG_LABEL_DEF = topology.kubernetes.io/zone
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทด้าน Fintech ที่ควบรวมกิจการหลายบริษัท และใช้ Transit Gateway เชื่อมโยง VPC เข้าด้วยกัน มักเจอฝันร้ายจากการที่ VPC ของแต่ละบริษัทมีย่าน IP ชนกัน การให้ Kubernetes คาย Pod ออกมาพร้อมกับย่าน IP ขยะ (100.64.x.x) ช่วยประหยัดพื้นที่ Routing Table ส่วนกลาง (Corporate Routable Space) ไปได้นับหมื่น IP เพราะ Pod ภายในคลัสเตอร์ไม่ต้องถูกทำ Route ส่งไปบริษัทแม่ อาศัยแค่เครื่อง Node (EC2) ไปคุยแทนก็เพียงพอแล้ว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ทราฟฟิกขาออกจาก Pod ที่ใช้ย่าน IP 100.64.x.x เพื่อจะวิ่งไปหา Database ที่อยู่ใน VPC วงหลัก (10.0.x.x) บางครั้งทราฟฟิกจะหลงทาง เพราะ VPC ยอมรับเส้นทางของทั้งคู่ แต่องค์ประกอบอย่าง VPN Gateway อาจไม่รู้จักย่าน CGNAT
* Mitigation (วิธีแก้): ต้องทำความเข้าใจการทำงานของ External Source Network Address Translation (SNAT) ของ VPC CNI ตามปกติแล้ว ทราฟฟิกที่ออกจาก Pod เพื่อออกนอก VPC จะถูกทำ SNAT แปลงร่างเป็น IP ของ Node อัตโนมัติ (ซ่อนตัวตน Pod) คุณต้องตัดสินใจให้แน่วแน่ว่าจะปรับตั้งค่า AWS_VPC_K8S_CNI_EXTERNALSNAT เป็น true หรือ false ตามสถาปัตยกรรมเครือข่ายขอบบนของคุณ (Edge Architecture)

ทฤษฎีและกลไกการทำงาน (How it works):
ปัญหาความปลอดภัยระดับสถาปัตยกรรมของ EKS ยุคก่อนคือ Security Group (SG) จะผูกอยู่กับระดับ Node (EC2) แปลว่าถ้า Node หนึ่งเครื่องมีทั้ง Pod ที่รันระบบชำระเงิน (Payment) และ Pod ที่รันเว็บไซต์ (Frontend) คุณต้องเปิดพอร์ตฐานข้อมูลใน SG ของ Node นี้เพื่อให้ Payment คุยกับ DB ได้... ส่งผลให้ Frontend ที่แชร์รังอยู่บน Node เดียวกัน "พลอยได้สิทธิ์" ในการแทงทะลุไปหา DB ด้วย (Over-privileged Access)!

AWS แก้ปัญหานี้ด้วย Security Groups for Pods (ผ่านการทำ Branch ENIs)
ระบบอนุญาตให้คุณ "ฉีกกฎ" เดิมที่ SG คลุมทั้งเครื่อง โดยให้คุณคล้อง Security Group ไปที่ระดับของ Pod แต่ละตัวโดยตรงได้เลย! เมื่อ Pod สร้างขึ้น VPC CNI จะแตกกิ่ง (Branch) ขั้วต่อเครือข่ายลึกเข้าไปใน Pod และห่อหุ้มมันด้วย SG เฉพาะกิจ ทำให้เราสามารถทำ Zero Trust Architecture ในระดับคอนเทนเนอร์บน AWS ได้อย่างสมบูรณ์

# กำหนด Policy ว่า Pod ไหนที่มี label role=payment ให้ผูก SG พิเศษให้
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: payment-pod-sg-policy
  namespace: secure-apps
spec:
  podSelector:
    matchLabels:
      role: payment
  securityGroups:
    groupIds:
      - sg-0987654321fedcba0 # Payment SG (อนุญาตทะลุไป Database ได้)
        

Use Case ในชีวิตจริง (Real-world Scenario):
สภาพแวดล้อมแบบ Multi-tenant EKS Cluster (ใช้คลัสเตอร์เดียวร่วมกันหลายแผนกเพื่อประหยัดเงิน) ทีม Platform Engineer จะแบ่ง Namespace ระหว่างทีม Data Science และทีม Web Backend แต่ละ Namespace จะถูกบังคับด้วย SecurityGroupPolicy ว่า Data Science Pods จะได้ SG ที่วิ่งไปหา Redshift ได้เท่านั้น ส่วน Web Backend Pods จะได้ SG ที่ไปหา RDS MySQL เท่านั้น ทำให้การใช้คลัสเตอร์ร่วมกันปลอดภัยตามมาตรฐาน ISO/IEC 27001

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): การเปิดใช้งาน Security Groups for Pods ทำให้โครงสร้างเครือข่ายหนักขึ้น (Branch ENIs กินทรัพยากร) ทำให้จำนวน Pod สูงสุด (Pod Density) ที่รันได้บน EC2 1 เครื่อง ลดลงอย่างน่าใจหาย เช่น เครื่องตระกูล m5.large อาจรัน Pod ที่ใช้ฟีเจอร์นี้ได้เหลือไม่ถึง 10 ตัว
* Mitigation (วิธีแก้): ใช้ฟีเจอร์นี้ เฉพาะกับ Pod ที่ต้องการระดับความปลอดภัยสูงลิ่วจริงๆ เท่านั้น (Mission-critical workload) อย่าเหวี่ยงแหใช้กับทุก Pod ในคลัสเตอร์ สำหรับ Pod ทั่วไป ให้กลับไปใช้ Kubernetes Network Policies (เช่น Calico) ในการบล็อกพอร์ตภายในคลัสเตอร์แทนเพื่อประหยัดทรัพยากรเครื่อง

ทฤษฎีและกลไกการทำงาน (How it works):
ต่อเนื่องจากปัญหาข้อที่ 3 ขนาดของเครื่อง EC2 (Instance Type) มีขีดจำกัดการเชื่อมต่อ ENI และ Secondary IPs (เช่น t3.medium รองรับ ENI ได้ 3 ตัว และดึง IP ได้ ENI ละ 6 ตัว แปลว่ารัน Pod ได้แค่สูงสุด 17 ตัวบนเครื่องนี้) หากใช้ EKS รัน Microservices เล็กๆ ที่กินแรมน้อย แต่จำนวนหลักร้อย คุณต้องเปิดเครื่อง t3.medium มหาศาลเพียงเพราะ "IP ไม่พอแจก" (ทั้งที่ CPU/RAM ยังเหลือบานตะไท)

นวัตกรรมกอบกู้โลก (Game Changer) คือ IP Prefix Delegation
แทนที่ VPC CNI จะขอทีละ 1 IP (Secondary IPv4) มันจะวิ่งไปขอเป็น "ชุด" (Prefix /28) จาก AWS มาเลย การขอ /28 หมายถึงมันโกย IP มาตุนไว้ทีเดียว 16 IPs ต่อหนึ่งช่องสัญญาณ!
ทวีคูณพลังให้เครื่อง EC2 ตัวเดิมสามารถยัด Pods ลงไปได้เพิ่มขึ้น 4 ถึง 16 เท่า (เช่น จาก 17 Pods เพิ่มเป็น 100+ Pods สบายๆ บนอินสแตนซ์ขนาดเล็ก)

# การแก้ไข DaemonSet ผ่าน kubectl Command (หรือจัดการผ่าน Terraform aws_eks_addon)
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true

# ควรปรับค่า WARM_PREFIX_TARGET ควบคู่กัน (ตุนไว้ 1 ชุด คือ 16 IPs เสมอ)
kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1
        

Use Case ในชีวิตจริง (Real-world Scenario):
ระบบ Machine Learning Inference หรือ Data Ingestion API ที่มีทราฟฟิกสวิงขึ้นลงรุนแรงในช่วงเช้า (Spiky Traffic) และต้องการสเกล HPA (Horizontal Pod Autoscaler) จาก 10 ไป 500 Pods ภายใน 2 นาที การที่ VPC CNI มี Prefix Delegation ดึง IP มาตุนไว้เป็นกระตั้กๆ ทำให้กระบวนการตื่นตัวของ Pod (Pod Startup Time) ลดลงจากหลักนาทีเหลือเพียงไม่กี่วินาที (เพราะไม่ต้องรอ API ของ AWS VPC แจก IP ทีละเม็ด)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ดาบสองคมที่อันตรายที่สุด เมื่อเปิด Prefix Delegation ตัวเครื่อง Node จะตะกละมาก (Greedy) มันจะฮุบก้อน /28 (16 IPs) มาตุนไว้บนเครื่องทันที แม้ว่ามันจะรัน Pod แค่ 1 ตัวก็ตาม! หากคุณมี Node เยอะๆ ในคลัสเตอร์ IP ใน Subnet ของคุณจะหายวับไปในพริบตา (Fragmentation of IP space)
* Mitigation (วิธีแก้): ต้องจูนพารามิเตอร์ WARM_PREFIX_TARGET และ WARM_IP_TARGET อย่างละเอียดสุดๆ (Fine-tuning) และต้องมั่นใจว่าขนาด Subnet สำหรับ Worker Node นั้นใหญ่เกินพอ (อย่างน้อย /21 หรือกว้างกว่านั้น) หากมี IP จำกัด ห้ามเปิดฟีเจอร์นี้เด็ดขาด

ทฤษฎีและกลไกการทำงาน (How it works):
ใน Kubernetes แบบดั้งเดิม เมื่อสร้างคลาส Ingress Controller ทราฟฟิกจากภายนอกจะวิ่งมาที่ Load Balancer -> กระจายไปหา Worker Node (ผ่าน NodePort) -> และ Node ใช้ iptables โยนแพ็กเกจวนไปหา Pod ภายในอีกที ซึ่งกระบวนการผ่านหลายทอด (Extra Hopping) นี้ ทำให้เกิดความหน่วง (Latency) และเสียสมดุลการกระจายโหลด (Uneven load distribution)

AWS Load Balancer Controller (ALBC) ปฏิวัติสถาปัตยกรรมนี้ด้วยโหมด IP Target Routing
เนื่องจาก VPC CNI ทำให้ Pod มี Native IP อยู่แล้ว ตัว ALBC จะทำการควบคุม Application Load Balancer (ALB) หรือ Network Load Balancer (NLB) จากนอกคลัสเตอร์ ให้มันยิง Target เล็งเป้า "ทะลุเข้าไปที่ IP ของ Pod โดยตรง (Direct to Pod)"

สถาปัตยกรรมแบบข้ามหัว Node (Bypass NodePort) นี้ ลด Latency ระดับฮาร์ดแวร์ได้อย่างมาก (Network path optimization) และสามารถควบคุม Health Check ระดับ Pod แต่ละตัวผ่าน Load Balancer ได้แม่นยำ 100%

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "data-api-ingress"
  namespace: "production"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    # พระเอกของงาน! บังคับ ALB ยิง IP ของ Pod ตรงๆ
    alb.ingress.kubernetes.io/target-type: ip 
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-southeast-1:111122223333:certificate/abc-123
spec:
  rules:
    - host: api.pipecraft.data
      http:
        paths:
          - path: /v1/*
            pathType: Prefix
            backend:
              service:
                name: data-ingestion-svc
                port: 
                  number: 8080
        

Use Case ในชีวิตจริง (Real-world Scenario):
บนแพลตฟอร์ม Video Streaming ยักษ์ใหญ่ หรือ WebSockets API (เช่น โค้ดห้องแชทสด) ที่ต้องเปิด Connection แช่ค้างไว้ การสับเส้นทางทราฟฟิก (Hop) ในระบบเครือข่ายเดิมมักทำให้เกิดคอขวดที่ Node (SNAT Port Exhaustion) การให้ตัวกระจายโหลด (NLB) จัดการทราฟฟิกวิ่งส่งพัสดุถึงหน้าประตูบ้าน (Pod) โดยตรง ช่วยให้เครือข่ายรองรับ Concurrent Connections ได้ทะลุหลักล้าน (Millions of Connections) สบายๆ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): เมื่อใช้ Target-type: ip หมายความว่า Load Balancer (ALB) ของ AWS จะต้อง "ลงทะเบียน (Register)" และ "ถอนชื่อ (Deregister)" IP ของ Pod เข้า/ออกจากตัวมันเองตลอดเวลา เมื่อเกิดกระบวนการ Rolling Update กะทันหัน Pod หายวับไป 100 ตัว ALB อาจจะใช้เวลาประมวลผล 15-30 วินาทีในการถอนชื่อ ส่งผลให้คนเข้าเว็บในช่วงนั้นเจอหน้าจอ 502 Bad Gateway
* Mitigation (วิธีแก้): เมื่อใช้งานโหมดนี้ ห้าม ตั้งค่า Pod Graceful Shutdown ต่ำเด็ดขาด ต้องคอนฟิก preStop hook ใน Kubernetes Lifecycle ให้ Pod หน่วงเวลารอ (Sleep) สัก 10-15 วินาทีก่อนจะดับจริง เพื่อให้ ALB ทันถอดรายชื่อ IP ออกจาก Target Group อย่างสมบูรณ์และหยุดส่งทราฟฟิกเข้ามาในซาก Pod (Zero-downtime deployment pattern)