เครื่องมือตรวจสอบ YAML ของ Kubernetes
วาง Kubernetes manifest หนึ่งรายการหรือมากกว่า (คั่นด้วย ---) แล้วตรวจสอบกับสคีมาจริงก่อนที่คุณจะ kubectl apply
ลากไฟล์ .yaml/.yml มาวางที่นี่ หรือวางข้อความ manifest ด้านบน
manifest หลายรายการที่คั่นด้วย "---" จะถูกตรวจสอบแยกเป็นเอกสารแต่ละรายการ
ตัวเลือกขั้นสูง
การแยกวิเคราะห์และตรวจสอบทำงานในเบราว์เซอร์ของคุณ — มีเพียงสคีมาของรีซอร์สเท่านั้น (ไม่ใช่ manifest ของคุณ) ที่จะถูกดึงจาก CDN สาธารณะ
วาง Kubernetes manifest ด้านบน (หรือโหลดตัวอย่าง) แล้วผลการตรวจสอบจะแสดงที่นี่
จับข้อผิดพลาดของ Kubernetes manifest ก่อนที่ kubectl จะเจอ
การที่ `kubectl apply` ถูกปฏิเสธมักเป็นครั้งแรกที่ข้อผิดพลาดใน Kubernetes manifest ปรากฏให้เห็น ซึ่งตอนนั้นคุณมักกำลังดีพลอยอยู่ และต้องจ้องข้อความผิดพลาดที่อ้างเส้นทางตรวจสอบ JSON Schema (`spec.template.spec.containers[0].image: Required value`) ที่ไม่ชัดเจนว่าตรงกับตรงไหนของไฟล์ YAML ที่เพิ่งแก้ การจับข้อผิดพลาดประเภทเดียวกันได้เร็วขึ้นพร้อมไฮไลต์บรรทัดที่แน่นอน ทำให้เรื่องนี้กลายเป็นการแก้ภายในห้าวินาที แทนที่จะต้องเปลี่ยนบริบทงาน
ไวยากรณ์ของ YAML มีจุดที่แหลมคมซึ่งไม่ค่อยพบในรูปแบบคอนฟิกอื่น การเยื้องมีความหมาย แท็บและช่องว่างที่ปนกันอาจสร้างโครงสร้างที่ต่างออกไป (และผิด) โดยไม่ขึ้นข้อผิดพลาดในบางกรณี ตัวคั่นเอกสาร `---` ตามยากในไฟล์ที่มีหลายทรัพยากร และการซ้อนเกินมาหนึ่งระดับก็ยังอ่านเป็น YAML ที่ถูกต้องแต่มีความหมายต่างไปโดยสิ้นเชิงสำหรับ Kubernetes เครื่องมือนี้แยกวิเคราะห์ด้วยแนวทางของไลบรารีที่เก็บข้อมูลตำแหน่งต้นฉบับครบถ้วน ปัญหาด้านไวยากรณ์จึงถูกรายงานที่บรรทัดจริง ไม่ใช่แค่ "สักแห่งในไฟล์ 200 บรรทัดนี้"
apiVersion ที่เลิกใช้เป็นกับดักที่เกิดช้ากว่า Deployment แบบ `extensions/v1beta1`, StatefulSet และ DaemonSet แบบ `apps/v1beta1`/`apps/v1beta2` และ Ingress แบบ `networking.k8s.io/v1beta1` ล้วนยังแยกวิเคราะห์เป็น YAML ที่ถูกต้อง และเคยใช้ได้บนคลัสเตอร์เก่า จนกระทั่งคลัสเตอร์ถูกอัปเกรดเกินเวอร์ชันที่ Kubernetes ลบ API group เดิมออกไปจริง ๆ แล้ว manifest ทุกไฟล์ที่ใช้มันจะ apply ไม่ผ่านโดยไม่มีคำเตือนล่วงหน้า การจับสิ่งเหล่านี้ขณะแก้ไข (พร้อมแนะนำ apiVersion ที่ใช้แทน) ช่วยให้ไม่ต้องไปรู้ตอนอัปเกรดคลัสเตอร์
การตรวจสอบสคีมากับ OpenAPI spec จริงของ Kubernetes จับที่เหลือได้ เช่น ฟิลด์ `replicas` ที่กลายเป็นสตริงในเครื่องหมายคำพูดแทนที่จะเป็นตัวเลข `containerPort` ที่อยู่นอกช่วงที่ถูกต้อง หรือฟิลด์ที่จำเป็นอย่าง `spec.selector` ใน Deployment ที่หายไประหว่างคัดลอก-วางข้าม manifest ทั้งหมดนี้ไม่ใช่ข้อผิดพลาดไวยากรณ์ YAML เพราะไฟล์ยังแยกวิเคราะห์ได้ปกติ นั่นคือเหตุผลที่การตรวจสคีมาโดยเฉพาะจับสิ่งที่การอ่านผ่านตาเพียงเร็ว ๆ มักไม่เห็น
คำถามที่พบบ่อย
เครื่องมือนี้ใช้แทน `kubectl apply --dry-run` หรือ `kubeconform` ได้ไหม
ไม่ได้ `kubectl apply --dry-run=server` เป็นการตรวจเดียวที่ทำงานกับ API server ของคลัสเตอร์จริงของคุณ (รวมถึง CRD และ admission webhook ที่ติดตั้งไว้) ส่วน `kubeconform`/`kubeval` เป็นเครื่องมือ CLI ที่ผ่านการใช้งานมานานสำหรับ CI pipeline เครื่องมือนี้ตรวจสิ่งประเภทเดียวกัน ได้แก่ ไวยากรณ์ YAML รูปทรงตามสคีมา และ apiVersion ที่เลิกใช้ จากแท็บเบราว์เซอร์ ก่อนที่คุณจะตั้งค่า `kubectl` กับคลัสเตอร์ใด ๆ หรือขณะตรวจ manifest ที่คนอื่นส่งมาให้
สคีมามาจากไหน
มาจาก `yannh/kubernetes-json-schema` ซึ่งเป็นมิเรอร์ที่ชุมชนดูแลและอัปเดตอัตโนมัติของ JSON Schema ที่สร้างจาก OpenAPI ของ Kubernetes เอง ดึงตามต้องการจาก CDN สาธารณะตามเวอร์ชัน Kubernetes ที่คุณเลือก ไม่มีข้อมูลใดของ manifest ถูกส่งออกไป ดาวน์โหลดเฉพาะไฟล์สคีมาสาธารณะที่ระบุเวอร์ชัน ซึ่งเป็นไฟล์เดียวกันสำหรับผู้ใช้ทุกคนที่ตรวจ kind/เวอร์ชันนั้น
ทำไมมีแค่ 10 ชนิดทรัพยากร
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob และ PersistentVolumeClaim ครอบคลุม manifest ที่เขียนด้วยมือส่วนใหญ่ ชนิดอื่น ๆ ยังได้รับการตรวจไวยากรณ์ YAML เต็มรูปแบบและการตรวจจับ apiVersion ที่เลิกใช้ เพียงแต่ยังไม่มีการตรวจรูปทรงตามสคีมา
YAML ของฉันออกจากเบราว์เซอร์หรือไม่
ไม่ การแยกวิเคราะห์และตรวจสอบสคีมาทำงานด้วย JavaScript ล้วนในแท็บนี้ คำขอเครือข่ายเดียวที่เครื่องมือนี้ทำคือดึงไฟล์ JSON Schema สาธารณะของชนิดทรัพยากรและเวอร์ชัน Kubernetes ที่คุณเลือก ไม่เคยส่งเนื้อหา manifest ของคุณ