Kubernetes คืออะไร

Kubernetes (K8s) เป็น Container Orchestration Platform ที่มีความสามารถสูงสุด ใช้สำหรับจัดการ Container applications ขนาดใหญ่และซับซ้อน Kubernetes ช่วยแก้ปัญหาสำคัญหลายประการ เช่น

• การจัดการ Container หลายพันตัว บนเซิร์ฟเวอร์หลายเครื่อง
• Auto-scaling ตามปริมาณ CPU และ Memory
• Self-healing: Restart container ที่หยุดการทำงาน
• Rolling updates: Update application โดยไม่หยุดบริการ
• Load balancing ระหว่าง Pod (containers) ที่กำลังทำงาน
• Secret management สำหรับเก็บข้อมูลที่เป็นความลับ เช่น password, API keys

สถาปัตยกรรม Kubernetes: ภาพรวมทั่วไป

Kubernetes Cluster ประกอบด้วย 2 ส่วนหลัก คือ Control Plane (Master Node) และ Worker Nodes

Control Plane: สมองของ Kubernetes Cluster

Control Plane คือหัวใจของ Kubernetes Cluster ที่รับผิดชอบการตัดสินใจ ควบคุม และบ่งบอกระบบว่าควรทำอะไร ประกอบด้วยหลายคอมโพเนนต์:

1. API Server

API Server เป็นประตูหลักของ Kubernetes ทุก request จาก kubectl (command-line tool) หรือ Kubernetes client ต้องผ่าน API Server ก่อน มันทำหน้าที่:

• รับ request จากผู้ใช้ (via kubectl)
• ตรวจสอบความถูกต้องของ request
• บันทึกข้อมูลลงใน etcd (database)
• ส่งข้อมูลให้กับ controller manager และ scheduler
• ส่งการตอบกลับ (response) ให้กับ client

2. etcd: ฐานข้อมูล Key-Value ของ Kubernetes

etcd เป็นฐานข้อมูล Key-Value Distributed ที่เก็บสถานะ (state) ของ Kubernetes Cluster ทั้งหมด ข้อมูลทั้งหมด เช่น:

• ข้อมูล Pod, Deployment, Service ทั้งหมด
• Configuration ของ application
• Secrets (รหัสผ่าน, API keys)
• Status ของแต่ละ component

etcd นี่แหละที่ทำให้ Kubernetes สามารถ recover จากการ crash ได้ เพราะสถานะ (desired state) ถูกเก็บไว้อย่างปลอดภัย

3. Scheduler

Scheduler มีหน้าที่เลือก Worker Node ที่เหมาะสม เพื่อวาง Pod ลงไป Scheduler พิจารณาหลายปัจจัย:

• Resource request: Pod ต้องการ CPU และ Memory เท่าไร
• Node capacity: แต่ละ Node มี resource ว่างเท่าไร
• Affinity/Anti-affinity: ต้องการวาง Pod เข้าไปใกล้กันหรือไม่
• Taints and tolerations: Node บาง Node มี “บ่น” และ Pod บาง Pod “ยอมรับบ่น” นั้น
• Node selector: เลือก Node แบบเฉพาะเจาะจง

4. Controller Manager

Controller Manager เป็นกลุ่มตัวควบคุม (controllers) ที่ดูแลให้สถานะปัจจุบัน (current state) ตรงกับสถานะที่ต้องการ (desired state) Controllers สำคัญ ได้แก่:

• ReplicaSet Controller: ดูแลให้จำนวน Pod เสมอเท่ากับที่กำหนด ถ้า Pod ตายไปหนึ่งตัว มันจะสร้างตัวใหม่
• Deployment Controller: จัดการ Rolling update เมื่ออัปเดต application version
• Service Controller: จัดการ Load Balancer สำหรับ Service
• Node Controller: ดูแลสถานะของ Worker Node
• StatefulSet Controller: จัดการ Pod ที่ต้องการข้อมูลถาวร (stateful)

5. Cloud Controller Manager

Component นี้ทำหน้าที่ผสมผสาน Kubernetes กับ cloud provider เช่น AWS, Google Cloud, Azure เมื่อใช้บริการ Cloud VPS ของ ผู้ให้บริการโฮสติ้ง ให้สร้าง Load Balancer หรือ Persistent Volume

Worker Nodes: ผู้ปฏิบัติงาน

Worker Node คือเซิร์ฟเวอร์ที่ต้องทำงานจริง ๆ โดยรัน Pod และ Container Worker Node ประกอบด้วย 3 คอมโพเนนต์หลัก:

1. kubelet

kubelet เป็น agent ที่รันบน Worker Node แต่ละตัว มันรับหน้าที่:

• รับคำสั่งจาก API Server เพื่อเริ่มหรือหยุด Pod
• ติดต่อ Container runtime เพื่อจัดการ Container
• ตรวจสอบสถานะ Pod และรายงานกลับไปยัง API Server
• Restart Pod ที่เกิดปัญหา (self-healing)
• เรียกใช้ lifecycle hooks เช่น liveness probe, readiness probe

2. kube-proxy

kube-proxy รับหน้าที่จัดการเครือข่าย (network) บน Node:

• ตั้งค่า iptables rules เพื่อทำให้ traffic ไปถึง Pod ที่ถูกต้อง
• จัดการ load balancing ระหว่าง Pod หลายตัว
• อนุญาตให้ Pod สื่อสารกับอันอื่น ๆ บน Node อื่น
• Expose Service บน port ของ Node

3. Container Runtime

Container runtime เป็นซอฟต์แวร์ที่จริง ๆ แล้วรัน Container บน Node ตัวเลือกที่นิยม ได้แก่:

• containerd: Runtime ที่เบาและเร็ว เป็น default ของ Docker
• CRI-O: Runtime ที่ออกแบบเพื่อ Kubernetes โดยเฉพาะ
• Docker: Runtime ที่คุ้นเคยสำหรับ developer แต่หนักกว่า

1. Pod

Pod เป็นหน่วยที่เล็กที่สุดใน Kubernetes Pod มักมี Container หนึ่งตัว แต่อาจมี Container หลายตัวที่ต้องทำงานร่วมกัน (เช่น app container + logging sidecar) Container ใน Pod เดียวกัน:

• แบ่ง storage volume
• ใช้ localhost เพื่อสื่อสารกัน
• ถูกสร้างและลบพร้อม ๆ กัน

# ตัวอย่าง Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    image: nginx:latest
    ports:
    - containerPort: 80

2. ReplicaSet

ReplicaSet ควบคุมให้มีจำนวน Pod ตรงกับที่ระบุไว้ ถ้า Pod ตายไป ReplicaSet จะสร้างตัวใหม่เพื่อให้ครบจำนวน

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replica-set
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

3. Deployment

Deployment คือ object ที่ควบคุม ReplicaSet และจัดการ rolling update ส่วนใหญ่เราใช้ Deployment แล้วปล่อยให้ Deployment สร้าง ReplicaSet ให้เอง Deployment มี feature ที่ดีกว่า:

• Rolling update: Update version ใหม่ทีละ Pod เพื่อไม่หยุดบริการ
• Rollback: ถ้า version ใหม่มีปัญหา ค่อน rollback กลับไป version เก่า
• Revision history: เก็บประวัติการ update ทั้งหมด

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

4. Service

Service เป็นวิธีที่ expose Pod ไปยัง network Service มี 3 ประเภทหลัก:

• ClusterIP: Internal IP ที่ใช้สำหรับสื่อสารภายใน Cluster เท่านั้น (default)
• NodePort: Expose บน port ของ Node ทุกตัว สามารถเข้าถึงจากนอก Cluster
• LoadBalancer: ใช้ external load balancer จาก cloud provider (AWS, GCP, Azure) โดยในบริการ Cloud VPS ของ ผู้ให้บริการโฮสติ้ง สามารถใช้บริการนี้ได้

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

5. ConfigMap และ Secret

ConfigMap ใช้เก็บ configuration ที่ไม่เป็นความลับ เช่น environment variable ส่วน Secret ใช้เก็บข้อมูลที่เป็นความลับ เช่น password, API key

# ConfigMap example
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info

---
# Secret example
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=  # base64 encoded
  api-key: YWJjZGVmZ2g=

6. PersistentVolume และ PersistentVolumeClaim

PersistentVolume (PV) เป็น storage ที่อยู่ภายนอก Pod และ Node ที่ให้ข้อมูลยังคงอยู่แม้ Pod ตายไป PersistentVolumeClaim (PVC) เป็นการขอ PV จาก Pod

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

7. Namespace

Namespace เป็นวิธีการแบ่ง Kubernetes Cluster เป็น virtual clusters หลายตัว ทำให้สามารถ:

• แบ่งการใช้ resource ระหว่างทีม
• ตั้งค่า resource quota ให้แต่ละทีม
• กำหนด access control ต่างกันสำหรับแต่ละ namespace
• ใช้ชื่อ resource เดียวกัน ในแต่ละ namespace ที่ต่างกัน

# สร้าง namespace
kubectl create namespace production
kubectl create namespace staging

# ใช้ deployment ใน namespace
kubectl apply -f deployment.yaml -n production

คำสั่ง kubectl บ้านที่สำคัญ

kubectl เป็น command-line tool ที่ใช้ควบคุม Kubernetes คำสั่งที่ใช้บ่อยที่สุด:

# ดู Pod ทั้งหมด
kubectl get pods

# ดู Pod ใน namespace เฉพาะ
kubectl get pods -n production

# สร้าง resource จาก file
kubectl apply -f deployment.yaml

# ลบ resource
kubectl delete pod my-pod

# ดู log ของ Pod
kubectl logs my-pod

# เข้า Pod ด้วย interactive shell
kubectl exec -it my-pod -- /bin/bash

# ดู status ของ Deployment
kubectl describe deployment nginx-deployment

# Scale Deployment
kubectl scale deployment nginx-deployment --replicas=5

# Rollout ไป version เก่า
kubectl rollout undo deployment nginx-deployment

ว่ไฟ Component ทำงานร่วมกันอย่างไร

เมื่อผู้ใช้งาน (devops engineer) สั่งให้สร้าง Deployment ผ่าน kubectl กระบวนการจะเป็นดังนี้:

• kubectl ส่ง request ไปยัง API Server
• API Server ตรวจสอบความถูกต้อง แล้วบันทึกข้อมูล Deployment ลงใน etcd
• Deployment controller เห็นว่ามี Deployment ใหม่ จึงสร้าง ReplicaSet
• ReplicaSet controller เห็นว่าต้องมี Pod 3 ตัว จึงสร้าง Pod 3 ตัว
• Scheduler เลือก Worker Node ที่เหมาะสมสำหรับแต่ละ Pod
• kubelet บน Node รับคำสั่งจาก API Server และรัน Container
• kube-proxy ตั้งค่า network เพื่อให้ traffic ไปถึง Pod
• ผลลัพธ์คือ Deployment ที่มี 3 Pod กำลังรันบน 3 Node ต่างกัน

สรุป

สถาปัตยกรรม Kubernetes อาจดูซับซ้อน แต่เมื่อเข้าใจหลักการแล้ว มันมีเหตุผลที่สมเหตุสมผล:

• Control Plane ทำหน้าที่ประสานงานและตัดสินใจ
• Worker Node ทำงานจริง โดยรัน Pod และ Container
• Core objects เช่น Pod, Deployment, Service ทำให้เราสามารถอธิบายสิ่งที่ต้องการด้วยวิธีที่เข้าใจง่าย
• Self-healing และ auto-scaling ทำให้ application มีความเสถียรและสามารถปรับขนาดได้

สำหรับนักพัฒนาและนักดูแล system ที่ใช้บริการ Cloud VPS จาก ผู้ให้บริการโฮสติ้ง Kubernetes ถือเป็นตัวเลือกที่ยอดเยี่ยมสำหรับการรัน production application ที่ต้องการ high availability และ scalability