setup kubernetes production cluster

บทนำ: ความสำคัญของการตั้งค่า Kubernetes Production Cluster

ในยุคที่องค์กรต่างๆ หันมาใช้ Containerization และ Microservices Architecture กันอย่างแพร่หลาย Kubernetes ได้กลายเป็นมาตรฐานเด facto สำหรับการจัดการ Container Orchestration อย่างไรก็ตาม การตั้งค่า Kubernetes Cluster เพื่อใช้งานใน Production จริงนั้นมีความซับซ้อนและต้องคำนึงถึงปัจจัยหลายประการที่แตกต่างจากการตั้งค่าใน Development หรือ Staging Environment อย่างสิ้นเชิง

บทความนี้จะนำเสนอแนวทางปฏิบัติที่ดีที่สุด (Best Practices) สำหรับการตั้งค่า Kubernetes Production Cluster อย่างครอบคลุม ตั้งแต่การวางแผนสถาปัตยกรรม การเลือกใช้ Infrastructure Components การกำหนด Security Policies ไปจนถึงการ Monitoring และ Disaster Recovery ซึ่งเป็นสิ่งที่ทีม DevOps และ Platform Engineers จำเป็นต้องเข้าใจอย่างถ่องแท้

การตั้งค่า Production Cluster ที่ไม่ถูกต้องอาจนำไปสู่ปัญหาด้าน Performance, Security Vulnerabilities, และ Downtime ที่ส่งผลกระทบต่อธุรกิจโดยตรง ดังนั้น การทำความเข้าใจในรายละเอียดทุกขั้นตอนจึงเป็นสิ่งสำคัญอย่างยิ่ง

1. การวางแผนสถาปัตยกรรมและ High Availability (HA)

1.1 การออกแบบ Control Plane ที่มีความยืดหยุ่น

หัวใจสำคัญของ Kubernetes Production Cluster คือ Control Plane ซึ่งประกอบด้วย etcd, kube-apiserver, kube-controller-manager, และ kube-scheduler สำหรับ Production Environment จำเป็นต้องมี Control Plane อย่างน้อย 3 โหนด (Multi-Master) เพื่อให้สามารถทนต่อความเสียหายได้ (Fault Tolerance) โดยใช้หลักการ Quorum ของ etcd

ข้อควรพิจารณาในการออกแบบ Control Plane:

• Etcd Cluster: ควรใช้奇数จำนวนโหนด (3, 5, หรือ 7) เพื่อป้องกัน Split-brain scenario
• API Server Load Balancing: ใช้ Load Balancer (เช่น HAProxy, Nginx, หรือ Cloud LB) เพื่อกระจาย Traffic ไปยัง API Servers หลายตัว
• Network Latency: โหนด Control Plane ควรอยู่ใน Availability Zone เดียวกันหรือมี Latency ต่ำกว่า 10ms ระหว่างกัน
• Resource Allocation: Control Plane Nodes ควรมี CPU และ Memory ที่เพียงพอ โดยทั่วไปแนะนำ 4 vCPU และ 16GB RAM ต่อโหนด สำหรับ Cluster ขนาดกลาง

1.2 Worker Node Sizing และ Scaling Strategy

Worker Nodes คือส่วนที่รัน Workload จริง การเลือกขนาดและจำนวน Worker Nodes ต้องพิจารณาจากลักษณะ Application และ Resource Requirements

สำหรับ Scaling Strategy ควรใช้ Cluster Autoscaler ร่วมกับ Horizontal Pod Autoscaler (HPA) เพื่อปรับขนาดทั้ง Node และ Pod โดยอัตโนมัติตามความต้องการของระบบ

1.3 Network Architecture ที่เหมาะสม

Kubernetes ไม่ได้จัดการ Network Layer ให้โดยตรง แต่ต้องเลือก CNI (Container Network Interface) Plugin ที่เหมาะสม สำหรับ Production Cluster แนะนำ:

• Calico: รองรับ Network Policies ที่ซับซ้อน, Performance ดี, เหมาะกับ On-premise
• Cilium: ใช้ eBPF, Performance สูงมาก, รองรับ Service Mesh Integration
• Flannel: ตั้งค่าง่าย แต่ไม่รองรับ Network Policies

นอกจากนี้ ควรพิจารณาการใช้ MetalLB สำหรับ On-premise Load Balancing หรือใช้ Cloud Native Load Balancer (เช่น AWS NLB, GCP GLB) สำหรับ Environment บน Cloud

# ตัวอย่างการติดตั้ง Calico ด้วย Helm
helm repo add projectcalico https://docs.projectcalico.org/charts
helm repo update
helm install calico projectcalico/tigera-operator \
  --namespace tigera-operator \
  --create-namespace \
  --set installation.kubernetesProvider=onprem \
  --set installation.calicoNetwork.bgp=enabled

2. Security Hardening สำหรับ Production Cluster

2.1 RBAC (Role-Based Access Control) Configuration

การรักษาความปลอดภัยใน Kubernetes เริ่มต้นที่การกำหนดสิทธิ์การเข้าถึงอย่างถูกต้อง ควรใช้หลักการ Least Privilege โดยสร้าง Roles และ ClusterRoles ที่เฉพาะเจาะจง ไม่ควรใช้ Service Account ที่มีสิทธิ์ admin โดยเด็ดขาด

# ตัวอย่าง RBAC Configuration สำหรับ CI/CD Pipeline
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: ci-deployer
rules:
- apiGroups: ["apps", "extensions"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: ci-deployer-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ci-deployer
subjects:
- kind: ServiceAccount
  name: ci-robot
  namespace: cicd

2.2 Network Policies และ Pod Security Standards

การเปิดให้ Pod ทุกตัวติดต่อกันได้ (Default Allow) เป็นความเสี่ยงใหญ่ ควรใช้ NetworkPolicy เพื่อจำกัด Traffic ระหว่าง Pods และ Namespaces

นอกจากนี้ ควรใช้ Pod Security Admission (PSA) หรือ Kyverno เพื่อบังคับใช้ Security Policies เช่น:

• ห้ามรัน Container ด้วย Privileged mode
• ห้าม Mount Host Path
• จำกัด Linux Capabilities
• กำหนด Read-only Root Filesystem

# ตัวอย่าง NetworkPolicy ที่จำกัด Traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

2.3 Secrets Management

Kubernetes Secrets ถูกเก็บเป็น Base64 เท่านั้น ซึ่งไม่ปลอดภัยเพียงพอสำหรับ Production ควรใช้ External Secrets Management Tools เช่น:

• HashiCorp Vault + Vault Agent Injector
• External Secrets Operator (AWS Secrets Manager, GCP Secret Manager)
• Sealed Secrets สำหรับ GitOps Workflow

3. Cluster และ Application Monitoring

3.1 การตั้งค่า Monitoring Stack

Production Cluster จำเป็นต้องมี Monitoring ที่ครอบคลุมทั้ง Cluster Level และ Application Level โดย Stack ที่นิยมใช้คือ Prometheus + Grafana ร่วมกับ kube-prometheus-stack (Helm Chart)

สิ่งที่ต้อง Monitor:

• Cluster Level: CPU/Memory Usage ของ Nodes, API Server Latency, etcd Disk Sync Time, Pod Restarts
• Application Level: Request Rate, Error Rate, Latency (RED Metrics), Resource Usage per Pod
• Control Plane: etcd Leader Changes, Scheduler Queue Depth, Controller Manager Work Queue

3.2 Logging Strategy

Centralized Logging เป็นสิ่งจำเป็นสำหรับ Troubleshooting และ Security Audit ควรใช้ Stack ดังนี้:

3.3 Alerting และ Incident Response

การมี Alert ที่ดีจะช่วยให้ทีมสามารถตอบสนองต่อปัญหาได้ทันเวลา ควรกำหนด Alert Rules สำหรับ:

• Critical: Node Not Ready > 5 นาที, API Server Down, etcd Unhealthy
• Warning: Pod Restart > 3 ครั้งต่อชั่วโมง, Disk Usage > 80%, Memory Pressure
• Info: Deployment Rollout ล้มเหลว, Certificate ใกล้หมดอายุ

เครื่องมือที่แนะนำ: Alertmanager (ส่วนหนึ่งของ Prometheus) ร่วมกับ PagerDuty, Opsgenie, หรือ Slack Integration

4. Disaster Recovery และ Backup Strategy

4.1 การ Backup etcd

etcd คือหัวใจของ Kubernetes Cluster หาก etcd เสียหาย Cluster จะไม่สามารถทำงานได้ ควรทำ Backup etcd อย่างสม่ำเสมอ:

• Snapshot etcd ทุก 1-2 ชั่วโมง (สำหรับ Production)
• เก็บ Snapshot ไว้ใน Remote Storage ที่ปลอดภัย (S3, GCS, หรือ NFS)
• ทดสอบ Restore Process อย่างน้อยเดือนละครั้ง

# ตัวอย่าง Script Backup etcd ด้วย etcdctl
#!/bin/bash
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# อัปโหลดไปยัง S3
aws s3 cp /backup/etcd-snapshot-*.db s3://my-bucket/etcd-backups/

4.2 Velero สำหรับ Application Backup

นอกจากการ Backup etcd แล้ว ควร Backup Application Data ด้วย Velero (เดิมชื่อ Heptio Ark) ซึ่งสามารถ Backup และ Restore ทั้ง Kubernetes Resources และ Persistent Volume ได้

ขั้นตอนการติดตั้ง Velero:

1. ติดตั้ง Velero CLI บน Management Machine
2. สร้าง S3 Bucket สำหรับเก็บ Backup
3. ติดตั้ง Velero Server ใน Cluster ด้วย Helm
4. กำหนด Schedule Backup

4.3 Multi-Cluster Strategy สำหรับ High Availability

สำหรับองค์กรที่ต้องการความพร้อมใช้งานสูงสุด ควรพิจารณาใช้ Multi-Cluster Architecture โดยมี Cluster หลักและ Cluster สำรองใน Region หรือ Cloud Provider ที่แตกต่างกัน เครื่องมือที่ช่วยจัดการ Multi-Cluster ได้แก่:

• Karmada: Open-source Multi-Cluster Orchestrator
• Rancher: รองรับ Multi-Cluster Management
• Google Anthos: Enterprise Multi-Cloud Solution

5. การจัดการ Resources และ Cost Optimization

5.1 Resource Requests/Limits และ Quality of Service (QoS)

การกำหนด Resource Requests และ Limits อย่างถูกต้องเป็นพื้นฐานสำคัญของ Production Cluster โดย Pods จะถูกจัดลำดับ QoS ดังนี้:

• Guaranteed: Requests == Limits (สำคัญที่สุด)
• Burstable: Requests < Limits (ทั่วไป)
• BestEffort: ไม่ได้กำหนด Requests/Limits (เสี่ยงถูก Evict)

ข้อแนะนำ: ควรกำหนด Requests ให้ครอบคลุม Baseline Usage และ Limits ให้สูงกว่า Peak Usage ประมาณ 20-30% เพื่อป้องกัน OOM Killer

5.2 Cluster Autoscaler และ Node Pool Design

การใช้ Cluster Autoscaler ช่วยลดต้นทุนโดยการปรับขนาด Cluster ตามความต้องการ แต่ต้องออกแบบ Node Pool อย่างเหมาะสม:

• แยก Node Pool สำหรับ不同类型的 Workload (เช่น Spot Instances สำหรับ Stateless, On-demand สำหรับ Stateful)
• ใช้ Spot/Preemptible Instances สำหรับ Non-critical Workloads เพื่อประหยัดค่าใช้จ่าย 60-80%
• กำหนด Pod Disruption Budgets (PDBs) เพื่อป้องกันการหยุดชะงักระหว่างการปรับขนาด

5.3 Cost Monitoring และ FinOps

เครื่องมือสำหรับติดตามค่าใช้จ่าย Kubernetes:

• Kubecost: แสดงค่าใช้จ่ายต่อ Namespace, Deployment, Pod
• Kubevious: วิเคราะห์ Resource Waste
• Cloud Provider Tools: AWS Cost Explorer, GCP Cost Management

แนวทางปฏิบัติ FinOps สำหรับ Kubernetes:

1. กำหนด Resource Quota สำหรับแต่ละ Team/Namespace
2. ใช้ HPA และ VPA (Vertical Pod Autoscaler) เพื่อปรับขนาดอัตโนมัติ
3. ลบ Unused Resources (Stale PVCs, Orphaned Load Balancers)
4. ใช้ Node Affinity และ Taints/Tolerations เพื่อจัดวาง Pods อย่างมีประสิทธิภาพ

6. Production-Ready Deployment Strategies

6.1 GitOps Workflow ด้วย ArgoCD หรือ Flux

การจัดการ Deployment ใน Production ควรใช้ GitOps Principles เพื่อให้มั่นใจว่า Cluster State ตรงกับ Git Repository เสมอ เครื่องมือยอดนิยม:

• ArgoCD: มี UI สวยงาม, รองรับ Multi-Cluster, Sync Waves
• Flux: ทำงานกับ Git Repository โดยตรง, รองรับ Kustomize และ Helm

ข้อดีของ GitOps:

• ประวัติการเปลี่ยนแปลงทั้งหมดถูกบันทึกใน Git
• สามารถ Rollback ได้ง่าย
• ลด Human Error จากการ Manual Deploy
• รองรับ Code Review และ Approval Process

6.2 Canary Deployment และ Blue-Green Deployment

เพื่อลดความเสี่ยงในการ Deploy ควรใช้ Progressive Delivery Strategies:

• Canary Deployment: ปล่อย Traffic ส่วนน้อยไปยัง Version ใหม่ก่อน แล้วค่อยๆ เพิ่ม
• Blue-Green Deployment: มีสอง Environment พร้อมกัน สลับ Traffic เมื่อพร้อม

เครื่องมือที่สนับสนุน: Argo Rollouts, Flagger, Istio (Service Mesh)

# ตัวอย่าง Argo Rollout สำหรับ Canary Deployment
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2.0.0
        ports:
        - containerPort: 8080

6.3 Health Checks และ Readiness Probes

การกำหนด Health Checks ที่ถูกต้องช่วยให้ Kubernetes จัดการ Traffic ได้อย่างมีประสิทธิภาพ:

• Liveness Probe: ตรวจสอบว่า Container ยังทำงานอยู่ (หากล้มเหลวจะ Restart)
• Readiness Probe: ตรวจสอบว่า Pod พร้อมรับ Traffic (หากล้มเหลวจะตัดออกจาก Service)
• Startup Probe: สำหรับ Application ที่ใช้เวลา Start นาน (ช่วยป้องกัน Liveness Probe ทำงานผิดพลาด)

ข้อควรระวัง: อย่ากำหนด Timeout และ Failure Threshold ต่ำเกินไป เพราะอาจทำให้เกิด Restart Loop โดยไม่จำเป็น

7. Case Study: การตั้งค่า Production Cluster สำหรับ E-Commerce Platform

7.1 สถาปัตยกรรมที่เลือกใช้

บริษัท E-Commerce แห่งหนึ่งต้องการย้ายระบบจาก Monolithic ไปสู่ Microservices บน Kubernetes โดยมีข้อกำหนด:

• รองรับ Traffic สูงถึง 100,000 Request/วินาทีในช่วง Sale
• ต้องมี Uptime 99.99%
• รองรับ Multi-Region สำหรับ Disaster Recovery

สถาปัตยกรรมที่เลือก:

• Cloud: AWS (us-east-1 และ eu-west-1)
• Cluster: 3 Master Nodes ต่อ Region, Worker Nodes ใช้ Mixed Instance Types (On-demand + Spot)
• Service Mesh: Istio สำหรับ Traffic Management และ Security
• Monitoring: Prometheus + Grafana + Loki
• CI/CD: GitLab CI + ArgoCD
• Backup: Velero + etcd Snapshot ทุก 1 ชั่วโมง

7.2 ผลลัพธ์และ Lessons Learned

• ลด Downtime: จากเดิม 10 ชั่วโมง/ปี เหลือ 0.5 ชั่วโมง/ปี
• เพิ่มความเร็วในการ Deploy: จาก 1 ครั้ง/สัปดาห์ เป็น 20+ ครั้ง/วัน
• ประหยัดค่าใช้จ่าย: 30% จากการใช้ Spot Instances และ Autoscaling

บทเรียนที่ได้:

• การทดสอบ Chaos Engineering (เช่น Chaos Mesh) ช่วยค้นหาจุดอ่อนก่อนเกิดเหตุจริง
• การตั้งค่า Resource Limits ผิดพลาดทำให้เกิด OOM Kill หลายครั้งในเดือนแรก
• ควรมี Runbook สำหรับทุก Scenario ที่เป็นไปได้

Summary

การตั้งค่า Kubernetes Production Cluster ที่มีประสิทธิภาพและปลอดภัยนั้นต้องอาศัยการวางแผนอย่างรอบคอบในหลายมิติ ตั้งแต่การออกแบบสถาปัตยกรรมที่รองรับ High Availability การรักษาความปลอดภัยด้วย RBAC และ Network Policies การ Monitoring และ Alerting ที่ครอบคลุม ไปจนถึงการมี Disaster Recovery Plan ที่พร้อมใช้งาน

สิ่งที่สำคัญที่สุดคือการเข้าใจว่า Kubernetes Production Cluster ไม่ใช่สิ่งที่ตั้งค่าเพียงครั้งเดียวแล้วจบ แต่ต้องมีการปรับปรุงและปรับแต่งอย่างต่อเนื่องตามความต้องการของธุรกิจและเทคโนโลยีที่เปลี่ยนแปลงไป การลงทุนใน Automation, Testing, และ Documentation จะช่วยลดความเสี่ยงและเพิ่มความมั่นใจในการทำงานกับ Production Cluster ได้อย่างมาก

สำหรับองค์กรที่กำลังเริ่มต้นเส้นทาง Kubernetes ขอแนะนำให้เริ่มจาก Cluster ขนาดเล็กก่อน ค่อยๆ เพิ่มความซับซ้อน และที่สำคัญคือการมีทีมที่มีความรู้ความเข้าใจอย่างแท้จริง เพราะ Kubernetes เป็นเครื่องมือที่ทรงพลัง แต่ก็มาพร้อมกับความซับซ้อนที่ต้องจัดการอย่างเหมาะสม