خطوات الاستخدام
الخطوة الأولى: فهم الحقول الأساسية في Kubernetes Manifest. يتكون بيان Kubernetes (Manifest) من مجموعة من الحقول الإلزامية التي تضمن تعريف المورد بشكل صحيح. الحقول الأربعة الأساسية هي: apiVersion (إصدار API)، kind (نوع المورد)، name (الاسم)، و namespace (مساحة الأسماء). كل حقل له دور حاسم: يحدد apiVersion إصدار واجهة برمجة التطبيقات المستخدمة (مثل v1 أو apps/v1)، بينما يحدد kind نوع المورد (مثل Pod أو Deployment). name هو المعرف الفريد للمورد ضمن مساحة الأسماء، و namespace يحدد مجموعة الموارد المنطقية. إذا كان أي من هذه الحقول مفقودًا، سيرفض Kubernetes البيان.
الخطوة الثانية: إدخال قيم الحقول في الحاسبة. أدخل قيم apiVersion و kind و name و namespace كما تظهر في ملف YAML. تأكد من أنها تطابق التنسيق المطلوب: apiVersion يجب أن يكون سلسلة نصية مثل 'v1' أو 'apps/v1'، و kind مثل 'Pod'، و name أقل من 253 حرفًا ويتوافق مع تسمية DNS، و namespace يجب أن يكون اسمًا صالحًا. الحاسبة لا تتحقق من صحة القيم نفسها، فقط من وجودها.
الخطوة الثالثة: النقر على زر التحقق. بعد إدخال جميع الحقول، ستقوم الحاسبة بالتحقق مما إذا كانت كل الحقول غير فارغة. إذا كانت جميعها تحتوي على قيم، فستعيد النتيجة 1 (صالحة). وإلا، فستعيد 0 (غير صالحة). هذا مفيد لأتمتة فحص المانيفستات قبل تطبيقها على الكتلة.
الخطوة الرابعة: فهم النتيجة والتصرف بناءً عليها. إذا كانت النتيجة 0، فهذا يعني أن واحدًا أو أكثر من الحقول الإلزامية مفقود. يجب مراجعة ملف YAML وإضافة الحقول الناقصة. الحقول مثل apiVersion و kind حساسة لحالة الأحرف ويجب أن تتطابق مع القيم المتوقعة من قبل Kubernetes. تذكر أن بعض الموارد قد تتطلب حقولًا إضافية مثل spec أو metadata.labels، لكن هذه الحاسبة تتحقق فقط من الحقول الأساسية الأربعة.
الخطوة الخامسة: تطبيق أفضل الممارسات. حتى إذا كانت الحقول الأساسية موجودة، تأكد من أن القيم صحيحة: apiVersion يجب أن يتوافق مع إصدار Kubernetes (مثلاً use 'apps/v1' لـ Deployment بدلاً من 'extensions/v1beta1' القديم). kind يجب أن يكون نوعًا صالحًا، و name يجب أن يكون فريدًا ضمن مساحة الأسماء. استخدم هذه الحاسبة كخطوة أولى في سير عمل CI/CD لتصفية المانيفستات غير الصالحة بسرعة.
أمثلة محلولة
تطبيقات عملية على التحقق من صحة Kubernetes Manifest بخطوات الحل كاملة.
الحل
نعم، المانيفست صالح لأن جميع الحقول الأربعة الأساسية موجودة. الحاسبة ستنتج 1. يجب ملاحظة أن هذا لا يضمن صحة المحتوى مثل الحاويات أو المنافذ، ولكنه يضمن أن البنية الأساسية للمانيفست صحيحة. في الممارسة العملية، يجب أيضًا التحقق من أن namespace موجود بالفعل في الكتلة قبل التطبيق، وأن name لا يتعارض مع موارد أخرى. هذا المثال يمثل حالة بسيطة لمورد جذر (Root resource) يستخدم إصدار v1.
الحل
النتيجة ستكون 0 لأن الحقل name مطلوب ولكنه فارغ. في Kubernetes، يعد الحقل name جزءًا من metadata وهو إلزامي لجميع الموارد. بدون اسم، لا يمكن التعرف على المورد أو إدارته. حتى إذا كان لديك apiVersion و kind و namespace صحيحة، فإن غياب name يجعل المانيفست غير صالح. في هذا المثال، قد يتسبب تطبيق هذا المانيفست في خطأ من جانب Kubernetes مثل 'Missing required field: metadata.name'. لذلك، يجب إضافة اسم مناسب مثل 'my-deployment' ليصبح المانيفست صالحًا.
أمثلة محسوبة
قيم مُدخَلة ونتيجة محسوبة فعليًا بواسطة التحقق من صحة Kubernetes Manifest.
مرجع — مانيفست صالح كامل الحقول
- إصدار API
- v1
- النوع
- Pod
- الاسم
- my-pod
- النطاق
- production
مرجع — اسم مفقود
- إصدار API
- apps/v1
- النوع
- Deployment
- الاسم
- —
- النطاق
- development