เลเยอร์ที่เชื่อมต่อได้ (Pluggable Layers)

ทฤษฎีและกลไกการทำงาน (How it works):
ความจีเนียสของ Kubernetes คือมันกำหนด "กฎ" ของเครือข่ายเอาไว้ แต่ มันไม่ยอมลงมือสร้างเครือข่ายเอง กฎที่ว่ามีเพียง 3 ข้อ:
1. ทุก Pod ต้องมี IP Address เป็นของตัวเอง
2. Pod ทุกตัวต้องคุยข้ามหากันได้โดยไม่ต้องทำ NAT (Network Address Translation)
3. IP ที่ Pod มองเห็นตัวเอง ต้องเป็น IP เดียวกันกับที่คนอื่นมองเห็นมัน

เมื่อ K8s กำหนดกฎเสร็จ มันเปิดช่องเสียบปลั๊กที่เรียกว่า CNI (Container Network Interface) เพื่อให้บริษัทภายนอก (เช่น Calico, Flannel, Cilium) มาเขียนโปรแกรมสร้างเครือข่ายตามกฎนี้ เลเยอร์เครือข่ายของ K8s ซ้อนกันเป็น 4 ชั้น:
* Layer 1 (ในสุด): คอนเทนเนอร์ใน Pod เดียวกัน คุยกันผ่าน localhost (127.0.0.1)
* Layer 2 (Pod Network): เสกโดย CNI ทำให้ Pod ข้ามเครื่อง Node คุยกันได้ด้วย IP ประจำตัว
* Layer 3 (Service Network): สร้าง Virtual IP หน้าบ้านเพื่อรับโหลดบาลานซ์ (เพราะ IP ของ Pod เปลี่ยนแปลงตลอดเวลา)
* Layer 4 (นอกสุด): รับทราฟฟิกจากผู้ใช้งานจริงนอกคลัสเตอร์เข้าสู่ระบบผ่าน Ingress หรือ NodePort

# คุณจะเห็น Pod ของ CNI (เช่น calico-node หรือ aws-node) ฝังตัวอยู่ทุกๆ เครื่องในฐานะ DaemonSet
$ kubectl get pods -n kube-system -o wide | grep -E "calico|flannel|cilium|aws-node"

calico-node-abc12   1/1   Running   0   10d   10.0.1.5   node-1
calico-node-xyz98   1/1   Running   0   10d   10.0.1.6   node-2
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัท FinTech แห่งหนึ่งต้องการระบบเครือข่ายที่มีความเร็วสูงปรี๊ดและกิน CPU ต่ำ พวกเขาตัดสินใจถอดปลั๊ก Flannel ที่เป็น CNI ดั้งเดิมออก แล้วเสียบปลั๊ก Cilium (ซึ่งใช้เทคโนโลยี eBPF ทำงานระดับ Kernel) เข้าไปแทน การเปลี่ยน CNI นี้ทำให้พวกเขาลด Latency ลงได้ 40% และได้ฟีเจอร์ Network Security ระดับลึกมาใช้ฟรีๆ โดยไม่ต้องไปยุ่งกับ Source Code ของ Kubernetes Core เลยแม้แต่นิดเดียว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ปัญหา "IP Address Exhaustion" มือใหม่มักเลือก CIDR Block (ช่วงของ IP) ให้กับ Pod Network เล็กเกินไป (เช่น /24 ซึ่งมีแค่ 254 IPs) เมื่อสเกลระบบจนจำนวน Pod เกิน 254 ตัว ระบบจะไม่สามารถสร้าง Pod ใหม่ได้อีก ค้างอยู่ที่สถานะ ContainerCreating
* Mitigation (วิธีแก้): การออกแบบ IPAM (IP Address Management) ต้องทำตั้งแต่ก่อนสร้างคลัสเตอร์ (Day 0) ควรเผื่อ CIDR ของ Pods ให้ใหญ่พอ (เช่น /16 หรือขี้เหร่สุดคือ /20) หากคลัสเตอร์รันไปแล้ว การเปลี่ยน CIDR ของ Pod Network ภายหลังแทบจะเป็นไปไม่ได้โดยไม่เกิด Downtime ขนาดใหญ่

ทฤษฎีและกลไกการทำงาน (How it works):
Pod เกิดมาเพื่อตาย (Ephemeral) ถ้าคุณเซฟรูปลงไปในโฟลเดอร์ของคอนเทนเนอร์ เมื่อ Pod รีสตาร์ท รูปนั้นจะหายวับไปตลอดกาล เพื่อแก้ปัญหานี้ K8s จึงมีระบบ Persistent Storage ซึ่งใช้หลักการ "ถอดปลั๊กสับเปลี่ยนได้" เช่นเดียวกัน เรียกว่า CSI (Container Storage Interface)

สถาปัตยกรรมแบ่งออกเป็น 3 ชิ้นส่วนหลักที่ทำงานประสานกัน:
1. StorageClass: แคตตาล็อกสินค้าที่บอกว่าคลัสเตอร์นี้มีดิสก์แบบไหนให้เบิกบ้าง (เช่น fast-ssd บน AWS EBS, nfs-slow สำหรับเก็บ Log)
2. PersistentVolumeClaim (PVC): "ใบเบิกของ" ที่ Developer เขียนขอสเปก (เช่น ขอ SSD ขนาด 10GB)
3. PersistentVolume (PV): ดิสก์ก้อนจริงที่ถูกสร้างและดึงมาผูกติด (Bound) กับใบเบิก PVC เมื่อพร้อมใช้งาน Kubelet จะเมาท์ (Mount) ดิสก์ก้อนนี้เข้าไปใน Pod

การแยก PVC (คนขอ) ออกจาก PV (ของจริง) เป็นสถาปัตยกรรมที่ช่วยแยกหน้าที่ (Decoupling) ระหว่าง Developer และ Infrastructure Admin ได้อย่างหมดจด

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-storage-pvc
spec:
  accessModes:
    - ReadWriteOnce # อนุญาตให้เมาท์เข้ากับ Node เดียวเท่านั้น (เหมาะกับ Database)
  storageClassName: aws-ebs-gp3 # ระบุรุ่นของดิสก์ในแคตตาล็อก
  resources:
    requests:
      storage: 10Gi
        

Use Case ในชีวิตจริง (Real-world Scenario):
ระบบ Machine Learning สมัยใหม่มักจะมีการอ่าน Dataset ขนาดยักษ์พร้อมๆ กัน ทีม Data Science จะสร้าง PVC โดยระบุ accessModes: ReadWriteMany เพื่อขอเบิก Storage แบบ Network File System (เช่น AWS EFS หรือ NFS) ทำให้ Pod ประมวลผลจำนวน 50 ตัว สามารถเมาท์โฟลเดอร์เดียวกันและแชร์ไฟล์อ่านร่วมกันได้ในเวลาเดียวกัน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): หากคุณเผลอลบ PVC ทิ้ง ดิสก์จริง (PV) จะปลิวหายไปพร้อมข้อมูลสำคัญหรือไม่? คำตอบขึ้นอยู่กับนโยบาย Reclaim Policy หากตั้งไว้เป็น Delete (ค่า Default ของ Cloud หลายเจ้า) ข้อมูลคุณจะหายสาบสูญไปพร้อมกับใบเบิกทันที
* Mitigation (วิธีแก้): สำหรับข้อมูลที่มีความสำคัญอย่างยิ่งยวด (เช่น Database) ผู้ดูแลระบบต้องตั้งค่า StorageClass หรือ Patch ตัว PV ให้มี persistentVolumeReclaimPolicy: Retain เสมอ เมื่อ PVC ถูกลบ PV จะเปลี่ยนสถานะเป็น Released (ไม่ลบข้อมูลทิ้ง) รอให้แอดมินมาตรวจสอบและจัดการแบ็กอัปด้วยตนเอง

ทฤษฎีและกลไกการทำงาน (How it works):
ตามหลักการ 12-Factor App (การเขียนแอปยุคใหม่) เราต้อง ห้ามฮาร์ดโค้ด (Hardcode) ตัวแปรสภาพแวดล้อมหรือรหัสผ่านลงไปใน Source Code เด็ดขาด Kubernetes จึงเตรียม Object 2 ชนิดไว้ให้:
1. ConfigMap: ใช้เก็บข้อมูลทั่วไปที่เปิดเผยได้ (เช่น URL ของ Database, ค่า Timeout, Nginx config)
2. Secret: ใช้เก็บข้อมูลความลับ (เช่น รหัสผ่าน, API Keys, TLS Certificates)

เมื่อคุณสร้าง ConfigMap/Secret ไว้ในคลัสเตอร์ Kubelet สามารถฉีด (Inject) ข้อมูลเหล่านี้เข้าไปใน Pod ได้ 2 วิธี คือ
* แปลงเป็นตัวแปร Environment Variables
* แปลงเป็น ไฟล์ (Volume Mount) ไปวางแปะไว้ในโฟลเดอร์ของคอนเทนเนอร์ (อัปเดตไฟล์แบบ Hot-reload ได้เมื่อค่าเปลี่ยน)

spec:
  containers:
  - name: my-app
    image: my-app:latest
    env:
      - name: DB_HOST
        valueFrom:
          configMapKeyRef: # ดึงจาก ConfigMap
            name: app-config
            key: db_url
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef: # ดึงจาก Secret
            name: db-credentials
            key: password
        

Use Case ในชีวิตจริง (Real-world Scenario):
ทีมพัฒนาสร้าง Docker Image เพียงตัวเดียว (build once) แล้วนำไป Deploy ใน 3 สภาพแวดล้อม (Dev, Staging, Prod) ได้เลย โดยอาศัยการสับเปลี่ยน ConfigMap ตามแต่ละ Environment ทำให้มั่นใจได้ว่าโค้ดที่ผ่านการทดสอบจาก Dev จะเป็นโค้ดชุดเดียวกันเป๊ะกับที่รันบน Production (Immutable Image) ลดปัญหา "โค้ดรันได้แค่เครื่องผม" ลงได้อย่างสิ้นเชิง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): อคติที่ว่า "Secret ปลอดภัยขั้นสุด" ความจริงคือ Secret ใน K8s โดย Default เป็นแค่การเข้ารหัสแบบ Base64 Encoding เท่านั้น (ซึ่งใครๆ ก็ Decode กลับมาอ่านได้ด้วยคำสั่ง echo "..." | base64 -d) มันไม่ได้ถูกเข้ารหัสทางคณิตศาสตร์ (Encryption) แต่อย่างใด
* Mitigation (วิธีแก้): ในระดับ Enterprise ต้องเปิดใช้งาน Encryption at Rest บน API Server เพื่อให้ข้อมูล Secret ถูกเข้ารหัสจริงๆ ก่อนลงไปเก็บใน etcd และควรบูรณาการใช้เครื่องมือภายนอกอย่าง HashiCorp Vault หรือ AWS Secrets Manager ร่วมกับปลั๊กอิน External Secrets Operator เพื่อดึงรหัสผ่านลงมาที่คลัสเตอร์ในระดับรันไทม์

ทฤษฎีและกลไกการทำงาน (How it works):
เนื่องจาก Pod เกิดและตายตลอดเวลา IP ของพวกมันจึงเปลี่ยนไปเรื่อยๆ คุณไม่สามารถชี้ Traffic ไปหา IP ของ Pod ตรงๆ ได้ K8s จึงสร้างคอนเซปต์ Service ซึ่งเป็น "ป้ายทะเบียนเสมือน (Virtual IP)" ที่ไม่มีวันเปลี่ยนแปลง
Service จะใช้ Selector (เช่น หาตัวที่มี Label app: web) เพื่อกวาดหา IP ของ Pod ทุกตัวที่ตรงเงื่อนไข (เรียกว่า Endpoints) แล้วทำหน้าที่รับ Traffic และกระจายโหลด (Load Balance) ไปยัง Pod เหล่านั้น

ประเภทของ Service และ Ingress:
1. ClusterIP: เปิดให้คุยกันได้แค่ *ภายใน* คลัสเตอร์เท่านั้น (ปลอดภัยสุด ใช้กับ Database)
2. NodePort: เปิดพอร์ตสูงๆ (30000-32767) ทะลุทะลวงเข้ามาที่ทุกเครื่อง Node (ทางเข้าสำหรับชาวบ้าน)
3. LoadBalancer: ไปสั่ง Cloud Provider ให้เสก Load Balancer ของจริงมาครอบ NodePort อีกที
4. Ingress: ไม่ใช่ Service แต่เป็น "ยามเฝ้าประตู (Reverse Proxy Layer 7)" ตัวเดียวที่รับ Traffic ขาเข้า (HTTP/HTTPS) แล้วอ่าน URL/Domain เพื่อกระจาย (Route) ไปยัง Service ต่างๆ ในคลัสเตอร์ ช่วยประหยัดค่า Load Balancer ไปได้มหาศาล

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
spec:
  rules:
  - host: api.mycompany.com
    http:
      paths:
      - path: /v1/users
        pathType: Prefix
        backend:
          service:
            name: user-service # โยนไปหา Service ของ User
            port:
              number: 80
      - path: /v1/payments
        pathType: Prefix
        backend:
          service:
            name: payment-service # โยนไปหา Service ของ Payment
            port:
              number: 80
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทยักษ์ใหญ่ที่มี Microservices กว่า 100 ตัว หากพวกเขาใช้ LoadBalancer Service สำหรับทุกแอป พวกเขาจะต้องจ่ายค่าเช่า Load Balancer ของคลาวด์ถึง 100 ตัว (สิ้นเปลืองมาก) พวกเขาจึงใช้ Ingress Nginx เพียง 1 ตัวรับ Load Balancer แล้วใช้กฎของ Ingress (Host/Path) โยนทราฟฟิกไปหา 100 บริการที่อยู่ด้านหลัง ประหยัดค่าใช้จ่ายมหาศาลและจัดการ SSL Certificate ได้ที่จุดศูนย์กลางจุดเดียว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Asymmetric Routing เมื่อใช้ NodePort ทราฟฟิกจะวิ่งเข้ามาที่ Node-A แต่อาจจะถูก SNAT (Source NAT) และโยนไปให้ Pod ที่อยู่บน Node-B ทำให้ IP ต้นทางของลูกค้าที่แท้จริง (Client IP) สูญหายไป แอปพลิเคชันจะเห็นว่า Request ทุกอันมาจาก IP ของ K8s Node
* Mitigation (วิธีแก้): หากแอปพลิเคชันของคุณต้องการบันทึก IP ลูกค้าที่แท้จริง (เพื่อทำ Rate Limit หรือ Security Log) คุณต้องตั้งค่า Service ให้เป็น externalTrafficPolicy: Local ซึ่งจะบังคับให้ทราฟฟิกตกใส่เฉพาะ Node ที่มี Pod ตัวนั้นรันอยู่เท่านั้น (ข้าม Node ไม่ได้) เพื่อหลีกเลี่ยงการทำ SNAT กลางทาง

ทฤษฎีและกลไกการทำงาน (How it works):
ความฝันสูงสุดของการทำ Orchestration คือความสามารถในการรับมือกับความผันผวนของทราฟฟิกโดยไม่ต้องใช้มนุษย์ K8s มีแก๊ง 3 ทหารเสือในการทำ Autoscaling:
1. HPA (Horizontal Pod Autoscaler): หน้าที่คือ "เพิ่ม/ลดจำนวน Pod" (สเกลแนวนอน) โดยอ่านค่าจาก Metrics API เช่น ถ้า CPU เฉลี่ยของกลุ่ม Pod เกิน 70% ให้เพิ่มจำนวน Pod เข้าไปหารภาระ
2. VPA (Vertical Pod Autoscaler): หน้าที่คือ "เพิ่ม/ลดสเปก (Requests/Limits)" ของ Pod (สเกลแนวตั้ง) เหมาะกับแอปที่สเกลแนวนอนไม่ได้ (เช่น Database บางชนิด) มันจะประเมินการกินทรัพยากรจริง แล้วจับ Pod รีสตาร์ทเพื่อฉีดสเปกใหม่ที่ใหญ่กว่าเดิมให้
3. Cluster Autoscaler (CA): หน้าที่คือ "เพิ่ม/ลดจำนวนเครื่องเซิร์ฟเวอร์ (Node)" เมื่อ HPA เสก Pod ออกมาเยอะจนเต็มทุก Node แล้ว Pod ใหม่จะติดสถานะ Pending ตัว CA จะเห็นสถานะนี้ และวิ่งไปสั่ง Cloud ให้เปิด VM ใหม่มารับโหลดทันที

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-frontend
  minReplicas: 2 # อย่างน้อยต้องมี 2 ตัวเสมอ
  maxReplicas: 10 # ขยายได้สูงสุดไม่เกิน 10 ตัว
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70 # ถ้า CPU เฉลี่ยทะลุ 70% ให้งอก Pod ใหม่
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในวัน Black Friday ระบบ HPA ตรวจจับได้ว่า CPU ของเว็บพุ่งแตะ 80% มันจึงเริ่มเสก Pod เพิ่มจาก 2 เป็น 5 เป็น 10 จนกระทั่งเครื่องเซิร์ฟเวอร์ในคลัสเตอร์เต็ม (CPU จองเต็มขีดจำกัด) Pod ตัวที่ 11 จะขึ้นสถานะ Pending ทันใดนั้น Cluster Autoscaler ทำงาน สั่งเปิดเครื่อง Node ใหม่ใช้เวลา 2 นาที เมื่อ Node พร้อม Pod ตัวที่ 11-20 ก็หลั่งไหลเข้าไปรันบนเครื่องใหม่ และเมื่อผ่านพ้นช่วงโปรโมชัน ทราฟฟิกหดหาย HPA ลด Pod ลงมาเหลือ 2 ตัว CA เห็นว่ามีเครื่อง Node ว่างงานเกิน 10 นาที ก็จะสั่งลบเครื่องนั้นทิ้งเพื่อประหยัดเงินบริษัท (Scale-to-zero principles)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): "HPA สู้กับ VPA (The Scaling Fight)" มือใหม่เผลอเปิดใช้ HPA (สเกลจำนวนอิง CPU) และ VPA (สเกลสเปกอิง CPU) กับ Deployment ตัวเดียวกันพร้อมๆ กัน สิ่งที่เกิดคือ เมื่อ CPU สูง HPA จะเสก Pod เพิ่ม ในขณะเดียวกัน VPA จะจับ Pod รีสตาร์ทเพื่อเพิ่มสเปก ทำให้ระบบรวนและเกิด Downtime ขึ้นอย่างน่าประหลาด
* Mitigation (วิธีแก้): ห้ามใช้ HPA และ VPA อ่านค่า Metrics เดียวกัน (เช่น CPU) ใน Workload ตัวเดียวกันเด็ดขาด หากจำเป็นต้องใช้คู่กัน HPA ควรอ่านค่า Custom Metrics (เช่น จำนวนคิวใน RabbitMQ) แทนที่จะอ่าน CPU ปล่อยให้ VPA เป็นคนดูแลไซส์ CPU/Memory ไปตัวเดียว

ทฤษฎีและกลไกการทำงาน:
เดิมที K8s Network ต้องพึ่งพา iptables ซึ่งมีความซับซ้อนและล่าช้าเมื่อคลัสเตอร์ใหญ่ขึ้น เทคโนโลยีใหม่ล่าสุดอย่าง eBPF (Extended Berkeley Packet Filter) ยอมให้เรารันโปรแกรม Sandboxed ระดับ Kernel ได้โดยตรง
CNI สมัยใหม่อย่าง Cilium ใช้ eBPF ในการจัดการ Network, Security และ Observability โดยลัดขั้นตอน iptables ทำให้ Route แพ็กเก็ตได้ด้วยความเร็วเทียบเท่า Native OS

# การดูสถานะของ Cilium และ eBPF Maps ในระบบ
cilium status
cilium bpf tunnel list
        

Use Case ในชีวิตจริง:
บริษัท FinTech มี Services กว่า 2,000 ตัว ทำให้ iptables rules มีขนาดใหญ่ทะลุหมื่นบรรทัด คลัสเตอร์จึงมีอาการหน่วงเวลาเพิ่ม Pod ใหม่ พวกเขาตัดสินใจเปลี่ยน CNI มาใช้ Cilium ทำให้เวลาในการโหลด Network Policies ลดจาก 10 วินาทีเหลือต่ำกว่า 50 มิลลิวินาที

ข้อควรระวังและวิธีแก้:
* Pitfall: eBPF เป็นเทคโนโลยีที่ผูกติดกับ Linux Kernel สมัยใหม่ หากรันบน OS เก่าๆ (เช่น CentOS 7) จะใช้งาน Cilium แบบเต็มประสิทธิภาพไม่ได้
* Mitigation: ต้องอัปเกรด Linux Kernel ของ Node ให้ใหม่เพียงพอ (อย่างน้อย Kernel 4.19+) ก่อนที่จะเปลี่ยนมาใช้ Cilium