Kubernetes YAML Validator: ตรวจสอบ Manifest ก่อน kubectl apply ทุกครั้ง

ใครที่ดูแล Kubernetes มาสักระยะคงคุ้นเคยกับฉากที่ manifest หน้าตาเรียบร้อยดีใน editor แต่พอสั่ง kubectl apply กลับเจอ error แบบที่ไม่น่าจะเกิดขึ้น เหตุผลคือ YAML เป็นภาษาที่ละเอียดอ่อนมาก ทั้งเรื่อง indentation, field ที่จำเป็นของแต่ละ kind และความสอดคล้องระหว่าง selector กับ labels ล้วนเป็นจุดที่คนผิดพลาดกันบ่อยที่สุด และปัญหาเหล่านี้มักไม่มีสัญญาณเตือนจนกระทั่ง deployment เริ่มมีปัญหาจริง

Kubernetes YAML Validator ถูกออกแบบมาเพื่อปิดช่องว่างตรงจุดนี้โดยเฉพาะ เพียงวาง manifest ลงในเครื่องมือ ระบบจะตรวจสอบเทียบกับกฎ apiVersion/kind ที่มีในตัว จับทั้ง field ที่จำเป็นแต่ขาดหาย, metadata block ที่ผิดรูปแบบ เช่น labels หรือ selector ที่ไม่สอดคล้องกัน และ indentation ที่เลื่อนผิดตำแหน่ง พร้อมรายงาน diagnostics แยกตามบรรทัด ทำให้รู้ทันทีว่าต้องกลับไปแก้บรรทัดไหน แทนที่จะไล่หาจากข้อความ error กำกวม ๆ

ที่สำคัญคือทุกอย่างทำงานในเบราว์เซอร์ทั้งหมด ไม่ต้องเชื่อมต่อ cluster ไม่ต้องสมัครสมาชิก และ manifest ของคุณไม่ถูกส่งออกจากเครื่อง ไม่ว่าจะเป็นการเขียน Deployment ตัวแรกในชีวิต หรือการรีวิว manifest ของเพื่อนร่วมทีมก่อน release การตรวจสอบเพียงไม่กี่วินาทีช่วยประหยัดเวลาได้มาก บทความนี้จะพาไปดูว่าเครื่องมือนี้ทำงานอย่างไร ข้อผิดพลาดแบบไหนที่จับได้ และวิธีทำให้การ validate เป็นนิสัยในงานประจำวัน

ทำไมต้องใช้ Kubernetes YAML Validator?

• จับ error ก่อน kubectl apply — จุดที่ถูกที่สุดในการแก้ manifest คือก่อนที่มันจะไปถึง API server การตรวจสอบใช้เวลาไม่กี่วินาที แต่การตามแก้ rollout ที่พังกลับใช้เวลานานกว่านั้นมาก
• Diagnostics แยกตามบรรทัด — แทนที่จะได้ error message กำกวมจาก parser คุณจะได้เลขบรรทัดที่ชัดเจน พร้อมคำอธิบายว่า field ไหนขาดหรืออะไรถูกวางผิดที่
• กฎแยกตามชนิด resource — เครื่องมือใช้กฎในตัวที่จับคู่กับ apiVersion และ kind ที่ประกาศไว้ Deployment ถูกตรวจด้วยกฎของ Deployment ส่วน Service ก็ถูกตรวจด้วยกฎของ Service
• ตรวจความสอดคล้องของ selector กับ labels — นี่คือความพังแบบเงียบ ๆ ที่พบบ่อยที่สุด คือ manifest apply ผ่านสบาย ๆ แต่ traffic ไม่ยอมวิ่งเข้า pod เครื่องมือจะจับความไม่ตรงกันนี้ได้ตั้งแต่ต้น
• ทำงานในเบราว์เซอร์ล้วน ๆ — ไม่มีการอัปโหลดใด ๆ จึงตรวจ manifest ภายในองค์กรที่มีชื่อจริง ชื่อ image จริง และ environment จริงได้อย่างปลอดภัย
• เร็วกว่า dry-run สำหรับเช็กโครงสร้าง — เป็นทางเลือกของ kubectl apply --dry-run ที่ไม่ต้องมี cluster ไม่ต้องมี kubeconfig และไม่ต้องรอ API round-trip

ฟีเจอร์หลัก

รายละเอียดที่ควรรู้เพิ่มเติมมีดังนี้

• ตรวจเชิงโครงสร้าง ไม่ใช่แค่ไวยากรณ์ — parser ทั่วไปจะยอมรับโครงสร้างที่ไม่มีความหมาย แต่เครื่องมือนี้เช็กว่า field ภายใต้ spec นั้นสมเหตุสมผลกับ kind ที่ประกาศไว้จริงหรือไม่
• จุดเด่นคือการเทียบ selector กับ labels — เครื่องมือเทียบ selector block กับ labels ของ pod template และเตือนเมื่อทั้งสองฝั่งไม่มีทางตรงกันได้ ซึ่งเป็นสาเหตุอันดับต้น ๆ ที่ Deployment สร้าง pod ได้แต่ Service กลับหา pod ไม่เจอ
• ตรวจสิ่งที่ใช้จริง — วาง manifest แบบเดียวกับที่เก็บไว้ใน repo แล้วตรวจของจริง ไม่ใช่ฉบับที่ลดทอนจนเพี้ยน

วิธีใช้งาน Kubernetes YAML Validator

1. วาง manifest — เปิด Kubernetes YAML Validator แล้ววาง YAML ที่กำลังจะ apply ไม่ว่าจะเป็น Deployment, Service หรือ ConfigMap ตามที่งานต้องใช้
2. ดูชนิด resource ที่ตรวจจับได้ — เครื่องมืออ่าน apiVersion และ kind จาก manifest แล้วใช้กฎในตัวที่ตรงกับ resource นั้น ถ้าทั้งสอง field ขาดหายหรือสะกดผิด นั่นคือ diagnostic แรกที่จะเห็น
3. อ่านรายการ diagnostics — ทุกปัญหาจะถูกระบุพร้อมเลขบรรทัดและคำอธิบายสั้น ๆ ว่าเป็น field ที่ขาด, metadata block ที่ผิดรูปแบบ หรือ indentation ที่เลื่อนตำแหน่ง
4. แก้บรรทัดที่ถูกชี้ — กลับไปแก้ไฟล์ต้นทางทีละจุด และอย่าลืมส่ายตาดูบรรทัดข้างเคียงด้วย เพราะปัญหา indentation มักกระทบบรรทัดรอบ ๆ ไปด้วยกัน
5. ตรวจซ้ำ — รันการตรวจสอบใหม่หลังแก้ทุกครั้ง จนกว่าแผง diagnostics จะว่างเปล่า การวนแก้สองสามรอบในเครื่องมือยังดีกว่า rollout ที่ล้มเหลวเสมอ

ข้อผิดพลาดใน Manifest ที่ทุกคนมักทำ

การจับคู่ apiVersion กับ kind ทุก object ใน Kubernetes ต้องประกาศทั้งสอง field และทั้งคู่จับคู่กันได้ไม่อิสระ Deployment อยู่กับ apps/v1, Ingress ย้ายมาอยู่ที่ networking.k8s.io/v1 ส่วน Service อยู่ใน v1 แบบ core ถ้าจับ kind ผิดคู่กับ apiVersion ผิด API server จะปฏิเสธ manifest ทันทีโดยไม่สนใจ spec ของคุณเลย เครื่องมือที่มีกฎการจับคู่เหล่านี้ในตัวจะจับความผิดพลาดได้ทันที ซึ่งสำคัญขึ้นเรื่อย ๆ หลังจาก resource กลุ่ม extensions/v1beta1 เก่าถูกเลิกใช้ไปนานแล้ว

ความไม่ตรงกันระหว่าง selector กับ labels spec.selector.matchLabels ของ Deployment ต้องเป็นเซตย่อยของ labels ใน pod template ถ้าเปลี่ยน label ใน template ตอน refactor แต่ลืมเปลี่ยน selector ตาม Deployment จะอัปเดตไม่ได้ หรือแย่กว่านั้น Service จะเลือก pod ไม่เจอแล้ว traffic หายไปแบบเงียบ ๆ จุดนี้อันตรายที่สุดเพราะบางกรณี apply ผ่านอย่างสวยงาม แต่ความผิดพลาดกลับแสดงตัวทีหลังใน production

field ที่จำเป็นของแต่ละ kind แต่ละ kind มีขั้นต่ำของตัวเอง Deployment ต้องมี containers พร้อม image และ template ที่ถูกต้อง Service ต้องมี ports และ selector จึงจะมีประโยชน์ ส่วน ConfigMap และ Secret ต้องมี data หรือ binaryData ไม่งั้นก็เป็นแค่เปลือกเปล่าที่ไม่ทำอะไรเลย เวลาลอก manifest จากบทเรียนแล้วค่อย ๆ ลดทอนให้เหลือน้อย มักเกิดกรณีลบ field ที่จำเป็นหลุดไปพร้อมค่าตัวอย่างโดยไม่รู้ตัว

indentation ใต้ spec YAML ใช้ indentation เป็นตัวกำหนดโครงสร้าง เหลื่อมไปสองช่องว่างใต้ block ที่ซ้อนกันลึก ๆ อย่าง spec.template.spec.containers อาจเปลี่ยน list ให้กลายเป็น map หรือรวมสอง field เข้าด้วยกันเป็น key ประหลาด ๆ ที่ไม่มีใครรู้จัก editor ส่วนใหญ่ไม่เตือน เพราะ YAML ยัง valid อยู่ แค่ความหมายไม่ตรงกับที่ตั้งใจไว้ diagnostics แยกบรรทัดจึงเป็นสิ่งเดียวที่ทำให้ปัญหากลุ่มนี้หาเจอได้

ทำไม validation จึงชนะ dry-run ในเรื่องความเร็ว kubectl apply --dry-run=server ละเอียดดีแต่ต้องมี cluster ที่เข้าถึงได้ ต้องมี credential ที่ valid และต้องรอ round trip ทุกครั้งที่เช็ก ส่วนความผิดพลาดเชิงโครงสร้าง ซึ่งเป็นสาเหตุหลักของ apply ที่ล้มเหลว เครื่องมือในเบราว์เซอร์จับได้ในไม่กี่มิลลิวินาที โดยไม่ต้องมี kubeconfig และไม่ต้องสลับ context เก็บ dry-run ไว้สำหรับเรื่อง policy และ admission แล้วใช้ validation แบบทันทีสำหรับเรื่องโครงสร้างทั้งหมด

ตัวอย่างการใช้งานจริง

เช็กก่อน apply ในงานประจำวัน

ก่อนสั่ง kubectl apply ทุกครั้ง ให้วาง manifest ที่เพิ่งแก้ไขลงใน validator ก่อน ใช้เวลาสิบวินาที แต่จับ typo, field ที่ขาดหาย และ selector ที่เลื่อนได้ก่อนใคร ทีมที่ทำสิ่งนี้เป็นนิสัยจะไม่ปล่อยให้ apply เป็นขั้นตอนตรวจสอบแรกอีกต่อไป แต่เปลี่ยนให้มันเป็นขั้นตอนสุดท้ายแทน ซึ่งเป็นตำแหน่งที่เหมาะสมกว่ามาก

ใช้สอนโครงสร้าง YAML ให้คนใหม่ในทีม

ไม่มีอะไรสอนกายวิภาคของ manifest ได้เร็วไปกว่า feedback แบบทันที ให้วิศวกรใหม่เขียน Deployment จากศูนย์ ตรวจสอบ อ่าน diagnostics แล้วแก้ตามที่ถูกชี้ ข้อความ error แต่ละอันคือบทเรียนเล็ก ๆ ว่าทำไม metadata, selector และ spec ต้องสอดคล้องกัน ซึ่งจำได้นานกว่าการท่องเอกสารอ้างอิงเป็นไหน

Debug manifest ที่ถูกปฏิเสธ

เมื่อ API server ปฏิเสธ manifest พร้อมข้อความสั้น ๆ อย่าง error validating data ให้เอาไฟล์มาวางใน validator ทันที รายงานแยกบรรทัดมักเผยปัญหาจริง ไม่ว่าจะเป็น field ที่อยู่ผิด block, metadata.name ที่หายไป หรือ indentation ที่เลื่อนตอน copy-paste โดยใช้เวลาน้อยกว่าการไปค้นหน้าเอกสารที่ถูกต้องอีกด้วย

ตรวจสอบ config ก่อนเข้า CI

ตรวจ manifest แบบ standalone ก่อนเอาไปผูกกับ pipeline เสมอ และใช้เครื่องมือนี้เป็น sanity check ของ config ที่ generate ขึ้นได้ด้วย ถ้าระบบ templating หรือสคริปต์แทนค่าเป็นตัวผลิต YAML ออกมา ให้เอาผลลัพธ์มาตรวจหนึ่งรอบเพื่อยืนยันว่าโครงสร้างรอดมาได้ครบ สำหรับงานที่เป็น Helm อยู่แล้ว ให้ใช้คู่กับการ lint chart อย่างเดียวกัน

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

• ตรวจ manifest ทุกไฟล์ก่อน apply — ทำให้เป็นกล้ามเนื้อ วาง เช็ก แล้วค่อย apply ต้นทุนคือไม่กี่วินาที แต่ deployment ที่พังอาจแพงเป็นชั่วโมง
• รักษา selector ให้ตรงกับ labels เสมอ — ถือว่า selector.matchLabels กับ labels ของ template เป็นคู่ที่ต้องขยับพร้อมกัน ถ้าแก้ฝั่งหนึ่งต้องแก้อีกฝั่ง แล้วให้ validator ยืนยันผลให้
• ใช้ indentation แบบเดียวกันทั้งไฟล์ — เลือกสองช่องว่าง ห้ามใช้ tab และห้ามผสมกัน ความสม่ำเสมอป้องกัน bug การซ้อนกันที่ตาเปล่ามองไม่เห็นได้ดีที่สุด
• เก็บ manifest ไว้ใน version control — ใส่ YAML ไว้ใน git เคียงข้างโค้ดที่มัน deploy manifest ที่ผ่านการรีวิวและย้อนกลับได้ บวกกับการ validate คือวิธีรักษาความถูกต้องในระยะยาว
• ตรวจซ้ำหลังแก้ทุกครั้ง ไม่ใช่แค่ครั้งแรก — manifest ที่พังหลายไฟล์เคย valid มาก่อนในช่วงหนึ่งของ session ให้รัน validator ใหม่หลังทุกการแก้ไข ไม่ว่าจะเล็กแค่ไหน
• เริ่มจากตัวอย่างที่ผ่านการตรวจแล้ว — เวลาต้องเขียน kind ใหม่ที่ไม่เคยใช้ ให้เริ่มจาก manifest ที่เคยผ่าน validation แทนการเขียนจากความจำเพียงลำพัง

ครั้งต่อไปที่กำลังจะสั่ง kubectl apply กับ manifest ที่ยังไม่ได้เช็ก ลองให้เวลาสิบวินาทีกับ Kubernetes YAML Validator ก่อน วาง manifest อ่าน diagnostics แยกบรรทัด แก้จุดที่ถูกชี้ แล้ว ship อย่างมั่นใจ ทั้งหมดทำงานในเบราว์เซอร์และใช้ได้ฟรี

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

• Helm Lint Checker — ตรวจสอบ Helm chart ก่อน render เป็น manifest
• Helm Values Validator — ตรวจไฟล์ values ก่อน templating
• YAML Formatter — จัดระเบียบ indentation และรูปแบบของไฟล์ YAML

ขอให้ทุกการ deploy ราบรื่นทั้งหมด!

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

ถ: manifest ของฉันถูกส่งขึ้นเซิร์ฟเวอร์หรือไม่? ตอบ: ไม่ การตรวจสอบทำงานในเบราว์เซอร์ทั้งหมด จึงตรวจ manifest ที่มีชื่อภายในองค์กร ชื่อ image หรือ environment จริงได้อย่างปลอดภัย เพราะข้อมูลไม่ออกจากเครื่องของคุณเลย

ถ: เครื่องมือนี้แทน kubectl apply --dry-run ได้จริงหรือไม่? ตอบ: สำหรับความผิดพลาดเชิงโครงสร้าง เป็นทางเลือกที่เร็วกว่าและไม่ต้องมี cluster ส่วน dry-run แบบ server-side ยังมีค่าสำหรับเรื่อง admission control และ policy จึงควรใช้ทั้งคู่ร่วมกันในจุดที่เหมาะสม

ถ: รองรับ resource kind แบบไหนบ้าง? ตอบ: เครื่องมือตรวจเทียบกับกฎ apiVersion/kind ในตัว ครอบคลุม kind ที่ใช้บ่อยอย่าง Deployment, Service และ ConfigMap ถ้า kind ไม่รู้จักหรือจับคู่กับ apiVersion ผิด ปัญหานั้นจะถูกรายงานเป็น diagnostic ให้ทันทีเช่นกัน

ถ: ตรวจไฟล์ YAML แบบหลาย document พร้อมกันได้หรือไม่? ตอบ: ได้ วางไฟล์ทั้งหมดได้เลย และรายงาน diagnostics จะชี้ไปที่บรรทัดที่มีปัญหาเฉพาะเจาะจง รวมถึงปัญหา indentation ที่คร่อมมากกว่าหนึ่ง document ด้วย