Kubernetes คืออะไร? สอน K8s Container Orchestration ตั้งแต่ Pod Deployment Service จนถึง Production 2026

2026-04-08 · tech · 3500 words

ในยุคที่แอปพลิเคชันสมัยใหม่ถูกพัฒนาด้วยสถาปัตยกรรม Microservices และ Container มากขึ้นเรื่อยๆ การจัดการ Container จำนวนมากด้วยมือกลายเป็นเรื่องที่เป็นไปไม่ได้ในทางปฏิบัติ Kubernetes (K8s) จึงเข้ามาแก้ปัญหานี้ในฐานะแพลตฟอร์ม Container Orchestration ที่ทรงพลังที่สุดในปัจจุบัน บทความนี้จะพาคุณเรียนรู้ Kubernetes ตั้งแต่แนวคิดพื้นฐานจนถึงการนำไปใช้งานจริงใน Production อย่างละเอียด

Kubernetes คืออะไร? ทำไมต้องใช้ Container Orchestration

Kubernetes หรือเรียกสั้นๆ ว่า K8s เป็นระบบ Open Source ที่ Google พัฒนาขึ้นมาเพื่อจัดการ Containerized Applications แบบอัตโนมัติ ครอบคลุมการ Deploy การ Scale และการจัดการ Container ทั้งหมด ชื่อ Kubernetes มาจากภาษากรีกแปลว่า "คนถือหางเสือเรือ" สื่อถึงการนำทางและควบคุม Container ทั้งหมดให้ทำงานอย่างราบรื่น

ก่อนที่จะมี Container Orchestration การ Deploy แอปพลิเคชันบน Container ต้องทำด้วยมือเป็นส่วนใหญ่ เช่น การรัน Docker Container บนเซิร์ฟเวอร์แต่ละตัว การตรวจสอบว่า Container ยังทำงานอยู่หรือไม่ การกระจาย Traffic ไปยัง Container ต่างๆ ทั้งหมดนี้ต้องใช้เวลาและแรงงานมหาศาล Kubernetes เข้ามาแก้ปัญหาเหล่านี้โดยมีความสามารถหลักดังนี้

Self-healing - เมื่อ Container หยุดทำงาน K8s จะสร้างใหม่โดยอัตโนมัติ ไม่ต้องมีคนเฝ้าดูตลอด 24 ชั่วโมง ระบบจะตรวจสอบสุขภาพของ Container ผ่าน Health Check อย่างสม่ำเสมอ และหาก Container ใดไม่ตอบสนอง จะถูก Restart หรือสร้างใหม่ทันที

Auto-scaling - K8s สามารถเพิ่มหรือลดจำนวน Container ตามปริมาณการใช้งานจริง เช่น ถ้ามีผู้ใช้เข้ามาพร้อมกันมาก ระบบจะเพิ่ม Container เพื่อรองรับ Load และเมื่อผู้ใช้ลดลง ก็จะลดจำนวนลงเพื่อประหยัดทรัพยากร การ Scaling นี้สามารถตั้งค่าได้ทั้ง Horizontal Pod Autoscaler (HPA) และ Vertical Pod Autoscaler (VPA)

Rolling Updates & Rollback - อัปเดตแอปพลิเคชันโดยไม่ต้องหยุดให้บริการ สามารถ Rollback กลับเวอร์ชันเดิมได้ทันทีหากพบปัญหา K8s จะค่อยๆ แทนที่ Pod เก่าด้วย Pod ใหม่ทีละตัว ทำให้ไม่มี Downtime

Service Discovery & Load Balancing - K8s มีระบบ DNS ภายในที่ช่วยให้ Container ค้นหากันเองได้ และกระจาย Traffic ไปยัง Container ที่พร้อมให้บริการอย่างเท่าเทียม ไม่ต้องตั้งค่า Load Balancer เอง

Secret & Configuration Management - จัดการข้อมูลลับ เช่น รหัสผ่าน API Key และ Configuration ต่างๆ โดยไม่ต้องฝังใน Container Image ทำให้ปลอดภัยและยืดหยุ่นมากขึ้น

สถาปัตยกรรมของ Kubernetes

การเข้าใจสถาปัตยกรรมของ K8s เป็นสิ่งสำคัญที่สุดก่อนที่จะเริ่มใช้งาน Kubernetes Cluster ประกอบด้วยสองส่วนหลักคือ Control Plane และ Worker Nodes

Control Plane (Master Node)

Control Plane เป็นสมองของ Cluster ทำหน้าที่ตัดสินใจและควบคุมทุกอย่างที่เกิดขึ้นภายใน Cluster ประกอบด้วยส่วนประกอบสำคัญดังนี้

API Server (kube-apiserver) เป็นจุดเชื่อมต่อหลักของ Kubernetes ทุก Component ต้องสื่อสารผ่าน API Server ไม่ว่าจะเป็นคำสั่ง kubectl การทำงานของ Scheduler หรือ Controller ทั้งหมดผ่าน RESTful API ของ API Server API Server ยังรับผิดชอบ Authentication Authorization และ Admission Control เพื่อให้มั่นใจว่าเฉพาะคำสั่งที่ได้รับอนุญาตเท่านั้นที่จะถูกประมวลผล

etcd เป็น Distributed Key-Value Store ที่เก็บข้อมูลสถานะทั้งหมดของ Cluster ไม่ว่าจะเป็นข้อมูล Pod Service ConfigMap Secret ทุกอย่างถูกเก็บไว้ใน etcd เป็น Source of Truth ของ Cluster การสำรองข้อมูล etcd จึงเป็นสิ่งที่สำคัญมากในระบบ Production เพราะหาก etcd เสียหาย จะสูญเสียข้อมูลสถานะทั้ง Cluster

Scheduler (kube-scheduler) ทำหน้าที่ตัดสินใจว่า Pod ใหม่ควรถูกสร้างบน Node ไหน โดยพิจารณาจากปัจจัยหลายอย่าง เช่น ทรัพยากรที่เหลืออยู่ Node Affinity Taints และ Tolerations รวมถึง Pod Priority และ Preemption Policy

Controller Manager (kube-controller-manager) เป็นชุดของ Controllers ที่ทำงานเป็น Control Loop คอยเฝ้าดูสถานะปัจจุบันของ Cluster และปรับให้ตรงกับสถานะที่ต้องการ (Desired State) เช่น ReplicaSet Controller จะตรวจสอบว่ามี Pod ทำงานครบตามจำนวนที่กำหนดหรือไม่ ถ้าไม่ครบก็จะสร้างเพิ่ม ถ้ามากเกินก็จะลบออก

Cloud Controller Manager ทำหน้าที่เชื่อมต่อ Kubernetes กับ Cloud Provider เช่น AWS GCP Azure เพื่อจัดการทรัพยากรบน Cloud เช่น Load Balancer Storage Volume และ Node Instance

Worker Nodes

Worker Nodes เป็นเครื่องที่รัน Container จริงๆ แต่ละ Node ประกอบด้วย

kubelet เป็น Agent ที่ทำงานบนทุก Node ทำหน้าที่รับคำสั่งจาก API Server และดูแลให้ Container ทำงานตามที่กำหนด kubelet จะตรวจสอบ Health ของ Container อย่างสม่ำเสมอ และรายงานสถานะกลับไปยัง Control Plane

kube-proxy จัดการเรื่อง Network บน Node ทำ Load Balancing ระหว่าง Pod ต่างๆ และดูแล Network Rules สำหรับ Service

Container Runtime เป็นซอฟต์แวร์ที่รัน Container จริงๆ เช่น containerd หรือ CRI-O (Docker ถูกถอดออกจาก K8s ตั้งแต่เวอร์ชัน 1.24)

Core Concepts ที่ต้องรู้

Pod

Pod เป็นหน่วยที่เล็กที่สุดที่ Kubernetes จัดการ แต่ละ Pod สามารถมี Container ได้หนึ่งตัวหรือมากกว่า (แต่ส่วนใหญ่จะมีตัวเดียว) Container ใน Pod เดียวกันจะแชร์ Network Namespace คือมี IP Address เดียวกัน และสามารถสื่อสารกันผ่าน localhost ได้ นอกจากนี้ยังแชร์ Storage Volume ร่วมกันได้อีกด้วย

Pod เป็น Ephemeral หมายความว่ามันสามารถถูกสร้างและทำลายได้ตลอดเวลา ไม่ควรพึ่งพา Pod ตัวใดตัวหนึ่งโดยเฉพาะ แต่ควรใช้ Deployment หรือ StatefulSet ในการจัดการ Pod แทน

# ตัวอย่าง Pod YAML
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

ReplicaSet

ReplicaSet ทำหน้าที่รักษาจำนวน Pod ที่กำหนดให้คงที่อยู่เสมอ เช่น ถ้ากำหนดว่าต้องมี 3 Replicas ReplicaSet จะตรวจสอบว่ามี Pod ทำงานอยู่ 3 ตัวเสมอ ถ้ามี Pod ตายไปหนึ่งตัว จะสร้างใหม่ทันที แต่ในทางปฏิบัติเราไม่ค่อยสร้าง ReplicaSet โดยตรง แต่จะใช้ Deployment แทน เพราะ Deployment สร้าง ReplicaSet ให้อัตโนมัติ และมีความสามารถเพิ่มเติมเช่น Rolling Update

Deployment

Deployment เป็น Resource ที่ใช้บ่อยที่สุดใน Kubernetes ทำหน้าที่จัดการ ReplicaSet อีกทีหนึ่ง มีความสามารถที่สำคัญคือ Rolling Update (อัปเดตทีละ Pod โดยไม่หยุดให้บริการ) และ Rollback (กลับไปเวอร์ชันก่อนหน้าได้) Deployment เป็นวิธีมาตรฐานในการ Deploy Stateless Applications บน Kubernetes

# ตัวอย่าง Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: myapp:v2.1
        ports:
        - containerPort: 8080
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: database_host
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Service

Service เป็นวิธีที่ Kubernetes ใช้ Expose แอปพลิเคชันให้เข้าถึงได้ เนื่องจาก Pod มี IP ที่เปลี่ยนแปลงได้ตลอดเวลา Service จึงทำหน้าที่เป็น Stable Endpoint ที่ไม่เปลี่ยนแปลง และกระจาย Traffic ไปยัง Pod ที่เหมาะสม Service มีหลายประเภทที่จะอธิบายในหัวข้อ Networking

Namespace

Namespace ใช้แบ่ง Cluster ออกเป็นส่วนๆ เสมือน Virtual Cluster ภายใน Cluster เดียวกัน เหมาะสำหรับแบ่งแยกระหว่างทีม Environment (dev staging prod) หรือ Project ต่างๆ Resource ใน Namespace หนึ่งจะไม่เห็น Resource ใน Namespace อื่น ยกเว้นจะกำหนดไว้ Kubernetes สร้าง Namespace เริ่มต้นมาให้ 4 ตัว คือ default kube-system kube-public และ kube-node-lease

การติดตั้ง Kubernetes

มีหลายวิธีในการติดตั้ง Kubernetes ขึ้นอยู่กับวัตถุประสงค์การใช้งาน

Minikube - สำหรับเรียนรู้และทดสอบ

Minikube เป็นเครื่องมือที่สร้าง Single-Node Kubernetes Cluster บนเครื่องของคุณ เหมาะสำหรับการเรียนรู้และทดลอง รองรับทั้ง Windows macOS และ Linux สามารถติดตั้งได้ง่ายและรวดเร็ว

# ติดตั้งและเริ่มใช้งาน Minikube
# macOS
brew install minikube

# Linux
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# เริ่มต้น Cluster
minikube start --driver=docker --cpus=4 --memory=8192

# ตรวจสอบสถานะ
minikube status
kubectl get nodes

kind (Kubernetes in Docker) - สำหรับ CI/CD

kind สร้าง Kubernetes Cluster โดยใช้ Docker Container เป็น Node เหมาะสำหรับการทดสอบใน CI/CD Pipeline เพราะเริ่มต้นเร็วและใช้ทรัพยากรน้อย สามารถสร้าง Multi-Node Cluster ได้บนเครื่องเดียว

# ติดตั้ง kind
go install sigs.k8s.io/kind@latest

# สร้าง Cluster
kind create cluster --name my-cluster

# สร้าง Multi-Node Cluster
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF

k3s - Lightweight Kubernetes

k3s พัฒนาโดย Rancher Labs เป็น Kubernetes ขนาดเบาที่ตัดบางส่วนที่ไม่จำเป็นออก เหมาะสำหรับ Edge Computing IoT หรือเครื่องที่มีทรัพยากรจำกัด ขนาดไฟล์ Binary เพียงประมาณ 100MB ติดตั้งง่ายด้วยคำสั่งเดียว

# ติดตั้ง k3s (Linux)
curl -sfL https://get.k3s.io | sh -

# ตรวจสอบ
sudo k3s kubectl get nodes

kubeadm - สำหรับ Production

kubeadm เป็นเครื่องมือ Official ของ Kubernetes สำหรับสร้าง Production-grade Cluster ให้ความยืดหยุ่นในการกำหนดค่าสูงสุด แต่ต้องจัดการ Infrastructure เอง เหมาะสำหรับองค์กรที่ต้องการควบคุมทุกอย่างเอง

# ขั้นตอนหลักของ kubeadm
# 1. ติดตั้ง Container Runtime (containerd)
# 2. ติดตั้ง kubeadm kubelet kubectl
# 3. Initialize Control Plane
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# 4. ตั้งค่า kubeconfig
mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

# 5. ติดตั้ง CNI (Calico/Flannel)
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# 6. Join Worker Nodes
kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

kubectl คำสั่งพื้นฐาน

kubectl เป็นเครื่องมือ Command Line หลักสำหรับจัดการ Kubernetes Cluster คำสั่งที่ใช้บ่อยมีดังนี้

# ดูข้อมูลทั่วไป
kubectl cluster-info                  # ข้อมูล Cluster
kubectl get nodes                     # ดู Nodes ทั้งหมด
kubectl get pods                      # ดู Pods ใน Namespace ปัจจุบัน
kubectl get pods -A                   # ดู Pods ทุก Namespace
kubectl get svc                       # ดู Services
kubectl get deployments               # ดู Deployments

# จัดการ Resources
kubectl apply -f deployment.yaml      # สร้างหรืออัปเดตจาก YAML
kubectl delete -f deployment.yaml     # ลบ Resources จาก YAML
kubectl delete pod nginx-pod          # ลบ Pod ตามชื่อ

# ดูรายละเอียด
kubectl describe pod nginx-pod        # ดูรายละเอียด Pod
kubectl describe node worker-01       # ดูรายละเอียด Node
kubectl logs pod-name                 # ดู Logs ของ Pod
kubectl logs pod-name -c container    # ดู Logs ของ Container เฉพาะ
kubectl logs -f pod-name              # ดู Logs แบบ Stream

# Debug & Troubleshoot
kubectl exec -it pod-name -- bash     # เข้าไปใน Pod
kubectl port-forward pod-name 8080:80 # Forward Port
kubectl top pods                      # ดูการใช้ทรัพยากร
kubectl get events --sort-by='.lastTimestamp'  # ดู Events

# Scale & Update
kubectl scale deployment web --replicas=5       # Scale
kubectl set image deployment/web web=myapp:v3   # อัปเดต Image
kubectl rollout status deployment/web           # ดูสถานะ Rollout
kubectl rollout undo deployment/web             # Rollback
kubectl rollout history deployment/web          # ดูประวัติ

YAML Manifest สำหรับ Kubernetes

การจัดการ Kubernetes ส่วนใหญ่ทำผ่าน YAML Manifest ซึ่งเป็นไฟล์ที่อธิบายสถานะที่ต้องการ (Desired State) ของ Resource ต่างๆ ไฟล์ YAML ทุกไฟล์จะมีโครงสร้างพื้นฐานเหมือนกันคือ apiVersion kind metadata และ spec

ConfigMap และ Secret

ConfigMap ใช้เก็บ Configuration ที่ไม่เป็นความลับ เช่น Database Host Port หรือ Feature Flags ส่วน Secret ใช้เก็บข้อมูลที่เป็นความลับ เช่น Password API Key Certificate โดย Secret จะถูก Encode ด้วย Base64 (แต่ไม่ได้ Encrypt ดังนั้นควรใช้ร่วมกับ Tools เช่น Sealed Secrets หรือ External Secrets Operator ใน Production)

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_host: "db.example.com"
  database_port: "5432"
  log_level: "info"
  app.properties: |
    server.port=8080
    spring.profiles.active=production

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

Networking ใน Kubernetes

Networking เป็นหนึ่งในหัวข้อที่สำคัญและซับซ้อนที่สุดของ Kubernetes Kubernetes กำหนดหลักการ Networking พื้นฐานว่า Pod ทุกตัวต้องสื่อสารกันได้โดยไม่ต้องผ่าน NAT และทุก Node ต้องสื่อสารกับทุก Pod ได้

Service Types

ClusterIP (Default) - สร้าง Internal IP ภายใน Cluster ใช้สำหรับการสื่อสารภายใน เช่น Frontend เรียก Backend ภายใน Cluster เดียวกัน ไม่สามารถเข้าถึงจากภายนอกได้

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

NodePort - เปิด Port บนทุก Node ให้เข้าถึง Service จากภายนอกได้ Port Range คือ 30000-32767 เหมาะสำหรับการทดสอบหรือสภาพแวดล้อมที่ไม่มี Cloud Load Balancer

LoadBalancer - สร้าง External Load Balancer โดยอัตโนมัติ (ต้องใช้กับ Cloud Provider) เหมาะสำหรับ Production บน Cloud แต่มีค่าใช้จ่ายเพิ่มเติม

Ingress

Ingress เป็น Resource ที่จัดการ External Access ไปยัง Service ภายใน Cluster โดยทำงานที่ Layer 7 (HTTP/HTTPS) สามารถทำ Path-based Routing Host-based Routing SSL Termination และอื่นๆ ได้ ต้องติดตั้ง Ingress Controller เช่น NGINX Ingress Controller Traefik หรือ HAProxy Ingress ก่อนจึงจะใช้งาน Ingress Resource ได้

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Storage ใน Kubernetes

Container เป็น Ephemeral ข้อมูลที่เก็บใน Container จะหายไปเมื่อ Container ถูกทำลาย Kubernetes แก้ปัญหานี้ด้วยระบบ Persistent Storage

PersistentVolume (PV) และ PersistentVolumeClaim (PVC)

PersistentVolume เป็น Resource ที่แสดงถึง Storage จริงๆ ใน Cluster เช่น NFS Disk บน Cloud หรือ Local Storage ส่วน PersistentVolumeClaim เป็นคำร้องขอ Storage จาก Pod ทำงานคล้ายกับ Pod ร้องขอ CPU และ Memory

# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

---
# ใช้ PVC ใน Pod
apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data-vol
      mountPath: /data
  volumes:
  - name: data-vol
    persistentVolumeClaim:
      claimName: data-pvc

StorageClass

StorageClass ใช้กำหนดประเภทของ Storage ที่ Cluster สามารถจัดหาได้ เช่น SSD HDD หรือ NFS เมื่อมี PVC ร้องขอ Storage ที่ระบุ StorageClass K8s จะสร้าง PV ให้อัตโนมัติ (Dynamic Provisioning) ทำให้ไม่ต้องสร้าง PV ด้วยมือ

Monitoring และ Observability

การ Monitor Kubernetes Cluster เป็นสิ่งจำเป็นสำหรับ Production เพื่อให้รู้ว่า Cluster และแอปพลิเคชันทำงานเป็นอย่างไร มีปัญหาอะไรหรือไม่

Prometheus + Grafana

Prometheus เป็น Monitoring System ที่ออกแบบมาสำหรับ Cloud Native Applications สามารถ Scrape Metrics จาก Kubernetes Components และ Applications ได้ เมื่อใช้ร่วมกับ Grafana จะได้ Dashboard ที่สวยงามและใช้งานง่ายสำหรับการวิเคราะห์ข้อมูล สามารถติดตั้งได้ง่ายผ่าน Helm Chart ของ kube-prometheus-stack

# ติดตั้ง Prometheus + Grafana ด้วย Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack   --namespace monitoring --create-namespace   --set grafana.adminPassword=mypassword

Lens และ k9s

Lens เป็น Kubernetes IDE ที่มี GUI สวยงาม แสดงข้อมูล Cluster ทั้งหมดในรูปแบบที่เข้าใจง่าย รวมถึง Real-time Metrics Logs และ Events เหมาะสำหรับทั้งผู้เริ่มต้นและผู้เชี่ยวชาญ

k9s เป็น Terminal-based UI สำหรับจัดการ Kubernetes ทำงานได้เร็วมาก รองรับ Keyboard Shortcuts สำหรับทุกการดำเนินการ เหมาะสำหรับ DevOps ที่ชอบทำงานบน Terminal และต้องการความรวดเร็ว มีฟีเจอร์เช่น Resource Filtering Log Viewing Port Forwarding และอื่นๆ ผ่าน Keyboard Shortcuts

Managed Kubernetes vs Self-managed

การเลือกใช้ Kubernetes มีสองแนวทางหลัก คือ Managed Kubernetes ที่ Cloud Provider ดูแลให้ กับ Self-managed ที่ต้องจัดการเองทั้งหมด

Managed Kubernetes

Amazon EKS (Elastic Kubernetes Service) - เป็น Managed K8s ของ AWS มี Integration กับ AWS Services เช่น ALB EBS EFS IAM CloudWatch ได้อย่างดี เหมาะสำหรับองค์กรที่ใช้ AWS เป็น Cloud หลัก ค่าใช้จ่าย Control Plane ประมาณ $73/เดือน บวกค่า Worker Nodes

Google GKE (Google Kubernetes Engine) - พัฒนาโดย Google ซึ่งเป็นผู้สร้าง Kubernetes ทำให้มีความ Integrate กับ K8s ได้ดีที่สุด มี Autopilot Mode ที่จัดการ Node ให้อัตโนมัติ และ Control Plane ฟรี (Standard Tier)

Azure AKS (Azure Kubernetes Service) - Managed K8s ของ Microsoft Azure มี Integration กับ Azure Services เช่น Azure Active Directory Azure Monitor Container Insights Control Plane ฟรี จ่ายแค่ค่า Worker Nodes

Self-managed

การติดตั้งและจัดการ Kubernetes เองด้วย kubeadm หรือ k3s ให้ความยืดหยุ่นสูงสุดแต่ต้องดูแลทุกอย่างเอง รวมถึง Control Plane Upgrade Security Patches และ Backup เหมาะสำหรับองค์กรที่มี Compliance Requirements เฉพาะ ต้องการควบคุมค่าใช้จ่าย หรือต้องรันบน On-premises Infrastructure

ข้อผิดพลาดที่พบบ่อย

จากประสบการณ์การใช้งาน Kubernetes ข้อผิดพลาดที่พบบ่อยมีดังนี้

ไม่กำหนด Resource Requests/Limits - หากไม่กำหนด CPU และ Memory Limits Pod อาจใช้ทรัพยากรมากเกินไปจนกระทบ Pod อื่นบน Node เดียวกัน ควรกำหนด Requests (ทรัพยากรขั้นต่ำ) และ Limits (ทรัพยากรสูงสุด) เสมอ ใน Namespace ระดับ Production ควรตั้ง LimitRange และ ResourceQuota ด้วย

ไม่ตั้งค่า Health Checks - Liveness Probe ใช้ตรวจสอบว่า Container ยังทำงานอยู่หรือไม่ ถ้าไม่ตอบสนองจะถูก Restart Readiness Probe ใช้ตรวจสอบว่า Container พร้อมรับ Traffic หรือไม่ ถ้าไม่พร้อมจะไม่ถูกส่ง Traffic มา การไม่ตั้ง Health Checks ทำให้ K8s ไม่สามารถจัดการ Container ที่มีปัญหาได้อย่างถูกต้อง

ใช้ latest Tag - ไม่ควรใช้ image tag เป็น latest ใน Production เพราะไม่สามารถระบุได้ว่ากำลังรันเวอร์ชันไหน และ Rollback ก็ทำไม่ได้ ควรใช้ Semantic Versioning หรือ Git SHA เป็น Tag เสมอ เช่น myapp:v2.1.3 หรือ myapp:abc1234

ไม่ทำ Backup etcd - etcd เก็บข้อมูลสถานะทั้งหมดของ Cluster หาก etcd เสียหายโดยไม่มี Backup จะสูญเสียทุกอย่าง ควรตั้ง Automated Backup สำหรับ etcd ใน Production Cluster เสมอ

เปิด Privilege Containers โดยไม่จำเป็น - Privileged Container มีสิทธิ์เข้าถึง Host System ทั้งหมด ซึ่งเป็นความเสี่ยงด้านความปลอดภัยอย่างมาก ควรใช้ Security Context กำหนดสิทธิ์ให้น้อยที่สุดเท่าที่จำเป็น (Principle of Least Privilege)

ไม่ใช้ Network Policies - โดย Default Pod ทุกตัวใน Cluster สามารถสื่อสารกันได้หมด ซึ่งไม่ปลอดภัย ควรใช้ Network Policies กำหนดว่า Pod ไหนสามารถสื่อสารกับ Pod ไหนได้

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

Kubernetes กับ Docker ต่างกันอย่างไร?

Docker เป็น Container Runtime ที่ใช้สร้างและรัน Container ส่วน Kubernetes เป็น Container Orchestration Platform ที่จัดการ Container จำนวนมาก Kubernetes ใช้ Docker (หรือ containerd) เป็น Container Runtime แต่มีความสามารถเพิ่มเติมมากมาย เช่น Auto-scaling Self-healing Load Balancing อ่านเพิ่มเติมเกี่ยวกับ Docker ได้ที่ Docker Container Guide

เริ่มต้นเรียน Kubernetes ควรเรียนอะไรก่อน?

ควรเริ่มจาก Linux พื้นฐาน แล้วเรียน Docker ให้เข้าใจ Container ก่อน จากนั้นค่อยเริ่มเรียน Kubernetes ด้วย Minikube นอกจากนี้ควรเข้าใจ Git Version Control ด้วย เพราะจะใช้ร่วมกับ GitOps Workflow

Kubernetes เหมาะกับทุกโปรเจกต์หรือไม่?

ไม่จำเป็น สำหรับแอปพลิเคชันขนาดเล็กที่ไม่ซับซ้อน การใช้ Docker Compose หรือ Serverless อาจเหมาะกว่า Kubernetes เหมาะกับแอปพลิเคชันที่ต้องการ Scale มีหลาย Service ต้องการ High Availability และทีมมีขนาดใหญ่พอที่จะจัดการ Cluster ได้ การตัดสินใจใช้ K8s ควรพิจารณาจากความจำเป็นจริง ไม่ใช่เพราะมันเป็นเทรนด์

Helm คืออะไร?

Helm เป็น Package Manager สำหรับ Kubernetes เหมือนกับ apt หรือ yum สำหรับ Linux ช่วยจัดการ YAML Manifests ที่ซับซ้อนโดยรวมเป็น Chart เดียว สามารถ Install Upgrade Rollback แอปพลิเคชันบน K8s ได้ง่ายขึ้น Helm Chart ยังรองรับ Template Values ทำให้ปรับแต่งค่าต่างๆ ได้โดยไม่ต้องแก้ไข YAML โดยตรง

StatefulSet ต่างจาก Deployment อย่างไร?

Deployment ใช้สำหรับ Stateless Applications เช่น Web Server API Server ส่วน StatefulSet ใช้สำหรับ Stateful Applications เช่น Database Message Queue ที่ต้องการ Stable Network Identity Ordered Deployment และ Persistent Storage ที่ผูกกับ Pod เฉพาะ

สรุป

Kubernetes เป็นเครื่องมือที่ทรงพลังสำหรับการจัดการ Container ในระดับ Production การเข้าใจสถาปัตยกรรม Core Concepts และ Best Practices จะช่วยให้คุณใช้งาน K8s ได้อย่างมีประสิทธิภาพ เริ่มต้นด้วย Minikube เรียนรู้ kubectl และ YAML Manifest จากนั้นค่อยๆ ขยายไปสู่ Managed K8s บน Cloud สิ่งสำคัญคือการปฏิบัติจริง ลองสร้าง Cluster ลอง Deploy Application ลองทำ Rolling Update และ Rollback จะทำให้เข้าใจ Kubernetes ได้ดีที่สุด