أداة التحقق من YAML الخاص بـ Kubernetes
الصق واحدًا أو أكثر من ملفات Kubernetes (مفصولة بـ ---) وتحقق منها مقابل المخطط الحقيقي قبل تنفيذ kubectl apply.
أفلت ملف .yaml/.yml هنا، أو الصق نص الملف أعلاه.
يتم التحقق من الملفات المفصولة بـ "---" كمستندات منفصلة.
خيارات متقدمة
يتم التحليل والتحقق في متصفحك — لا يتم تحميل سوى مخطط المورد (وليس ملفك أبدًا) من شبكة توصيل محتوى عامة.
الصق ملف Kubernetes أعلاه (أو حمّل المثال) لتظهر نتائج التحقق هنا.
اكتشاف أخطاء ملفات Kubernetes قبل أن يكتشفها kubectl
غالبًا ما يكون رفض `kubectl apply` أول مرة يظهر فيها خطأ في ملف Kubernetes، وتكون حينها في منتصف النشر تحدّق في رسالة خطأ تقتبس مسار تحقق من JSON Schema (`spec.template.spec.containers[0].image: Required value`) لا يرتبط بوضوح بملف YAML الذي كنت تحرره. أما اكتشاف الفئة نفسها من الأخطاء مبكرًا مع تمييز السطر بدقة، فيحوّلها إلى إصلاح في خمس ثوانٍ بدل تبديل للسياق.
لصياغة YAML حواف حادة لا تظهر في معظم صيغ الإعداد الأخرى: المسافات البادئة مهمة، وقد يُنتج الخلط بين Tab والمسافات في بعض الحالات بنية مختلفة (خاطئة) بدل أن يُظهر خطأ، ومن السهل أن تضيع فواصل المستندات `---` في ملف طويل متعدد الموارد، ومستوى تداخل زائدًا يُقرأ كـ YAML صالح لكنه يعني شيئًا مختلفًا تمامًا لـ Kubernetes. تحلل هذه الأداة بأسلوب مكتبة يحتفظ بمعلومات موضع المصدر كاملة أثناء التحليل، فيُبلَّغ عن مشكلة الصياغة في السطر الفعلي الذي تقع فيه، لا «في مكان ما من هذا الملف ذي الـ 200 سطر».
إصدارات apiVersion المهجورة فخ بطيء الحركة: فـ Deployments من `extensions/v1beta1`، وStatefulSets وDaemonSets من `apps/v1beta1`/`apps/v1beta2`، وIngresses من `networking.k8s.io/v1beta1`، كلها ما زالت تُقرأ كـ YAML صالح تمامًا وعملت على العناقيد الأقدم، إلى أن يُرقّى العنقود إلى إصدار يزيل فيه Kubernetes مجموعة API القديمة نهائيًا، فتبدأ كل الملفات التي تستخدمها بالفشل عند التطبيق دون أي إنذار مسبق. واكتشافها أثناء التحرير (مع اقتراح apiVersion البديل بدقة) يغنيك عن اكتشافها أثناء ترقية العنقود.
أما التحقق بمخطط OpenAPI الحقيقي لـ Kubernetes فيلتقط الباقي: حقل `replicas` صار نصًا مقتبسًا بدل رقم، أو `containerPort` خارج النطاق الصالح، أو حقل مطلوب مثل `spec.selector` في Deployment حُذف أثناء النسخ واللصق بين الملفات. لا شيء من هذه أخطاء صياغة YAML، فالملف يُحلَّل بسلام، ولهذا بالضبط يلتقط تمرير المخطط المخصص ما لا تلتقطه عادةً القراءة البصرية السريعة للملف.
الأسئلة الشائعة
هل تغني هذه الأداة عن `kubectl apply --dry-run` أو `kubeconform`؟
لا. الأمر `kubectl apply --dry-run=server` هو الفحص الوحيد الذي يجري على خادم API في عنقودك الفعلي (بما في ذلك أي CRDs وwebhooks القبول المثبتة فيه)، و`kubeconform`/`kubeval` أدوات سطر أوامر ناضجة مصممة لخطوط CI. أما هذه الأداة فتفحص الفئة نفسها من الأشياء، وهي صياغة YAML وبنية المخطط وإصدارات apiVersion المهجورة، من تبويب متصفح، قبل أن تهيئ `kubectl` على أي عنقود، أو أثناء مراجعة ملف أرسله إليك شخص آخر.
من أين تأتي المخططات؟
من `yannh/kubernetes-json-schema`، وهو نسخة يحافظ عليها المجتمع وتتحدث تلقائيًا من مخططات JSON Schema المشتقة من OpenAPI الخاصة بـ Kubernetes، وتُجلب عند الطلب من CDN عام لإصدار Kubernetes الذي تختاره. لا يُرسل شيء من ملفك إلى أي مكان، إذ يُنزَّل ملف المخطط العام ذو الإصدار فقط، وهو نفسه لكل مستخدم يتحقق من هذا النوع والإصدار.
لماذا 10 أنواع من الموارد فقط؟
تغطي Deployment وService وIngress وConfigMap وSecret وStatefulSet وDaemonSet وJob وCronJob وPersistentVolumeClaim الغالبية العظمى من الملفات المكتوبة يدويًا. أما الأنواع الأخرى فتحصل على فحص كامل لصياغة YAML واكتشاف apiVersion المهجورة، لكن بلا تحقق من بنية المخطط حتى الآن.
هل يغادر YAML الخاص بي متصفحي في أي وقت؟
لا. يعمل التحليل والتحقق بالمخطط بـ JavaScript عادي في هذا التبويب، والطلب الشبكي الوحيد الذي تجريه الأداة هو جلب ملف JSON Schema العام لنوع المورد وإصدار Kubernetes اللذين اخترتهما، وليس محتوى ملفك أبدًا.