مقدمة موجزة للتخصيص

ملحوظة. ترجمة.: تمت كتابة المقالة بواسطة سكوت لوي، وهو مهندس يتمتع بخبرة واسعة في مجال تكنولوجيا المعلومات، وهو المؤلف/المؤلف المشارك لسبعة كتب مطبوعة (أساسًا عن VMware vSphere). وهو يعمل الآن في شركة Heptio التابعة لشركة VMware (التي تم الاستحواذ عليها في عام 2016)، وهو متخصص في الحوسبة السحابية وKubernetes. يعد النص نفسه بمثابة مقدمة موجزة وسهلة الفهم لإدارة التكوين لـ Kubernetes باستخدام التكنولوجيا تخصيص، والتي أصبحت مؤخرًا جزءًا من K8s.

Kustomize هي أداة تتيح للمستخدمين "تخصيص ملفات YAML بسيطة وخالية من القوالب لأغراض مختلفة، مع ترك ملف YAML الأصلي سليمًا وقابلاً للاستخدام" (الوصف مستعار مباشرةً من تخصيص المستودع على جيثب). يمكن تشغيل Kustomize مباشرة أو استخدامه اعتبارًا من Kubernetes 1.14 kubectl -k للوصول إلى وظائفه (على الرغم من أنه اعتبارًا من Kubernetes 1.15، فإن الثنائي المنفصل أحدث من الإمكانات المضمنة في kubectl). (ملحوظة. ترجمة.: ومع الإصدار الأخير Kubernetes 1.16 تحديث تخصيص مدعوم من أيضًا في الأداة المساعدة kubeadm.) في هذا المقال، أريد أن أقدم للقراء أساسيات التخصيص.

في أبسط أشكاله/تطبيقاته، يعد kustomize مجرد مجموعة من الموارد (ملفات YAML التي تحدد كائنات Kubernetes: عمليات النشر والخدمات وما إلى ذلك) بالإضافة إلى قائمة تعليمات التغييرات التي يجب إجراؤها على تلك الموارد. تمامًا كما يستخدم make مجموعة التعليمات الموجودة فيه Makefile، ويقوم Docker ببناء الحاوية بناءً على التعليمات الواردة من Dockerfileتخصيص الاستخدامات kustomization.yaml لتخزين تعليمات حول التغييرات التي يريد المستخدم إجراؤها على مجموعة من الموارد.

هنا ملف مثال kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

لن أحاول التحدث عن جميع الحقول الممكنة في الملف. kustomization.yaml (هذا مكتوب بشكل جيد عنه هنا)، ولكن سأقدم شرحا موجزا لمثال محدد:

• حقل resources يشير إلى ما (الموارد) التي سيتم تغييرها. في هذه الحالة، فإنه سيتم البحث عن الموارد في الملفات deployment.yaml и service.yaml في الدليل الخاص بك (يمكنك تحديد المسارات الكاملة أو النسبية إذا لزم الأمر).
• حقل namePrefix يرشد kustomize لإضافة بادئة معينة (في هذه الحالة - dev-) أن ينسب name جميع الموارد المحددة في هذا المجال resources. وهكذا، إذا كان النشر قد name مع معنى nginx-deployment، التخصيص سيجعل ذلك dev-nginx-deployment.
• حقل namespace يرشد kustomize لإضافة مساحة الاسم المحددة لجميع الموارد. في هذه الحالة، سوف يقع النشر والخدمة في مساحة الاسم development.
• وأخيراً الميدان commonLabels يحتوي على مجموعة من التسميات التي سيتم إضافتها إلى جميع الموارد. في مثالنا، سيقوم kustomize بتعيين تسمية للموارد بالاسم environment والمعنى development.

إذا قام المستخدم بذلك kustomize build . في الدليل مع الملف kustomization.yaml والموارد اللازمة (أي الملفات deployment.yaml и service.yaml)، ثم عند الإخراج سيتلقى نصًا يتضمن التغييرات المحددة فيه kustomization.yaml.

ملحوظة. ترجمة.: رسم توضيحي من وثائق المشروع حول الاستخدام "البسيط" لـ kustomize

يمكن إعادة توجيه الإخراج إذا كانت هناك حاجة إلى الالتزام بالتغييرات:

kustomize build . > custom-config.yaml

تعتبر بيانات المخرجات حتمية (نفس بيانات الإدخال ستنتج نفس نتائج المخرجات)، لذلك لا يتعين عليك حفظ النتيجة في ملف. بدلاً من ذلك، يمكن تمريره مباشرة إلى أمر آخر:

kustomize build . | kubectl apply -f -

يمكن أيضًا الوصول إلى ميزات التخصيص عبر kubectl -k (منذ الإصدار 1.14 من Kubernetes). ومع ذلك، ضع في اعتبارك أن الحزمة المخصصة المستقلة يتم تحديثها بشكل أسرع من حزمة kubectl المدمجة (على الأقل هذا هو الحال مع إصدار Kubernetes 1.15).

قد يتساءل القراء: "لماذا كل هذا التعقيد إذا كان بإمكانك تحرير الملفات مباشرة؟" سؤال عظيم. في مثالنا، في الواقع يمكن للمرء تعديل الملفات deployment.yaml и service.yaml مباشرة، ولكن ماذا لو كانوا شوكة لمشروع شخص آخر؟ إن تغيير الملفات مباشرة يجعل من الصعب (إن لم يكن من المستحيل) إعادة تأسيس الشوكة عند إجراء تغييرات على الأصل/المصدر. يتيح لك استخدام kustomize مركزية هذه التغييرات في ملف kustomization.yaml، مع ترك الملفات الأصلية سليمة وبالتالي يسهل إعادة صياغة الملفات الأصلية إذا لزم الأمر.

تصبح فوائد التخصيص واضحة في حالات الاستخدام الأكثر تعقيدًا. في المثال أعلاه kustomization.yaml والموارد في نفس الدليل. ومع ذلك، يدعم kustomize حالات الاستخدام حيث يوجد تكوين أساسي والعديد من المتغيرات منه، والمعروفة أيضًا باسم التراكبات. على سبيل المثال، أراد أحد المستخدمين استخدام النشر والخدمة لـ nginx، والذي استخدمته كمثال، وإنشاء إصدارات (أو متغيرات) للتطوير والتشغيل والإنتاج لهذه الملفات. للقيام بذلك، سيحتاج إلى التراكبات المذكورة أعلاه، وفي الواقع، الموارد الأساسية نفسها.

لتوضيح فكرة التراكبات والموارد الأساسية (الموارد الأساسية)لنفترض أن الدلائل لها البنية التالية:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

في ملف base/kustomization.yaml المستخدمين باستخدام هذا المجال resources قم ببساطة بالإعلان عن الموارد التي يجب أن يتضمنها التخصيص.

في كل ملف من الملفات overlays/{dev,staging,prod}/kustomization.yaml يشير المستخدمون إلى التكوين الأساسي في هذا المجال resources، ثم قم بالإشارة إلى التغييرات المحددة لـ بيئة معينة. على سبيل المثال، ملف overlays/dev/kustomization.yaml قد يبدو مثل المثال المذكور سابقًا:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

في هذه الحالة الملف overlays/prod/kustomization.yaml يمكن أن يكون مختلفًا تمامًا:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

عندما يقوم المستخدم بتشغيل kustomize build . في الكتالوج overlays/dev، سيؤدي التخصيص إلى إنشاء خيار التطوير. اذا ركضت kustomize build . في الكتالوج overlays/prod - تحصل على خيار الإنتاج. وكل هذا - دون إجراء أي تغييرات على الأصل (يتمركز) الملفات، كل ذلك بطريقة تعريفية وحتمية. يمكنك الالتزام بالتكوين الأساسي وتراكب الدلائل مباشرة للتحكم في الإصدار، مع العلم أنه بناءً على هذه الملفات، يمكنك إعادة إنتاج التكوين المطلوب في أي وقت.

ملحوظة. ترجمة.: رسم توضيحي من وثائق المشروع حول استخدام التراكبات في kustomize

تخصيص يمكن أكثر أكثر مما تناولته هذه المقالة. ومع ذلك، آمل أن تكون بمثابة مقدمة جيدة.

مصادر إضافية

هناك العديد من المقالات والمنشورات الجيدة حول kustomize. فيما يلي بعض الأشياء التي وجدتها مفيدة بشكل خاص:

• قم بتغيير تكوين YAML الأساسي لبيئات مختلفة prod/test باستخدام Kustomize;
• Kubernetes - الطريقة الصحيحة للقيام بالقوالب في Kubernetes;
• الإدارة التعريفية لكائنات Kubernetes باستخدام التخصيص;
• تخصيص مخططات رأس المنبع مع التخصيص.

ملحوظة. ترجمة.: يمكنك أيضًا التوصية بمجموعة من الروابط المنشورة باسم الموارد على موقع الأداة المساعدة، تليها مجموعة من مقاطع الفيديو مع أحدث التقارير حول kustomize.

إذا كانت لديك أسئلة أو اقتراحات لتحسين هذه المادة، فأنا دائمًا منفتح على تلقي التعليقات. يمكنك الاتصال بي في تويتر أو قناة Kubernetes سلاك. استمتع بتعديل بياناتك باستخدام kustomize!

PS من المترجم

اقرأ أيضًا على مدونتنا:

• «أدوات لمطوري التطبيقات التي تعمل على Kubernetes"؛
• «Kubernetes 1.14: إبراز الميزات الجديدة"؛
• «خمس نتائج رئيسية لقمة هيلم 2019 في أمستردام"؛
• «التدريب العملي مع مدير حزمة Kubernetes - Helm".

المصدر: www.habr.com