Kubernetes Manifest Generator: สร้าง YAML สำหรับ Deployment, Service, ConfigMap และ Secret

การเขียน Kubernetes manifest ด้วยตนเองเป็นงานที่ดูตรงไปตรงมา แต่รายละเอียดเล็ก ๆ อย่าง indentation, label selector, resource unit หรือโครงสร้างของ health probe สามารถทำให้การ deploy ล้มเหลวหรือทำงานไม่ตรงตามที่คาดไว้ได้ Kubernetes Manifest Generator ช่วยเปลี่ยนค่าที่กรอกผ่านหน้าจอให้เป็น YAML ที่มีโครงสร้างพร้อมใช้งาน ลดเวลาที่ต้องจำ field และลดความผิดพลาดจากการคัดลอก manifest เดิมมาแก้ไข

เครื่องมือนี้สร้างทรัพยากรที่เลือกได้ทั้ง Deployment, Service, ConfigMap และ Opaque Secret แล้วรวมเป็น multi-document YAML โดยคั่นแต่ละ resource ด้วย --- คุณจึงสามารถเตรียม manifest สำหรับ workload ขนาดเล็กหรือบริการหนึ่งชุดได้ในครั้งเดียว จากนั้นคัดลอกผลลัพธ์หรือดาวน์โหลดเป็นไฟล์ manifest.yaml เพื่อนำไปตรวจสอบและใช้งานต่อ

การประมวลผลทั้งหมดเกิดขึ้นใน browser เครื่องมือไม่ได้เชื่อมต่อ Kubernetes cluster และไม่ได้นำ manifest หรือค่า Secret ไปเก็บบน server อย่างไรก็ตาม YAML ที่สร้างขึ้นเป็นจุดเริ่มต้น ไม่ใช่การรับรองว่าพร้อม production โดยอัตโนมัติ ควร review, validate และทดสอบกับ environment ที่เหมาะสมก่อน deploy จริงเสมอ

ทำไมต้องใช้ Kubernetes Manifest Generator?

• ลดภาระการจำ syntax: เลือก resource และกรอกค่าที่จำเป็นผ่าน form แทนการจำตำแหน่งของ spec, template, containers, ports และ field ย่อยทั้งหมด
• รักษาความสัมพันธ์ของ label: Service selector เชื่อมกับ app label ของ Deployment โดยอัตโนมัติ ช่วยลดปัญหา Service มี endpoint ว่างเพราะ selector ไม่ตรงกับ Pod label
• รวมหลาย resource ในไฟล์เดียว: สร้าง Deployment, Service, ConfigMap และ Secret เป็น multi-document YAML ที่อ่านง่ายและ apply ได้ด้วยคำสั่งเดียว
• กำหนดทรัพยากรได้ชัดเจน: ตั้ง CPU และ memory ทั้ง requests และ limits เพื่อสื่อสารความต้องการของ container ให้ scheduler และระบบจัดสรรทรัพยากรทราบ
• เพิ่ม health checks ได้สะดวก: เปิดใช้ HTTP liveness probe และ readiness probe โดยไม่ต้องเขียนโครงสร้าง probe ที่ซ้อนหลายระดับเอง
• เหมาะกับการเรียนรู้และทำต้นแบบ: ผู้เริ่มต้นเห็นความสัมพันธ์ระหว่างค่าบนหน้าจอกับ YAML ที่ได้ทันที ส่วนทีมที่มีประสบการณ์ใช้สร้าง baseline ก่อนเพิ่ม policy หรือ configuration เฉพาะระบบ

คุณสมบัติสำคัญ

• Environment variables แบบ KEY=VALUE: เพิ่มค่าหลายรายการในรูปแบบที่คุ้นเคย เช่น NODE_ENV=production หรือ LOG_LEVEL=info แล้วเครื่องมือจะแปลงเป็นรายการ env ภายใน container การแยกที่เครื่องหมาย = ทำให้ควรตรวจผลลัพธ์เมื่อ value มีรูปแบบซับซ้อนหรือมีอักขระพิเศษ
• Resource configuration ที่ใช้งานได้จริง: requests บอกค่าขั้นต่ำที่ scheduler ใช้วาง Pod ส่วน limits กำหนดเพดานการใช้ทรัพยากร ตัวอย่างเช่น CPU request 250m, CPU limit 500m, memory request 256Mi และ memory limit 512Mi
• ผลลัพธ์พร้อมเข้าสู่ workflow: คุณสามารถ copy YAML ไปยัง repository เพื่อ review ผ่าน pull request หรือดาวน์โหลด manifest.yaml แล้วตรวจด้วยเครื่องมือของทีมก่อนสั่ง kubectl apply -f manifest.yaml

วิธีใช้ Kubernetes Manifest Generator

1. กำหนด Deployment ระบุชื่อ workload เช่น orders-api, จำนวน replicas, container image เช่น ghcr.io/example/orders-api:1.4.2 และ container port เช่น 8080 ควรหลีกเลี่ยง tag ที่เปลี่ยนค่าได้อย่าง latest สำหรับ production เพราะทำให้ตรวจสอบ version ที่กำลังรันได้ยาก

2. ตั้งค่า resources, environment variables และ probes กรอก CPU/memory requests และ limits ให้สอดคล้องกับข้อมูลการใช้งานจริง เพิ่ม environment variables ในรูปแบบ KEY=VALUE แล้วเปิด HTTP liveness/readiness probes หาก application มี health endpoint เช่น /health โดย path เดียวกันนี้จะถูกใช้กับ probe ทั้งสองแบบ

3. เลือก Service ที่เหมาะสม ใช้ ClusterIP เมื่อให้บริการเฉพาะภายใน cluster, NodePort เมื่อต้องเปิด port ผ่านแต่ละ node ในกรณีเฉพาะ หรือ LoadBalancer เมื่อต้องการให้ cloud provider จัด external load balancer ตรวจสอบ service port และ target ที่สัมพันธ์กับ container port แม้ selector จะถูกเชื่อมกับ Deployment app label ให้อัตโนมัติแล้วก็ตาม

4. เพิ่ม ConfigMap หรือ Secret ตามความจำเป็น ใส่ configuration ทั่วไป เช่น APP_MODE=production หรือ FEATURE_X_ENABLED=true ใน ConfigMap ส่วนข้อมูลอ่อนไหวให้ใส่ใน Opaque Secret เครื่องมือจะ base64-encode value ภายใน browser แต่ต้องเข้าใจว่า base64 เป็นเพียง encoding ไม่ใช่ encryption ผู้ที่อ่าน Secret manifest ได้สามารถ decode กลับเป็นข้อความเดิมได้

5. ตรวจสอบ คัดลอก หรือดาวน์โหลด manifest อ่าน YAML ทุก document ตรวจชื่อ, namespace ที่ต้องการ, image, ports, labels, resource values และ probe paths จากนั้น copy ไปยังไฟล์ของโครงการหรือดาวน์โหลดเป็น manifest.yaml เมื่อตรวจและ validate แล้วจึงนำไปใช้ด้วย kubectl apply -f manifest.yaml ใน context และ namespace ที่ถูกต้อง

ทำความเข้าใจแนวคิดของ Kubernetes Manifest

Kubernetes manifest คือคำอธิบาย desired state ของ object ในรูปแบบ YAML หรือ JSON แทนที่จะสั่งระบบทีละขั้นว่าต้องสร้าง container อย่างไร เราระบุว่าต้องการ Deployment จำนวนกี่ replicas ใช้ image ใด เปิด port อะไร และมีข้อกำหนดด้านสุขภาพหรือทรัพยากรแบบไหน จากนั้น Kubernetes controller จะพยายามทำให้สถานะจริงเข้าใกล้ desired state อย่างต่อเนื่อง

เอกสารแต่ละชุดประกอบด้วย field หลัก ได้แก่ apiVersion, kind, metadata และ spec โดย kind ระบุชนิดของทรัพยากร ส่วน metadata.name เป็นชื่อที่ใช้ระบุ object ภายใน namespace สำหรับ Deployment นั้น spec.selector.matchLabels ต้องตรงกับ spec.template.metadata.labels หากสองส่วนนี้ไม่ตรงกัน Deployment จะไม่สามารถจัดการ Pod ตามที่ตั้งใจไว้

Deployment ไม่ได้เปิด network endpoint ที่คงที่ให้ผู้ใช้โดยตรง เพราะ Pod สามารถถูกสร้างใหม่และเปลี่ยน IP ได้ Service จึงทำหน้าที่เป็นจุดเข้าถึงที่เสถียรและค้นหา Pod ผ่าน selector ตัว generator ใช้ชื่อ application เชื่อม app label ระหว่าง Deployment กับ Service ลดโอกาสที่สอง resource จะอ้างอิงกันผิด แต่ถ้าคุณแก้ YAML ภายหลัง ต้องรักษาความสอดคล้องของ label ด้วยตนเอง

multi-document YAML ช่วยเก็บ object หลายชนิดในไฟล์เดียว โดยใช้ --- เป็นตัวคั่น ตัวอย่างโครงสร้างย่ออาจเป็นดังนี้:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
---
apiVersion: v1
kind: Service
metadata:
  name: orders-api
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: orders-api-config

เมื่อสั่ง kubectl apply -f manifest.yaml คำสั่งจะส่งแต่ละ document ไปยัง Kubernetes API ที่กำหนดโดย kubeconfig ปัจจุบัน การมี YAML พร้อมใช้จึงไม่ได้หมายความว่าเครื่องมือ generator เข้าถึง cluster หรือ apply ให้เอง คุณยังเป็นผู้ควบคุม cluster context, namespace, สิทธิ์ และจังหวะ deployment ทั้งหมด

requests และ limits มีผลต่อ reliability โดยตรง CPU request 250m หมายถึงหนึ่งในสี่ของ CPU core ขณะที่ memory request 256Mi คือหน่วย mebibyte ที่ scheduler ใช้พิจารณาพื้นที่บน node หากใช้ memory เกิน limit container อาจถูกยุติด้วย OOM ส่วนการแตะ CPU limit มักทำให้เกิด throttling การตั้งค่าที่ต่ำเกินไปจึงอาจสร้างปัญหาไม่ต่างจากการไม่ตั้งค่าเลย ควรอ้างอิง metrics และ load test แทนการเดา

health probes ก็มีหน้าที่ต่างกัน liveness probe ตอบคำถามว่า container ค้างและควรถูก restart หรือไม่ ส่วน readiness probe ตอบว่า Pod พร้อมรับ request ผ่าน Service หรือยัง หากนำ endpoint เดียวกันไปตรวจ dependency ภายนอกทุกชนิด liveness อาจ restart application ซ้ำเมื่อระบบภายนอกล่ม จึงควรออกแบบ endpoint และค่า timing ให้สอดคล้องกับพฤติกรรมจริงของ application

ConfigMap เหมาะกับข้อมูล configuration ที่ไม่ลับ ขณะที่ Secret ใช้แยกข้อมูลอ่อนไหวออกจาก Pod spec โดยตรง แต่ค่าใน Kubernetes Secret มักปรากฏเป็น base64 เนื่องจาก YAML ต้องเก็บข้อมูลได้อย่างปลอดภัยต่อรูปแบบ ไม่ใช่เพราะถูกเข้ารหัส ผู้ที่มีสิทธิ์อ่าน Secret สามารถ decode ได้ทันที สำหรับ production ควรพิจารณา encryption at rest, RBAC ที่จำกัดสิทธิ์ และระบบจัดการ Secret ภายนอกตามข้อกำหนดขององค์กร

กรณีใช้งานจริง

สร้าง API ภายในสำหรับ development environment

สมมติทีมมี image ghcr.io/acme/catalog-api:2.3.0 ที่ฟัง port 8080 สามารถสร้าง Deployment ชื่อ catalog-api จำนวน 2 replicas และ Service แบบ ClusterIP ที่ port 80 เพื่อให้ workload อื่นเรียกผ่าน DNS ภายใน cluster ได้ ตั้ง request เริ่มต้นเป็น CPU 200m และ memory 256Mi พร้อม limit CPU 500m และ memory 512Mi แล้วเพิ่ม LOG_LEVEL=debug สำหรับ environment นี้

หลังดาวน์โหลด manifest ให้ทีมเพิ่ม metadata.namespace: development ตามมาตรฐาน repository และตรวจว่า Service ส่ง traffic ไปยัง container port 8080 ถูกต้อง ก่อน apply ไปยัง cluster สำหรับทดสอบ การใช้ ClusterIP ช่วยไม่เปิด API ออกสู่ภายนอกโดยไม่จำเป็น

เตรียม web service ที่เข้าถึงจากภายนอก

สำหรับหน้าเว็บหรือ public API บน managed Kubernetes ให้เลือก Service แบบ LoadBalancer และกำหนด container image แบบ immutable tag หรือ digest จากนั้นตั้ง probe path ร่วม เช่น /health โดยตรวจว่า endpoint นี้เหมาะกับทั้งการ restart container ที่ค้างและการตัดสินใจว่า Pod พร้อมรับ traffic หรือไม่

manifest ที่ได้ยังอาจต้องเพิ่ม Ingress, TLS, annotations ของ cloud provider, PodDisruptionBudget หรือ autoscaling ตาม architecture จริง ตัว generator ช่วยสร้างแกนหลักของ Deployment และ Service แต่ไม่ควรถูกตีความว่าแทนที่การออกแบบ production topology

แยก configuration ออกจาก container image

บริการ billing-worker อาจต้องใช้ค่าทั่วไป เช่น APP_MODE=production, QUEUE_NAME=billing และ RETRY_LIMIT=5 ข้อมูลเหล่านี้เหมาะกับ ConfigMap เพราะเปลี่ยนได้โดยไม่ต้อง build image ใหม่ ส่วน DATABASE_PASSWORD หรือ token ควรอยู่ใน Secret และไม่ควร commit plaintext ลง Git

หลังสร้าง ConfigMap และ Secret ต้องตรวจว่า Deployment อ้างอิงค่าดังกล่าวตามรูปแบบที่ application ต้องการ เพราะ generator รองรับการสร้าง resource และ environment variables แต่ระบบ production อาจต้องใช้ envFrom, configMapKeyRef, secretKeyRef หรือ volume mount เพิ่มเติม อย่าคัดลอกค่าลับจริงลง issue, chat หรือ pull request แม้ค่าจะถูก base64 แล้วก็ตาม

สร้าง baseline สำหรับ GitOps

ทีมที่ใช้ GitOps สามารถสร้าง manifest.yaml เป็น baseline แล้วนำ YAML เข้า repository ให้ผ่าน code review, policy checks และ validation pipeline ก่อน merge ตัวอย่างเช่นตรวจ schema, บังคับให้มี resource limits, ห้ามใช้ privileged container และกำหนด image registry ที่อนุญาต

วิธีนี้เหมาะกับการเริ่มต้นเร็วโดยยังคงกระบวนการควบคุมการเปลี่ยนแปลง เครื่องมือไม่ push ไปยัง Git และไม่ส่งข้อมูลไป cluster ผู้ใช้เป็นผู้ตัดสินใจว่าจะจัดไฟล์แยกตาม resource, ใช้ Kustomize/Helm ต่อ หรือคงเป็น multi-document manifest ตามขนาดของระบบ

แนวทางปฏิบัติที่ดี

• ใช้ชื่อและ label ที่สม่ำเสมอ: ตั้งชื่อตาม convention ของทีม และตรวจว่า selector ทุกจุดตรงกับ Pod labels โดยเฉพาะหลังแก้ YAML ที่ generator สร้างแล้ว
• ตรึง version ของ image: ใช้ semantic version, commit SHA หรือ image digest แทน latest เพื่อให้ rollback, audit และเปรียบเทียบ environment ได้ชัดเจน
• ตั้ง resources จากข้อมูลจริง: เริ่มจาก metrics ของ workload และ load test ปรับ requests/limits ตามพฤติกรรมจริง พร้อมติดตาม OOM, CPU throttling และ scheduling failures
• ออกแบบ probes อย่างระมัดระวัง: แยกความหมายของ liveness กับ readiness ให้ชัด ตั้ง path, port, delay และ threshold ให้เหมาะกับเวลา startup และ dependency ของ application
• ปกป้อง Secret มากกว่า base64: อย่าถือว่า base64 ปลอดภัยเหมือน encryption จำกัด RBAC, เปิด encryption at rest และหลีกเลี่ยงการ commit Secret จริงลง source control
• ตรวจสอบก่อน production ทุกครั้ง: ใช้ schema validation, kubectl apply --dry-run=client -f manifest.yaml หรือเครื่องมือ policy ของทีม ตรวจ diff และทดลองใน non-production environment ก่อน apply จริง

เริ่มสร้าง Kubernetes YAML ที่ตรวจสอบและนำไปใช้ต่อได้

เมื่อคุณต้องการ baseline ที่อ่านง่ายสำหรับ Deployment, Service, ConfigMap และ Secret ลองเปิด Kubernetes Manifest Generator เลือกเฉพาะ resource ที่ต้องการ แล้วกำหนด image, ports, resources, environment variables และ probes ผ่านหน้าจอ คุณจะได้ multi-document YAML ที่พร้อมนำเข้าสู่ขั้นตอน review, validation และ version control โดยไม่ต้องเริ่มจากไฟล์ว่าง

หลังดาวน์โหลด manifest.yaml อย่าลืมตรวจ context, namespace, security policy และค่าที่เฉพาะกับ infrastructure ของคุณ เมื่อทุกอย่างผ่านการตรวจสอบแล้วจึงใช้ kubectl apply -f manifest.yaml เพื่อ deploy อย่างมั่นใจและตรวจสอบย้อนกลับได้

เครื่องมือที่เกี่ยวข้องที่คุณอาจชอบ:

• Docker Compose to Kubernetes Converter
• Docker Compose Generator
• YAML Formatter

ขอให้การสร้างและดูแล Kubernetes manifest ของคุณเป็นระบบ ปลอดภัย และพร้อมใช้งานในทุก environment!