كابيتان على رأس Kubernetes

قابل كابيتان . يساعدك على جلب الجمال والنظام إلى تكوين Kubernetes الخاص بك.

تكتسب Kapitan سمعة من مراجعات المستخدمين الراضين ، وبالتالي تستفيد من الوثائق الشاملة والتسويق المكلف. لدينا ما يكفي من النجوم واثنين من الإشارات من المدونين والخطباء في Kubernetes. أصبح كابيتان حتى بطل الرواية لفصل كامل في الكتاب . الأهم من ذلك هو أنه جذب انتباه العديد من الشركات الواعدة ، لأن Kapitan ، مثله مثل أي شخص آخر ، قادر على كشف التكوين المرتبط بعقدة البحر .

في kubernetes.slack.com تمكنت #kapitan من جمع مجتمع صغير ولكنه مخصص (انضم إلى!) ، لذلك نحن فخورون بعملنا :)

لا يزال الكثيرون يعتقدون أن Kapitan عبارة عن مزيج من jsonnet و jinja ، لكنهم يفتقدون هذه الفكرة.
في هذا المنشور ، سوف أخبرك كيف تدير Kapitan عمليات نشر Kubernetes ، ولكن بشكل عام يمكنها أن تكون أكثر من ذلك. هذا مهم: Kapitan عالمي وغير مثبت على Kubernetes واحد. Kubernetes هي ببساطة واحدة من العديد من الاستخدامات.

هذا ليس مرشدًا (على الرغم من أنني أعدك بدليل أيضًا). أريد فقط أن أخبركم لماذا فعلنا ذلك وما هي المشاكل التي يجب أن تحلها من خلال نشرات تكوينات Kubernetes.

ما لم يعجبني

بدأت تجربة Kubernetes في عام 2015 وسقطت على الفور في الحب.
صحيح أن هناك العديد من العيوب التي لا أريد تحملها:

• السياق . بالنسبة لي ، هذا واحد من أصعب المفاهيم لفهم Kubernetes - وأحد أخطرها. يشير السياق إلى العميل ، ومن الصعب فهمه ، ويُطلق عليه الخلط ويخلق البلبلة عند تشغيل أوامر kubectl . أنا أكره السياقات في kubectl!
• مطوّل التكوين المتداخلة (yaml!) . اضطررت للعرق لمعرفة كل مستوى من التكوين yaml في البيان. ما هي الفائدة من تكرار العلامات مرتين إلى ثلاث مرات في عدة أماكن؟
• فوضى مع فرق حتمية وإعلانية . يتم تشجيع القادمين الجدد إلى Kubernetes على التعلم من قبل فرق ضرورية ، على الرغم من أنه من الواضح أن الأشخاص العاديين لا يستخدمونها. في رأيي ، من الأصعب فقط دمج Kubernetes في استراتيجية النشر الصحيحة لشركتك. المفسد: لا توجد "استراتيجية صحيحة" واحدة.
• تكوين وقت التشغيل . يكون Jesse Suen على حق عندما ينصح بعدم تمرير معلمات التكوين إلى سطر أوامر helm (أو kubectl وغيرها). مع المعلمات ، يمكن تنفيذ الأمر نفسه بشكل مختلف في كل مرة.
• تكوين التطبيق لقد تعلمنا كيفية إدارة قوائم yaml في Kubernetes ، نحن رائعون. هذا فقط تحت ونشر - وهذا هو وعاء فارغ. لا يزال يتعين عليه تعويم التطبيق بكل أشكاله.
• يرغب المطورون في قضاء عطلة ، وسير العمل في Kubernetes لا يزال منخفضًا بعض الشيء. يجبر مشجعو Kubernetes الجميع على القيام بذلك هناك. هل هو ضروري؟ أوبي كيلسي هايتاور!
• مشغلي لدي مشاعر مختلطة بالنسبة لهم ، لذلك أترك هذا الموضوع في الوقت الحالي :) لا يمكنني إلا أن أقول إنهم يتعرضون للاعتداء.
• العاطفة . بدلا من ذلك ، غيابها. إذا أضفنا جميع أوجه القصور المذكورة أعلاه ، فسوف نحصل على سير عمل ضعيف بما فيه الكفاية ، وهذا أمر محزن بالنسبة لـ Kubernetes.

ما يجب القيام به

لقد حاولت حل هذه المشكلات ووضعت نظامًا صغيرًا للحركة يستخدم j2cli واثنين من البرامج النصية للباش لإدارة تكوينات Kubernetes.

وضع النظام كل شيء في ملف environmentA.yaml واستخدمه في قالب Jinja2. كان من الممكن نشر تطبيقات بأسلوب microservice من عدة مكونات باستخدام أمر بسيط:

bin/apply.sh environments/environmentA.yaml 

رائع! كان Yaml كل شيء عن نشر. إنه ملائم للغاية ، لأنه يمكنني استخدام نفس الملف كمصدر للمعلومات لشيء آخر. قل ل ... مخطوطات باش !

لقد اكتشفت كيفية استيراد القيم من yaml إلى البرامج النصية لتنفيذ أوامر مماثلة:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

ثم خرج كل شيء عن السيطرة في وقت واحد :

• لم أستطع فعل أي شيء مع الهيكل في ملف yaml. كان mishmash من نفس الحقول والقيم والتكوين الخلط.
• لن تعرف أبدًا كيف تتصرف النشر في البيئة حتى تحاول. غالبًا ما كان هذا بسبب التغييرات في قوالب jinja2 بسبب قيمة مخزون جديدة (على سبيل المثال ، feature_X) لم تنجح في بيئات لم يتم تعريف هذه الوظيفة فيها.
• نفس المشكلة في البرامج النصية: إذا كنت لا تحاول ذلك ، فأنت لا تعلم.
• في بعض الأحيان تغيرت Kubernetes بسرعة لدرجة أنها أزعجتني باستمرار لتغيير البيانات لإصدارات مختلفة ، لا سيما العبث مع التعليقات التوضيحية على القيم.
• العامل الخارجي : تحول فريق التطوير من ملفات التكوين إلى معلمات سطر الأوامر. مثل هذا التغيير البسيط أربكنا جميع الأوراق ، وكان علينا التفكير في حل جديد.
• الأهم من ذلك : templating yaml مع Jinja (أو قوالب Go) ليست متعة! ثم كان لدينا لغز: " ما يشبه النص ، يقرأ مثل النص ، تنبعث منه رائحة النص ، ولكن ليس النص؟ ". أو ، كما قالها لي بريجز باقتدار: " لماذا بحق الجحيم نحن نمثل yaml؟ "

كابيتان: أصبح

لقد جمعنا جميع تجربتنا المريرة ، وبدأنا مع ريكاردو أمارو في تخيل نظام إدارة التكوين المثالي. بعد ذلك ، لم يكن لدينا صورة واضحة ، لكننا عرفنا أننا أحببنا ولم نحبها.

الحب :

• بوابة
• الزخرفة بشكل عام: البيانات / القيم منفصلة عن الأنماط.
• قيم منفصلة للجوانب المختلفة (التطبيق ، Kubernetes ، وقت التشغيل ...).
• وجوه المنحى النهج.
• yaml المبسطة كواجهة لإخفاء تعقيد Kubernetes.
• فهم واضح لما يحدث ولماذا.
• إعادة استخدام القيم في المكونات المختلفة.
• ويجب أن يكون للنصوص حق الوصول إلى القيم.

نحن لا نحب :

• سياقات Kubectl
• محركات قالب النص لإنشاء yaml.
• المسافة البادئة: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• السحر: كل شيء يجب أن يكون واضحا وواضحا. لا الحيل.
• الإدارة اليدوية لكلمات المرور وأسرار التطبيق.
• أسلوب تيلر: أردنا السيطرة على استخدام البيانات.
• Git-crypt approach: لا يتم تشفير الأسرار الموجودة على القرص.
• خط أنابيب قالب مباشرة إلى kubectl.
• تمرير خيارات سطر الأوامر.

ثم حدث شيئان :

1. اكتشفنا jsonnet ديف Cunningham ل templating yaml / json في لغة وجوه المنحى.
2. لقد أوضح لنا غوستافو بوريولا عملية إعادة التصنيف ، وبدونه لن نكون قد ذهبنا بعيدًا.

بدأ ريكاردو أمارو العمل ، وسرعان ما جلس الفريق بأكمله في كابيتان - عمل بعضهم على الوظائف الأساسية ، بينما عمل آخرون على استخدامه في مشاريعنا الداخلية. إدارة الأسرار ، دعم gpg \ kms ، وظائف معرّفة من قِبَل المستخدم: الآن Kapitan منتج متكامل يعمل بأكثر من وعد.

من هو كابيتان؟

يحاول Kapitan حل جميع المشكلات التي تحدثت عنها (أو كلها تقريبًا).

من الناحية الفنية ، فإن Kapitan بسيط جدًا:

• المخزون : مجموعة هرمية من القيم التي تصف النشر بناءً على yaml. بناء على إعادة التصنيف. مثل هيرا.
• محركات القوالب : الآن هي Jinja2 ، Jsonnet ، Kadet. يأخذون المخزون وإنشاء ملفات (البرامج النصية yaml ، json ، وثائق أو باش).
• الأسرار : أسرار القالب ، وسوف يتعامل معها Kapitan.

نحن نستخدم jsonnet لقالب البيانات و Jinja للقيام بالباقي.

أحيانًا يشتكي الأشخاص من أن ملف jsonnet مختلف تمامًا عن ملف yaml نفسه ، لذلك يصعب عليهم التبديل إلى jsonnet.

حاولنا حل هذه المشكلة مع كاديت من خلال لف ياميل في بيثون. خذ yaml المفضل لديك كأساس وأضف Python إليه.

النظر في هذا الهيكل الخارجي لبايثون ل yaml! بطريقة ما سأتحدث عن هذا.

في سير العمل ، يُظهر Kapitan الحرف على الفور:

• حرية الاختيار : نحن لا نفرض أي عمليات وتقنيات العمل ، ولكن عادة ما نعمل على المبادئ الموضحة أدناه. في الواقع ، يمكن استخدام Kapitan كما تريد. لا يلزمك استخدام git ، ولا يجب عليك ترجمة الملفات الموجودة فيه ، ويمكنك حتى الاستغناء عن jsonnet! افعل ما تريد
• GitOps لنخاع العظام: كل شيء في git ، كل شيء في ضوء يعكس هدفنا.
• التصريح : ترحب Kapitan بتجميع قوالب البيان في عروض محددة. وأنت تجميع النصوص الخاصة بك.
• السياق الخاضع للرقابة : نستخدم البرامج النصية المترجمة لتبسيط أعمالنا ، على سبيل المثال ، عند إعداد السياقات وتكوين المجموعات.
  تكوين Kubernetes: compiled/target_A/setup/setup.sh
  تطبيق التغييرات: compiled/target_A/setup/apply.sh
• Idempotency : يسمح لك Kapitan بتغيير القوالب وأدوات إعادة تشكيل الكود. لن تتغير البيانات المترجمة والرمز بدون أمرك ، لذلك ليس لديك ما تخشاه عند إعادة البناء.
• السبب والتأثير : نحن لسير العمل حيث يتم تضمين التغييرات في المخزون أو القوالب والملفات المترجمة في طلب دمج واحد. لذلك سيكون المراجع قادرًا على تقييم تغييراتك ونتائجها الفعلية. من الجيد معرفة ما إذا كان التغيير في القالب سيؤثر على هدف أو هدفين أو أكثر.
• وأخيراً : لا يتم ربط Kapitan بـ Kubernetes. انه يخلق فقط الملفات. نشر التغييرات المعنية kubectl . نعطي فقط قذيفة للأوامر ليتم تنفيذها بطريقة متسقة.

هل أحتاجها؟

دعونا نوضح الأمر : ربما لا تحتاج إلى Kapitan (حتى الآن).

لكن كل هذا يتوقف على ما تحاول القيام به ومدى تعقيد نظامك.

Kapitan هي أداة استثمار قوية . استخدمها في سيناريوهات معقدة حيث يتعين عليك نشر مجموعة من التطبيقات على كومة من الكتل.

إذا كان لديك تطبيقات قياسية ، فأنت تتعلم فقط Kubernetes أو كنت سعيدًا بالفعل بسير عملك ، ثم ستعمل Helm أو البديل الحالي.

أتصور أن هيلم مناسب لـ Kubernetes ، و Kapitan يشبه الدمى .

في المنشور التالي ، سأقدم أمثلة محددة وأصف بالتفصيل المخزون. اكتب ما تريد معرفته أو ما توافق / لا توافق عليه في هذا المنشور.

شكرا لجاسك جروزيفسكي .