วิธีย้ายแอปพลิเคชันจาก Docker Compose ไปใช้ Kubernetes ด้วย Kustomize อย่างปลอดภัย

Overview — Overview

การย้ายแอปพลิเคชันจาก Docker Compose ไปยัง Kubernetes ไม่ใช่เรื่องยาก ถ้าจัดระเบียบไฟล์และตั้งค่าให้เป็นระบบ วิธีนี้ช่วยเพิ่มความทนทานต่อข้อผิดพลาดและทำให้การขยายตัว (scaling) ง่ายขึ้น Kustomize เป็นเครื่องมือจัดการคอนฟิกของ Kubernetes ที่ไม่ต้องเขียนสคริปต์ซับซ้อน

**Tip: ก่อนเริ่มขั้นตอนใด ๆ ควรสำรองไฟล์ `docker‑compose.yml` และบันทึกเวอร์ชันที่ทำงานได้อยู่ในระบบควบคุมเวอร์ชัน (Git) เพื่อให้สามารถย้อนกลับได้เมื่อต้องการ

เตรียมพร้อมก่อนย้าย — Prerequisites

ตรวจสอบว่าเครื่องของคุณมี Kubernetes cluster ที่เข้าถึงได้และ `kubectl` ตั้งค่าเรียบร้อยแล้ว รวมถึงติดตั้ง `kustomize` (เวอร์ชัน 4.x ขึ้นไป) เพื่อใช้สร้าง overlay อย่างเป็นระบบ

• **Docker Compose: มีไฟล์ `docker‑compose.yml` ทำงานสมบูรณ์
• **Kubernetes cluster: สามารถสร้าง namespace และ Deploy ได้
• **เครื่องมือ: `kubectl`, `kustomize`, Git (สำหรับ version control)

แปลง Docker Compose เป็น Manifest ของ Kubernetes — Compose K8s Manifests

ใช้เครื่องมืออย่าง `kompose` หรือแปลงด้วยตนเองเพื่อให้ได้ไฟล์ YAML ของ Deployment, Service, ConfigMap ฯลฯ ควรตรวจสอบว่าทุก service มีพอร์ตที่สอดคล้องกัน

• **ขั้นตอนที่ 1: ติดตั้ง `kompose` (`brew install kompose` หรือดาวน์โหลดจาก GitHub)
• **ขั้นตอนที่ 2: รันคำสั่ง `kompose convert -f docker-compose.yml` จะได้ไฟล์ `.yaml` หลายไฟล์ในโฟลเดอร์ปัจจุบัน
• **ขั้นตอนที่ 3: ตรวจสอบและปรับแก้ Manifest เช่น เพิ่ม `resources.limits`, ปรับ `imagePullPolicy` ให้เป็น `IfNotPresent` หรือ `Always` ตามความต้องการ

**สำคัญ: อย่าลืมเปลี่ยนค่า `restart: always` ของ Docker Compose ให้เป็น `restartPolicy: Always` ใน Deployment เพื่อให้พฤติกรรมเทียบเคียงกัน

สร้าง Overlay ด้วย Kustomize — Add Kustomize Overlay

Kustomize ช่วยจัดการหลายสภาพแวดล้อม (dev, staging, prod) โดยไม่ต้องคัดลอกไฟล์ Manifest ซ้ำ ทำให้การอัปเดตเป็นศูนย์กลางและปลอดภัย

โครงสร้างโฟลเดอร์ที่แนะนำ

``` k8s/ ├─ base/ │ ├─ deployment.yaml │ ├─ service.yaml │ └─ kustomization.yaml └─ overlays/ ├─ dev/ │ ├─ kustomization.yaml │ └─ configmap-dev.yaml └─ prod/ ├─ kustomization.yaml └─ configmap-prod.yaml ```

สร้างไฟล์ `kustomization.yaml` ใน `base/`

• **resources: ระบุ Manifest ทั้งหมดจากขั้นตอนแปลง
• **commonLabels: เพิ่ม label เช่น `app: my‑service` เพื่อให้จัดการง่ายขึ้น
• **namespace: กำหนด namespace เริ่มต้น (เช่น `my-app`)

สร้าง Overlay สำหรับสภาพแวดล้อม

ในแต่ละ overlay ให้กำหนด `patchesStrategicMerge` หรือ `configMapGenerator` เพื่อเปลี่ยนค่าเฉพาะ เช่น ตัวแปร environment, replica จำนวน

• **dev overlay: ใช้ `replicas: 1`, เปิด Debug logs
• **prod overlay: เพิ่ม `replicas: 3`, ตั้ง resource limits สูงกว่า

ปรับใช้อย่างปลอดภัย — Deploy Safely

ใช้แนวทาง Blue‑Green หรือ Canary Deployments เพื่อลดความเสี่ยงของการหยุดทำงานในขณะย้ายจาก Docker Compose ไปยัง Kubernetes

• **ขั้นตอนที่ 1: สร้าง namespace ใหม่ (เช่น `my-app-new`) แล้วใช้ `kustomize build overlays/dev | kubectl apply -f -` เพื่อ Deploy เวอร์ชันแรก
• **ขั้นตอนที่ 2: ตรวจสอบว่า Pods ทั้งหมดอยู่ในสถานะ `Running` และ Service ให้ตอบสนองตามคาด
• **ขั้นตอนที่ 3: ปรับ DNS หรือ Ingress ให้ชี้ไปยัง namespace ใหม่โดยค่อย ๆ เพิ่ม traffic (Canary) หรือสลับทั้งหมดในคราวเดียว (Blue‑Green)

**Tip: ใช้ `kubectl rollout status deployment/<name>` เพื่อตรวจสอบความสำเร็จของการอัปเดตก่อนทำขั้นตอนต่อไป

เปรียบเทียบ Docker Compose Kustomize — Comparison Table

ข้อควรระวังทั่วไป — Common Pitfalls

• อย่าลืมตั้งค่า `imagePullPolicy` ให้เหมาะสม หากใช้ private registry จำเป็นต้องสร้าง Secret ประเภท `docker-registry` ก่อน Deploy
• ตรวจสอบว่า Service ชนิด `ClusterIP`, `NodePort` หรือ `LoadBalancer` ตรงกับความต้องการของแอปพลิเคชัน มิฉะนั้น traffic อาจไม่ถึง Pods

**สำคัญ: การลืมตั้งค่า `readinessProbe` ทำให้ Service ส่ง traffic ไปยัง Pod ที่ยังไม่ได้พร้อมทำงาน ส่งผลให้เกิด error spikes

สรุป — Summary

การย้ายจาก Docker Compose ไป Kubernetes ด้วย Kustomize เป็นกระบวนการที่ช่วยเพิ่มความเสถียรและจัดการสภาพแวดล้อมได้ดีขึ้น เพียงทำตามขั้นตอนที่วางโครงสร้างไฟล์ให้เป็นระบบ ปรับใช้ overlay ตาม env แล้ว Deploy อย่างระมัดระวัง

• สำรวจ Docker Compose ที่ใช้งานอยู่และบันทึกเวอร์ชัน
• แปลง ด้วย `kompose` หรือเขียน Manifest เองอย่างละเอียด
• จัดการ คอนฟิกด้วย Kustomize เพื่อให้มี Base + Overlay ชัดเจน
• ทดสอบ บน namespace แยกก่อนสลับ traffic จริง
• ตรวจสอบ readiness/liveness probes, resource limits, และ Secret อย่างครบถ้วน

ทำตามขั้นตอนเหล่านี้ จะช่วยให้การย้ายแอปพลิเคชันเป็นไปอย่างปลอดภัยและพร้อมรองรับการขยายตัวในอนาคต.