Init Container และ Sidecar Pattern ใน Kubernetes ออกแบบ Pod อย่างมืออาชีพ

ในบทความนี้เราจะศึกษา Init Containers และ Sidecar Containers ซึ่งเป็นเทคนิคขั้นสูงสำหรับออกแบบ Kubernetes Pods ที่มีความนุ่มนวลและสามารถจัดการได้ดี

พื้นฐาน: Init Containers และ Sidecar Containers

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

Init Containers คืออะไร?

Init Containers คือ container ที่ทำงานก่อน application containers เสร็จสิ้นทั้งหมด ใช้กำหนดการเตรียม environment สำหรับ application main

ลักษณะเฉพาะของ Init Containers:
– ทำงานแบบลำดับไม่ขนาน
– ต้องสิ้นสุดสำเร็จ (exit code 0) ก่อนจะเริ่ม main containers
– สามารถมีได้หลายชั้น
– ใช้ได้สำหรับ setup/initialization tasks เท่านั้น

ตัวอย่าง: เตรียม Volume Data

apiVersion: v1
kind: Pod
metadata:
name: myapp-with-init
spec:
initContainers:
– name: init-download-data
image: busybox:1.35
command: [‘sh’, ‘-c’, ‘wget -O /data/app.tar.gz https://example.com/app.tar.gz && tar -xzf /data/app.tar.gz -C /data/’]
volumeMounts:
– name: data-volume
mountPath: /data
containers:
– name: app
image: myapp:1.0
volumeMounts:
– name: data-volume
mountPath: /data
volumes:
– name: data-volume
emptyDir: {}

ในตัวอย่างนี้ init container จะดาวน์โหลดและแตกไฟล์ก่อน main application เริ่มต้น

Sidecar Pattern คืออะไร?

Sidecar Container เป็น container ที่ทำงานควบคู่กับ application container เพื่อให้บริการเสริมเช่น:
– Logging aggregation
– Monitoring/metrics collection
– Security scanning
– Network proxying
– Configuration management

ตัวอย่าง: Logging Sidecar

apiVersion: v1
kind: Pod
metadata:
name: myapp-with-sidecar
spec:
containers:
– name: app
image: myapp:1.0
ports:
– containerPort: 8080
volumeMounts:
– name: log-volume
mountPath: /var/log/app
– name: log-forwarder
image: fluent-bit:2.0
volumeMounts:
– name: log-volume
mountPath: /var/log/app
– name: fluent-bit-config
mountPath: /fluent-bit/etc/
volumes:
– name: log-volume
emptyDir: {}
– name: fluent-bit-config
configMap:
name: fluent-bit-config

ขั้นตอนการกำหนด Init Containers + Sidecars

apiVersion: apps/v1
kind: Deployment
metadata:
name: advanced-app
spec:
replicas: 3
selector:
matchLabels:
app: advanced-app
template:
metadata:
labels:
app: advanced-app
spec:
# Init Containers – ทำงานแรก
initContainers:
– name: wait-for-db
image: busybox:1.35
command: [‘sh’, ‘-c’, ‘until nc -z mydb.default.svc.cluster.local 5432; do echo waiting for db; sleep 2; done;’]
– name: db-migration
image: myapp-migration:1.0
env:
– name: DB_HOST
value: mydb.default.svc.cluster.local
– name: DB_PORT
value: “5432”
# Main Containers
containers:
– name: app
image: myapp:1.0
ports:
– containerPort: 8080
volumeMounts:
– name: shared-logs
mountPath: /var/log/app
# Sidecar Containers
– name: prometheus-exporter
image: prometheus-sidecar:latest
ports:
– containerPort: 9090
volumeMounts:
– name: shared-metrics
mountPath: /metrics
– name: log-aggregator
image: fluent-bit:2.0
volumeMounts:
– name: shared-logs
mountPath: /var/log/app
volumes:
– name: shared-logs
emptyDir: {}
– name: shared-metrics
emptyDir: {}

ลำดับการทำงาน:
1. wait-for-db init container เริ่มต้น (รอให้ database พร้อม)
2. db-migration init container เริ่มต้น (รันการ migrate database)
3. init containers สิ้นสุด
4. app container เริ่มต้น
5. prometheus-exporter และ log-aggregator sidecars เริ่มต้นและทำงานพร้อมกับ app

Usage Pattern

เมื่อใช้ Init Containers:
– Setup tasks ที่ต้องเสร็จสิ้นก่อนแอปเริ่มต้น
– Database migrations
– Downloading configuration files
– Checking dependencies

เมื่อใช้ Sidecar Containers:
– Logging/monitoring ที่ต้องทำงานตลอด
– Network proxy/mesh sidecar
– Security scanning
– Configuration reloading
– Health checks

การแชร์ Data ระหว่าง Containers

การใช้ emptyDir volumes:
apiVersion: v1
kind: Pod
metadata:
name: shared-data-pod
spec:
initContainers:
– name: generate-config
image: busybox:1.35
command: [‘sh’, ‘-c’, ‘echo “server=mydb.com” > /shared/config.txt’]
volumeMounts:
– name: shared-config
mountPath: /shared
containers:
– name: app
image: myapp:1.0
volumeMounts:
– name: shared-config
mountPath: /shared
volumes:
– name: shared-config
emptyDir: {}

ทั้ง init container และ main application container สามารถอ่านไฟล์ config.txt ได้

ข้อปฏิบัติที่ดี

1. ใช้ init containers สำหรับ setup งาน initialization เท่านั้น
2. ระบุ resource requests/limits สำหรับ init containers
3. ใช้ exit code 0 เพื่อบ่งชี้ความสำเร็จ
4. ให้ init containers มี timeout ที่เหมาะสม
5. ใช้ health checks กับ sidecars
6. ทำให้ sidecars เป็น stateless เท่าที่เป็นไปได้

apiVersion: v1
kind: Pod
metadata:
name: best-practice-pod
spec:
initContainers:
– name: init-task
image: busybox:1.35
command: [‘sh’, ‘-c’, ‘sleep 5 && echo “Init complete”‘]
resources:
requests:
memory: “64Mi”
cpu: “100m”
limits:
memory: “128Mi”
cpu: “200m”
containers:
– name: app
image: myapp:1.0
resources:
requests:
memory: “256Mi”
cpu: “100m”
limits:
memory: “512Mi”
cpu: “500m”
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
– name: sidecar
image: myapp-sidecar:1.0
resources:
requests:
memory: “128Mi”
cpu: “50m”
limits:
memory: “256Mi”
cpu: “100m”
livenessProbe:
httpGet:
path: /health
port: 9090
initialDelaySeconds: 10
periodSeconds: 10

การ Debug Init Containers

ดูลอก init containers:
kubectl logs -c
kubectl logs -c –previous

ดูสถานะ init containers:
kubectl describe pod

ในส่วน “Init Containers” จะแสดงสถานะของแต่ละ init container

ในส่วน “Containers” จะแสดงว่า main containers เก่ากว่าหรือว่ายัง

การใช้งานใน Production

ที่ ผู้ให้บริการโฮสติ้ง Cloud VPS มีการสนับสนุนสำหรับ:
– Init Containers สำหรับ setup tasks
– Sidecars สำหรับ monitoring และ logging
– Resource management สำหรับทุก container types
– Service mesh (Istio) ที่ใช้ sidecar proxies

ตัวอย่างการ Deploy บน Cloud VPS:

Cloud VPS

สรุป

Init Containers และ Sidecars เป็นเทคนิคที่มีประสิทธิภาพสำหรับ:
– แยกความกังวลระหว่าง initialization และ runtime
– เพิ่มความยืดหยุ่นและความสามารถในการบำรุงรักษา
– นำเสนอ cross-cutting concerns (logging, monitoring)
– ลดการจับคู่ระหว่าง containers

การเข้าใจและใช้งานรูปแบบเหล่านี้อย่างเหมาะสมจะทำให้ Kubernetes applications ของคุณมีความนุ่มนวลและปลอดภัยมากขึ้น