Helm Values Validator: ตรวจ values.yaml ให้ถูกต้องก่อน helm install

ทีมที่ deploy ด้วย Helm เกือบทุกทีมเคยเจอความล้มเหลวแบบเดียวกัน มี pull request แก้ค่าใน values.yaml เพียงจุดเดียว เช่น replica count, port หรือ image tag แล้ว CI ผ่านเพราะ syntax ของ YAML ถูกต้อง แต่พอ helm install render manifest ออกมาเป็น replicas: two rollout ก็พังกลางทางทันที

Helm มีคำตอบในตัวอยู่แล้ว นั่นคือ values.schema.json ตั้งแต่ Helm 3 เป็นต้นมา chart สามารถแนบ JSON Schema ที่บอกว่า values ต้องหน้าตาเป็นอย่างไร — key ใดจำเป็น, type ใด, ค่าใดอนุญาต แต่ปัญหาคือเรามักพบ schema violation ตอน install บน cluster ใน pipeline ซึ่งเป็นจังหวะที่ feedback ช้าที่สุด

Helm Values Validator ย้ายการตรวจสอบนี้ไปไว้ที่จุดเร็วที่สุด เพียงวาง values.yaml และ values.schema.json ลงในเบราว์เซอร์ คุณจะได้รายงาน error แยกตาม key ทันที ทั้ง type ที่ผิด, required field ที่หายไป และ enum ที่ไม่อนุญาต โดยรองรับ JSON Schema draft-07 อย่างเต็มรูปแบบ ทุกอย่างทำงานฝั่ง client จึงไม่มีเหตุผลที่จะไม่ตรวจก่อน commit

ทำไมต้องใช้ Helm Values Validator?

• เจอปัญหาเร็ว ไม่ต้องรอ rollout พัง — schema violation ที่จับได้ตอนกำลังแก้โค้ดคือการแก้ไม่กี่สิบวินาที แต่ถ้าไปโผล่ตอน rollout ค้างคือเรื่อง incident และ rollback
• error ระบุ path ชัดเจน — ทุกปัญหาถูกรายงานที่ตำแหน่งเป๊ะ เช่น service.port ทำให้เข้าไปแก้ key ที่ผิดได้ทันทีโดยไม่ต้องไล่ diff ไฟล์ YAML สองไฟล์ด้วยตา
• รองรับ draft-07 เต็มรูปแบบ — เครื่องมือ implements keyword ชุด draft-07 ที่ Helm ใช้จริง สิ่งที่ผ่านที่นี่คือสิ่งที่ Helm จะยอมรับ
• เป็นความลับ 100% ฝั่ง client — ไฟล์ values มักมี hostname, internal endpoint และบางครั้งคือ secret ทุกอย่างเกิดขึ้นในเบราว์เซอร์ ไม่มีการอัปโหลดใด ๆ
• ใช้กับ chart ใดก็ได้ — ไม่ต้องติดตั้ง ไม่ต้องแก้ chart เอา values.schema.json ของ chart ไหนก็มา validate override ได้ รวมถึง chart บุคคลที่สาม
• feedback loop ที่ไวมาก — แก้ค่า รันใหม่ เห็น error ถัดไป การทำ values ให้ตรง schema กลายเป็นกิจวัตร ไม่ใช่ด่านที่หวาดกลัวตอน deploy

ฟีเจอร์หลัก

error ทั้งหมดถูกรายงานพร้อมกันในรอบเดียว และเพราะ YAML ถูก parse ก่อน กรณี syntax ผิดจริง ๆ จะถูกรายงานเป็น parse error แยกชัดเจนจาก schema violation

วิธีใช้งาน

1. เปิดเครื่องมือ — เข้าหน้า Helm Values Validator ไม่ต้องติดตั้ง ไม่ต้องสมัครบัญชี
2. วาง values.yaml — วางไฟล์ values ทั้งไฟล์ หรือเฉพาะส่วน override ที่กำลังจะ commit ลงใน editor ฝั่ง values
3. วาง values.schema.json — เอา schema จาก chart ของคุณ หรือจาก upstream chart ที่ใช้งาน วางลง editor ฝั่ง schema
4. กดรัน validation — เครื่องมือ parse เอกสารทั้งสองและตรวจ values กับ schema ในรอบเดียว
5. แก้ตาม path แล้วรันใหม่ — ทุก error จะบอก key path, กฎที่ถูกละเมิด และค่าที่พบ รันซ้ำจนรายงานสะอาดแล้วค่อย commit

values.schema.json คืออะไร อธิบายแบบเข้าใจง่าย

ไฟล์ values.schema.json วางอยู่ข้าง values.yaml ใน directory ของ chart มันคือ contract แบบ machine-readable ที่ประกาศว่า values ที่ถูกต้องหน้าตาเป็นอย่างไร และ Helm จะอ่านอัตโนมัติและปฏิเสธ render template ถ้า values ไม่ตรง — ลองนึกว่ามันคือ type declaration แต่ใช้กับไฟล์ configuration

keyword ชุด draft-07 ที่ทำงานหนักที่สุดมีไม่กี่ตัว:

• type — จำกัด value เป็น object, string, integer, number, boolean หรือ array ตัวเดียวกันนี้ก็ป้องกันปัญหาคลาสสิก string กับ integer ปนกันแล้ว
• required — ระบุ key ที่ต้องมีใน object ถ้าขาด key ใดถือเป็น error ก่อน render เสมอ
• enum — จำกัด value เป็นชุดตัวเลือกที่กำหนด เหมาะกับ log level, pull policy หรือ protocol
• minimum / maximum — กำหนดขอบเขตตัวเลข เช่น port 99999 ถูกปฏิเสธทันที
• pattern — ใช้ regular expression กับ string มีประโยชน์กับ image tag และ hostname

เครื่องมือรายงาน error 4 กลุ่ม โดยทุก error จะนำหน้าด้วย path ของ key ที่ผิด ทำให้ข้อความชี้ตรงไปที่บรรทัดที่ต้องแก้: type (type ผิด), required (key ที่จำเป็นหายไป), enum (ค่าไม่อยู่ในชุดที่อนุญาต) และ path (ปัญหาเชิงโครงสร้างที่รายงานพร้อมตำแหน่งเต็ม)

ตัวอย่างสั้น ๆ 3 ชิ้นที่เข้ากัน — เริ่มจาก values.yaml ที่มีปัญหาเล็กน้อย:

replicaCount: two
image:
  repository: nginx
  tag: 1.25
service:
  type: ClusterIP
logLevel: verbose

ต่อด้วย schema ที่ไฟล์นี้ต้องผ่าน:

{
  "type": "object",
  "required": ["replicaCount", "service"],
  "properties": {
    "replicaCount": { "type": "integer", "minimum": 1 },
    "service": { "type": "object", "required": ["port"] },
    "logLevel": { "enum": ["debug", "info", "warn", "error"] }
  }
}

และรายงานที่ validator สร้างให้ — 3 ปัญหา แต่ละอันผูกกับ path:

TYPE     replicaCount   expected integer, found string
REQUIRED service.port   required key is missing
ENUM     logLevel       must be one of: debug, info, warn, error

สามบรรทัด สามตำแหน่งที่ชัดเจน ไม่ต้องเดาว่าต้องแก้อะไร — สิ่งที่เคยเป็นงานสืบสวนกลายเป็น checklist สั้น ๆ

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

ตรวจก่อน deploy ใน CI

เพิ่ม step validation ก่อน helm upgrade ใน pipeline การ lint จับ syntax ของ YAML และ helm template จับ error ฝั่ง template แต่มีเพียง schema validation เท่านั้นที่จับความผิดพลาดเชิงความหมายของ config และ error จะโผล่ในไม่กี่วินาทีพร้อม message ที่อ่านเข้าใจ

เอกสารประกอบ chart สำหรับผู้ดูแล chart

schema คือ README ที่ซื่อสัตย์ที่สุดของ chart การเผยแพร่ values.schema.json บอกผู้ใช้ว่ามี key อะไร, key ใดจำเป็น และรูปแบบใดอนุญาต ผู้ใช้ยังตรวจ override ของตัวเองได้ก่อนเปิด issue ด้วย

ชุด values หลาย environment

environment ต่าง ๆ มักคลาดเคลื่อนจากกัน: key ที่เพิ่มใน staging ไม่เคยไปถึง production หรือ override ฝั่ง prod ใช้ type ผิด การตรวจทุกไฟล์ values กับ schema เดียวกันเปลี่ยนปัญหา drift ให้เป็นการตรวจเชิงกล

อัปเกรด chart ผ่านการเปลี่ยน schema แบบ breaking

เมื่อ chart เวอร์ชัน major เปลี่ยนชื่อ key หรือลดชุด enum schema จะเปลี่ยนก่อนเสมอ ตรวจไฟล์ values เดิมกับ schema ใหม่ก่อนอัปเกรด แล้วคุณจะได้รายการ migration ที่ต้องทำครบในรอบเดียว

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

• แนบ schema ไปกับทุก chart ที่ดูแล — การไม่มี values.schema.json คือ configuration ที่ไม่มีเอกสารและไม่เคยถูกตรวจ schema แบบมินิมัลก็คุ้มแล้วตั้งแต่ครั้งแรกที่มันหยุด deploy ที่พัง
• ตรวจทุก environment ไม่ใช่แค่ครั้งเดียว — รันทุกไฟล์ values กับ schema ไฟล์ที่คุณข้ามคือไฟล์ที่ทำ release พัง
• ใช้ required เป็นเอกสาร — การระบุ key ที่จำเป็นบังคับให้คุณตัดสินใจว่า chart ต้องการอะไรจริง ๆ และสื่อสารสิ่งนั้นต่อผู้ใช้ทุกคน
• version schema ไปพร้อม chart — schema ที่เก่าและยังรับ key ที่ template ไม่อ่านแล้ว แย่กว่าไม่มี schema เสียอีก
• เข้มงวดแต่ใช้งานจริงได้ — จำกัดเฉพาะ key ที่พลาดแล้วเจ็บ เช่น type, enum, ขอบเขตตัวเลข แต่อย่าใช้ pattern ที่แคบจนผู้ใช้เลิกสนใจ validator
• ทำให้เป็น merge gate — วินัยส่วนบุคคลไม่ scale แต่ pipeline step ทำได้

พร้อมตรวจ values ของคุณหรือยัง?

เปิด Helm Values Validator วาง values.yaml และ values.schema.json แล้วดู error ทุกกลุ่ม ทั้ง type, required, enum และ path ในรอบเดียว — ก่อน helm install จะแตะ cluster ของคุณ ทำงานในเบราว์เซอร์ทั้งหมด

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

• JSON Schema Faker — สร้าง sample data สมจริงจาก JSON Schema
• YAML Formatter — จัด indentation ของไฟล์ values ให้เรียบร้อย
• Docker Compose to Kubernetes Converter — แปลงไฟล์ Compose เป็น Kubernetes manifest

ตรวจ values ให้เป็นนิสัยตั้งแต่ก่อน deploy แล้วตัวคุณในเวร on-call จะขอบคุณตัวเอง

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

ถ: ต้องแก้ chart ก่อนใช้เครื่องมือนี้ไหม?

ตอบ: ไม่ต้อง validator ทำงานจากเอกสารสองไฟล์ที่คุณวางเท่านั้น ลอก values.schema.json จาก chart ใดก็ได้มาตรวจ override ของคุณโดยไม่ต้องแตะ chart เลย

ถ: เครื่องมือรองรับ JSON Schema draft ไหน?

ตอบ: ชุด keyword draft-07 ซึ่งเป็น dialect ที่ Helm ใช้กับ values.schema.json keyword อย่าง type, required, enum, minimum, maximum และ pattern ถูกประเมินแบบเดียวกับที่ Helm ประเมินตอน install

ถ: ไฟล์ values ของฉันถูกอัปโหลดไปไหนหรือเปล่า?

ตอบ: ไม่ parsing, schema evaluation และการ render error ทั้งหมดรันฝั่ง client ในเบราว์เซอร์ จึงปลอดภัยแม้ไฟล์ values มี internal hostname หรือ configuration ที่อ่อนไหว

ถ: YAML syntax error กับ schema error ต่างกันอย่างไร?

ตอบ: syntax error คือไฟล์ parse ไม่ได้เลย เช่นลืม colon หรือ indent เพี้ยน ส่วน schema error คือ YAML ถูกต้องแต่ขัด contract เช่น type ผิด, required key หาย หรือค่า enum ไม่อนุญาต เครื่องมือรายงานทั้งสองแบบแยกชัดเจน

ถ: ตรวจ value ที่ซ้อนกันหลายชั้นและ array ได้ไหม?

ตอบ: ได้ schema draft-07 มักอธิบาย object ซ้อนกันและ array ของ object และ error จะรายงานด้วย key path เต็ม เช่น ingress.tls[0].secretName ทำให้ปัญหาที่ซ่อนลึกหลายชั้นยังชี้ตรงถึงตำแหน่งที่ผิด