การรันบนโปรดักชันระดับองค์กร

ทฤษฎีและกลไกการทำงาน (How it works):
Kubernetes ไม่ได้มีวัตถุ (Objects) ครบทุกอย่างบนโลกมาตั้งแต่เกิด (มีแค่ Pods, Services, Deployments ฯลฯ) แต่ความเก่งของมันคือความสามารถในการ "สอนคำศัพท์ใหม่" ให้กับคลัสเตอร์ ผ่านระบบที่เรียกว่า CRD (Custom Resource Definition)

เมื่อคุณลงทะเบียน CRD สำเร็จ K8s API Server จะรู้จักคำสั่งใหม่ทันที แต่แค่รู้จักคำศัพท์มันยังไม่เกิดประโยชน์ คุณต้องมี Operator (ซึ่งก็คือ Custom Controller ที่รันเป็น Pod อยู่ในคลัสเตอร์) มาคอยทำหน้าที่อ่าน Desired State ของวัตถุชนิดใหม่นี้ และลงมือทำงาน (Reconcile)

รูปแบบ Operator Pattern นี้คือการดึงเอา "ความรู้ของแอดมินที่เป็นคน (Human Domain Knowledge)" มาเขียนเป็นโค้ด เพื่อให้มันสามารถติดตั้ง, อัปเกรด, แบ็กอัป, หรือกู้คืนระบบที่มีความซับซ้อน (Stateful apps อย่าง Database) ได้โดยอัตโนมัติ

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: main-prometheus
spec:
  replicas: 2
  retention: 15d
  storage:
    volumeClaimTemplate:
      spec:
        resources:
          requests:
            storage: 50Gi
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทจัดการข้อมูลใช้ Strimzi Operator ในการบริหารจัดการ Apache Kafka บน Kubernetes ในอดีตการสร้าง Kafka Cluster ต้องการทีมงานผู้เชี่ยวชาญดูแลหลายวัน แต่ด้วย Operator ทีมงานแค่เขียน YAML ประกาศว่าต้องการ Kafka 3 Brokers ตัว Operator จะจัดการเสก Zookeeper, ปรับจูนคอนฟิก, ดูแลเรื่องเครือข่าย และเมื่อมี Broker พัง Operator จะทำการกู้คืนข้อมูลซิงก์กลับมาให้เองอัตโนมัติราวกับมีแอดมินเฝ้าจอ 24 ชั่วโมง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ถ้าคุณเผลอไปลบ CRD (ตัวนิยามคำศัพท์) ทิ้งจากคลัสเตอร์ K8s จะทำการ Cascading Deletion (ลบกวาดล้าง) Custom Resources ที่สร้างจาก CRD นั้นทิ้งทั้งหมดโดยอัตโนมัติ! Database อันมีค่าของคุณอาจจะปลิวหายไปในพริบตาเพียงเพราะลบ CRD ผิดตัว
* Mitigation (วิธีแก้): ล็อกสิทธิ์ RBAC ห้ามใครก็ตาม (แม้แต่แอดมินทั่วๆ ไป) สั่ง delete crd อย่างเด็ดขาด และควรใช้เครื่องมือ GitOps (เช่น ArgoCD) ในการจัดการ CRD ควบคู่กับระบบสำรองข้อมูล (Velero) เสมอ

ทฤษฎีและกลไกการทำงาน (How it works):
การรัน Kubernetes แบ่งความรับผิดชอบออกเป็น 2 แนวทางหลัก:
1. Self-hosted (DIY): คุณรับเหมาเองหมด (ใช้ kubeadm, kubespray, kops) ต้องดูแลตั้งแต่ระดับ VM, การตั้งค่า etcd ให้เป็น HA, การหมุนเวียน TLS Certificates ทุกปี, และการอัปเกรดเวอร์ชัน API Server ที่สุดแสนจะอันตราย
2. Managed Kubernetes (EKS, GKE, AKS): Cloud Provider รับเหมาดูแลสมอง (Control Plane) ให้คุณทั้งหมด คุณแค่จ่ายเงิน (เช่น $73/เดือน) แล้วคุณจะได้ API Server ที่ไม่มีวันตาย สิ่งที่คุณต้องดูแลเหลือแค่ฝั่ง Worker Nodes (พนักงาน) เท่านั้น

หลักการทำงานขององค์กรส่วนใหญ่ในปัจจุบันคือ "หลีกเลี่ยงการทำ Self-hosted Control Plane ยกเว้นแต่มีเหตุผลจำเป็นทางข้อกฎหมาย หรือเป็นแบบ On-Premises เท่านั้น" เพราะความพยายาม (Operation overhead) ในการกู้คืน etcd ที่พังนั้น ไม่คุ้มกับมูลค่าทางธุรกิจเลย

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 19.0"

  cluster_name    = "production-cluster"
  cluster_version = "1.28" # ควบคุมแค่เวอร์ชัน

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 10
      instance_types = ["m5.large"]
    }
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทสตาร์ทอัพพยายามประหยัดงบโดยการทำ Self-hosted K8s บน EC2 เปล่าๆ ปรากฏว่าผ่านไป 1 ปี TLS Certificate หมดอายุแบบไม่รู้ตัว คลัสเตอร์ดับทั้งระบบ (Kubelet คุยกับ API Server ไม่ได้) ในที่สุดพวกเขายอมแพ้และย้ายระบบทั้งหมดมายัง EKS (Managed) ปล่อยให้ AWS จัดการต่ออายุ Certificate และอัปเดต Security Patches อัตโนมัติ ช่วยให้ทีม Engineer เอาเวลาไปเขียนโค้ดแอปพลิเคชันสร้างรายได้แทน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): แม้จะใช้ Managed Service แบบ EKS แต่ถ้าคุณปล่อยเวอร์ชัน Kubernetes ทิ้งไว้นานๆ โดยไม่อัปเกรด (End of Life) Cloud Provider อาจจะ "บังคับอัปเกรด (Forced Upgrade)" อัตโนมัติ ซึ่งถ้า API บางตัวในโค้ดเก่าคุณเลิกใช้ (Deprecated API) โค้ดคุณจะพังทั้งหมดตอนถูกบังคับอัปเกรด
* Mitigation (วิธีแก้): Kubernetes ออกเวอร์ชันใหม่ทุก 4 เดือน คุณต้องมีรอบอัปเกรดคลัสเตอร์อย่างน้อยปีละ 1-2 ครั้ง และต้องใช้เครื่องมืออย่าง pluto หรือ kubent สแกนหา Deprecated APIs ในไฟล์ YAML เสมอก่อนกดอัปเกรด Control Plane

ทฤษฎีและกลไกการทำงาน (How it works):
สถาปัตยกรรมระดับองค์กรต้องทนทานต่อรอยรั่ว (Resilience) เรามาดูกันว่า K8s จัดการกับวิกฤตอย่างไร:
* The Node Death: หาก Worker Node เกิดไฟดับ Kubelet จะหยุดส่งสัญญาชีพ (Heartbeat) ไปที่ API Server เมื่อผ่านไป 40 วินาที K8s จะป้ายสถานะ Node เป็น NotReady และเมื่อครบ 5 นาที (Taint node.kubernetes.io/unreachable) ระบบจะเริ่มภารกิจไล่ที่ (Evict) โดยดึง Pod ทั้งหมดไปเกิดใหม่บนเครื่องอื่น
* The Network Partition: ถ้าสายแลนขาด (Node ยังรันอยู่ แต่คุยกับ Control Plane ไม่ได้) ระบบ K8s จะพยายามอพยพ Pod ไปเครื่องอื่น แต่ในขณะเดียวกันเครื่องที่เน็ตหลุดก็จะยังพยายามรันแอปเดิมต่อไป ทำให้เกิดปัญหา "Split-brain" (แอปเดียวแต่มีตัวตนรันอยู่ 2 เครื่องพร้อมกัน) ซึ่งอาจทำให้ Database เขียนข้อมูลซ้ำซ้อนจนพังได้

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2 # สั่งตายตัวว่า: ห้ามเกิดเหตุการณ์ใดๆ ที่ทำให้แอปนี้รันน้อยกว่า 2 ตัวเด็ดขาด!
  selector:
    matchLabels:
      app: web
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในกรณีแอปพลิเคชันประเภท Stateful (เช่น PostgreSQL แบบ Master-Slave) การเกิด Split-brain จะอันตรายมาก K8s ป้องกันด้วยระบบพ่วงกับ Storage กล่าวคือ ดิสก์ (PV) แบบ ReadWriteOnce จะถูกบังคับให้เมาท์ได้แค่บน Node เดียวเท่านั้น หาก Node A เน็ตหลุดและ K8s พยายามไปเกิด Pod บน Node B ตัว Node B จะไม่สามารถดึงดิสก์มาเมาท์ได้จนกว่าจะแน่ใจจริงๆ ว่า Node A ปล่อยมือจากดิสก์ก้อนนั้นแล้ว (Fencing mechanism)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): แอปบางตัวใช้เวลาบูตนาน 3 นาที หาก Node ดับ และ K8s รีบสร้าง Pod ใหม่ขึ้นมาแทน กว่าจะพร้อมใช้งาน ลูกค้าก็เจอหน้า Error ไปแล้ว 3 นาที
* Mitigation (วิธีแก้): สถาปัตยกรรมที่ถูกต้องคือ คุณต้องมี Pod สำรองรันรออยู่แล้วเสมอ (Overprovisioning) ตั้งแต่แรก (เช่น รัน 3 ตัวกระจาย 3 Availability Zones) หากพังไป 1 โหลดจะเทไปหา 2 ตัวที่เหลือทันที (Zero Downtime) ส่วนกระบวนการที่ K8s สร้าง Pod ใหม่มาเติมเต็ม เป็นแค่การ "ซ่อมเกราะให้กลับมาเต็มหลอด" ในภายหลังเท่านั้น ไม่ใช่เพื่อรับโหลดตอนเกิดเหตุ

ทฤษฎีและกลไกการทำงาน (How it works):
คลัสเตอร์ดิบๆ ที่เพิ่งติดตั้งเสร็จ ถือว่าไร้เกราะป้องกัน (Flat Network) แอดมินและแอปพลิเคชันทุกตัวมีสิทธิ์ทำลายล้างระบบได้ องค์กรระดับสูงจึงต้องบังคับใช้ 3 เสาหลักความปลอดภัย:
1. RBAC (Role-Based Access Control): กำหนดสิทธิ์ว่าใคร (User/ServiceAccount) สามารถทำอะไร (Verbs: get, list, create) กับสิ่งใด (Resources: pods, secrets) ได้บ้าง
2. Network Policies: เปรียบเสมือน Firewall ระดับ Pod โดยค่าเริ่มต้น Pod คุยหากันได้หมด (Default Allow All) ซึ่งอันตรายมาก Network Policy จะเข้ามาจับล็อกให้เป็น (Default Deny All) และอนุญาตเฉพาะแอปที่เกี่ยวข้องกันคุยกันได้เท่านั้น (Micro-segmentation)
3. Admission Controllers: ด่านสกัดกั้นสุดท้ายหน้า API Server ถึงคุณจะมีสิทธิ์สร้าง Pod (ผ่าน RBAC) แต่ถ้า Admission Controller (เช่น OPA Gatekeeper หรือ Kyverno) ตรวจพบว่า Pod ของคุณจะแอบใช้สิทธิ์ Root (Privileged) มันจะเตะคำสั่งคุณทิ้งทันที

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-only-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database # บังคับใช้กับ Pod ของ Database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend-api # อนุญาตให้เฉพาะ Pod ของ Backend เข้ามาคุยได้เท่านั้น!
    ports:
    - protocol: TCP
      port: 5432
        

Use Case ในชีวิตจริง (Real-world Scenario):
สมมติแฮกเกอร์สามารถเจาะหาช่องโหว่บนเว็บไซต์ Frontend และรันคำสั่ง Remote Code Execution (RCE) ได้ แฮกเกอร์พยายามจะสั่ง curl ข้ามเครือข่ายภายในไปหาฐานข้อมูล Billing โดยตรง แต่ต้องพ่ายแพ้ให้กับ Network Policies ที่จำกัดสิทธิ์ให้ Frontend คุยได้แค่กับ Backend เท่านั้น แฮกเกอร์ถูกขังอยู่ในกรงของ Namespace และไม่สามารถเจาะทะลวงระบบอื่นๆ (Lateral Movement) ไปได้อีก

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): นักพัฒนามักขี้เกียจและปล่อยให้แอปของตนรันด้วยสิทธิ์ root (UID 0) ภายในคอนเทนเนอร์ หากเกิดช่องโหว่ประเภท Container Breakout แฮกเกอร์จะหลุดออกมาจากคอนเทนเนอร์และยึด Worker Node ได้ทั้งเครื่องทันที
* Mitigation (วิธีแก้): บังคับใช้นโยบาย Pod Security Standards (PSS) ระดับ Restricted ห้ามคอนเทนเนอร์รันด้วย Root และห้ามเข้าถึง Host Network/PID เด็ดขาด บังคับให้ตั้งค่า runAsNonRoot: true ใน SecurityContext ของทุก Deployment

ทฤษฎีและกลไกการทำงาน (How it works):
แม้จะเป็นเทคโนโลยีเปลี่ยนโลก แต่ Kubernetes ก็มี "ขอบคม (Sharp Edges)" ที่บาดมือ Engineer มานักต่อนัก สิ่งที่คุณต้องเฝ้าระวังสูงสุดคือ:
1. CoreDNS Bottlenecks: ทุกครั้งที่แอปคุณเรียกชื่อโดเมน (เช่น my-db.local) มันต้องไปถาม CoreDNS เสมอ หากคุณมีแอปหลักพันตัวยิง DNS ควบคู่กัน CoreDNS จะรับโหลดไม่ไหว ส่งผลให้แอปพากัน Timeout ระนาว
2. IP SNAT Port Exhaustion: เมื่อแอปภายในคลัสเตอร์ของคุณ พยายามยิงออกไปหา External API นอกคลัสเตอร์ (ผ่าน NAT Gateway) หากยิงออกด้วย Concurrency ที่สูงมาก (เช่น 50,000 requests/sec) พอร์ตที่ใช้ทำ NAT จะถูกใช้จนหมดเกลี้ยง (Port Exhaustion) ทำให้ทราฟฟิกขาออกร่วงหล่นหายไปดื้อๆ
3. CronJob Overlaps: หากคุณรันสคริปต์ CronJob ประมวลผล 1 ชั่วโมง แต่ตั้งให้มันทำงานทุก 30 นาที มันจะเกิด Pod ซ้อนทับกัน (Overlap) เหยียบไฟล์เดียวกัน แย่งทรัพยากรกันจนโกลาหล

# การปรับ Config เล็กน้อยในระดับ Pod สามารถช่วยแก้ปัญหา DNS Lookup ช้า
# สั่งให้ค้นหา IPv4 อย่างเดียว (A record) แทนการค้นหา IPv6 (AAAA) ควบคู่ไปด้วย
spec:
  dnsConfig:
    options:
    - name: single-request-reopen
    - name: ndots
      value: "2" # ลดภาระการสุ่มหา Suffix ต่อท้ายโดเมน
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทจัดแคมเปญแจกของรางวัล มีคนเข้าเว็บพร้อมกันหลักแสนคน ระบบสเกล Pod ไปที่ 500 ตัวอย่างรวดเร็ว ปรากฏว่าทุกแอปพยายามทำ DNS Lookup รหัสสินค้า โหลดตกไปอยู่ที่ CoreDNS แค่ 2 ตัว (คอขวด) ระบบพินาศทั้งๆ ที่ CPU ของ Web Server ยังเหลือเฟือ ทางแก้ระดับ Enterprise คือการติดตั้ง NodeLocal DNSCache (รัน DNS Proxy ไว้ที่ทุกเครื่อง Node เป็น DaemonSet) ทำให้แอปไม่ต้องวิ่งข้ามเครื่องไปถาม CoreDNS กลาง แต่แคชคำตอบที่เครื่องตัวเองเลย ลด Latency และความเสี่ยงได้อย่างหมดจด

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): หลุมพรางที่คลาสสิกที่สุดคือการเปิดทิ้ง Default Service Account ไว้ให้กับทุก Pod โดยไม่ได้ตั้งใจ (แถมแอบเมาท์ Token ลงไปให้ในโฟลเดอร์ /var/run/secrets ด้วย) แฮกเกอร์ที่เจาะแอปได้ จะขโมย Token นี้ไปลองยิง API Server กลับเพื่อยึดคลัสเตอร์
* Mitigation (วิธีแก้): เติมคำสั่ง automountServiceAccountToken: false ลงไปใน YAML เสมอ สำหรับแอปทั่วไปที่ไม่จำเป็นต้องไปยิงคำสั่งคุยกับ K8s API Server เป็นการตัดไฟแต่ต้นลมเพื่อสกัดกั้นการแฮกระดับคลัสเตอร์

ทฤษฎีและกลไกการทำงาน:
แทนที่เราจะให้ CI/CD Pipeline นำสคริปต์มารัน kubectl apply ทีละคำสั่ง (Push approach) คอนเซปต์ GitOps พลิกมุมมองโดยให้ K8s Cluster เป็นฝ่าย "ดึง (Pull)" สเตทมาจาก Git Repository โดยตรง
เครื่องมืออย่าง ArgoCD จะรันเป็น Controller ฝังอยู่ในคลัสเตอร์ และคอย Watch ดู Git Repo ตลอดเวลา หากมีการเปลี่ยนไฟล์ YAML ใน Git มันจะทำหน้าที่ Reconcile สิ่งนั้นลงคลัสเตอร์อัตโนมัติ

# การประกาศ ArgoCD Application ให้ซิงก์กับ Git Repo
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: 'https://github.com/my-org/my-k8s-config.git'
    targetRevision: HEAD
    path: k8s-manifests
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod
        

Use Case ในชีวิตจริง:
ทีมดูแลระบบมี 5 คลัสเตอร์ทั่วโลก การอัปเดตแอปต้องคอยเชื่อมต่อ VPN ทีละแห่ง เมื่อเปลี่ยนมาใช้ GitOps ทีมเพียงแค่กด Merge PR (Pull Request) ใน GitHub ไฟล์เดียว ArgoCD Agent ในทั้ง 5 คลัสเตอร์จะดึงค่าไปอัปเดตตัวเองพร้อมกัน และถ้ามีใครเผลอลบ Pod หรือแก้สเปกผิด ArgoCD จะดึงสเตทกลับคืนสภาพเดิมให้ทันทีแบบ Self-healing

ข้อควรระวังและวิธีแก้:
* Pitfall: การเก็บข้อมูล Secret (เช่น รหัสผ่าน) เป็น Plain text ลงใน Git Repo ตรงๆ ทำให้ความลับรั่วไหล
* Mitigation: ต้องใช้เครื่องมือจัดการ Secret แบบเฉพาะเจาะจง ร่วมกับ GitOps เช่น Sealed Secrets, SOPS หรือการเชื่อมต่อกับ External Secret Operator (เช่น HashiCorp Vault)