ملاحظة perev. : مؤلف المقالة الأصلية هو Théo Chamley ، مهندس Google Cloud Architect. في هذا المنشور لمدونة Google Cloud ، قدم مقتطفًا موجزًا من إدارة شركته الأكثر تفصيلاً ، بعنوان " أفضل الممارسات لتشغيل الحاويات ". في ذلك ، جمع خبراء Google أفضل الممارسات لتشغيل الحاويات في سياق استخدام Google Kubernetes Engine وليس فقط لمس مجموعة واسعة من المواضيع: من الأمان إلى المراقبة وتدوين اليومية. لذا ، ما هي ممارسات الحاويات الأكثر أهمية لجوجل؟
يُعد محرك Kubernetes (خدمة قائمة على Kubernetes لتشغيل التطبيقات المعبأة على Google Cloud - ترجمة. تقريبًا ) أحد أفضل الطرق لتشغيل أعباء العمل التي تحتاج إلى تغيير الحجم.
ستضمن Kubernetes التشغيل السلس لمعظم التطبيقات إذا كانت في حاويات. ولكن إذا كنت تريد أن يكون التطبيق سهل الإدارة وترغب في الاستفادة الكاملة من Kubernetes ، يجب عليك اتباع أفضل الممارسات. ستعمل على تبسيط تشغيل التطبيق ومراقبته وتصحيحه ، بالإضافة إلى تحسين الأمان.
في هذه المقالة ، سنراجع قائمة بما تحتاج إلى معرفته والقيام به من أجل الأداء الفعال للحاويات في Kubernetes. يجب على أولئك الذين يرغبون في الخوض في التفاصيل قراءة
أفضل الممارسات لتشغيل مواد
الحاويات ، بالإضافة إلى الانتباه إلى
منشور تجميع الحاويات
السابق .
1. استخدم آليات الحاويات الأصلية للتسجيل
إذا كان التطبيق يعمل في مجموعة Kubernetes ، فلن تكون هناك حاجة للكثير من السجلات. من المحتمل أن يكون نظام تسجيل مركزي قد تم دمجه بالفعل في المجموعة التي تستخدمها. في حالة استخدام محرك
Kubernetes ، فإن
Stackdriver Logging مسؤول عن ذلك.
( ملاحظة : إذا كنت تستخدم التثبيت الخاص بك من Kubernetes ، فإننا نوصيك بإلقاء نظرة فاحصة على حل Open Source الخاص بنا - loghouse .) لا تعقد حياتك واستخدم الآليات الأصلية لتسجيل حاويات التسجيل. اكتب السجلات في stdout و stderr - سيتم استلامها وحفظها وفهرستها تلقائيًا.
إذا كنت ترغب في ذلك ، يمكنك أيضًا كتابة السجلات
بتنسيق JSON . هذا النهج يجعل من السهل إضافة البيانات الوصفية إليها. ومعهم في Stackdriver Logging سيتمكنون من البحث في السجلات باستخدام هذه البيانات الوصفية.
2. تأكد من أن الحاويات عديمة الجنسية وغير قابلة للتغيير
لكي تعمل الحاويات بشكل صحيح في مجموعة Kubernetes ، يجب أن تكون عديمة الحالة وغير قابلة للتغيير. عند استيفاء هذه الشروط ، ستتمكن Kubernetes من القيام بعملها ، وإنشاء وتدمير كيانات التطبيق عند الضرورة.
تعني الحالة
عديمة الحالة أنه يتم تخزين أي حالة (بيانات ثابتة من أي نوع) خارج الحاوية. لهذا ، اعتمادًا على الاحتياجات ، يمكن مشاركة أنواع مختلفة من التخزين الخارجي:
Cloud Storage ،
Persistent Disks ،
Redis ،
Cloud SQL أو غيرها من قواعد البيانات المدارة.
( ملاحظة ترجمة : اقرأ المزيد عن هذا في مقالتنا " عوامل تشغيل Kubernetes: كيفية تشغيل تطبيقات Stateful ").غير قابل للتغيير يعني أن الحاوية لن يتم تعديلها خلال عمرها: لا توجد تحديثات أو تصحيحات أو تغييرات في التكوين. إذا كنت بحاجة إلى تحديث رمز التطبيق أو تطبيق التصحيح ، فقم بإنشاء صورة جديدة ونشرها. يوصى بنقل تكوين الحاوية (منفذ للاستماع وخيارات
وقت التشغيل وما إلى ذلك) إلى الخارج - في
Secrets and
ConfigMaps . يمكن تحديثها دون الحاجة إلى إنشاء صورة حاوية جديدة. يمكنك استخدام
Cloud Build لإنشاء خطوط الأنابيب بسهولة مع تجميع الصور.
( ملاحظة : نستخدم أداة dapp مفتوحة المصدر لهذا الغرض.)
مثال على تحديث تهيئة النشر في Kubernetes باستخدام ConfigMap المركب في حوامل كتهيئة3. تجنب الحاويات المميزة
لا تشغل التطبيقات كجذر على خوادمك ، أليس كذلك؟ إذا اخترق أحد المهاجمين التطبيق ، فسيتمكن من الوصول إلى الجذر. تنطبق نفس الاعتبارات على عدم تشغيل الحاويات المميزة. إذا كنت ترغب في تغيير الإعدادات على المضيف ، يمكنك منح
القدرات الخاصة بالحاوية باستخدام خيار
securityContext في Kubernetes. إذا كنت بحاجة إلى تعديل
sysctls ، فإن Kubernetes لديه
تعليق توضيحي منفصل لذلك. بشكل عام ، حاول تعظيم استخدام
حاويات التهيئة و
sidecar لأداء مثل هذه العمليات المميزة. لا يحتاجون إلى إمكانية الوصول لحركة المرور الداخلية أو الخارجية.
إذا كنت تدير مجموعة ، يمكنك استخدام
سياسة أمان Pod لتقييد استخدام الحاويات ذات الامتيازات.
4. تجنب التشغيل كجذر
لقد قلنا بالفعل عن الحاويات المميزة ، ولكن سيكون من الأفضل إذا قمت ، بالإضافة إلى ذلك ، بعدم تشغيل التطبيقات داخل الحاوية كجذر. إذا عثر أحد المهاجمين على ثغرة بعيدة مع القدرة على تنفيذ التعليمات البرمجية في تطبيق بامتيازات الجذر ، وبعد ذلك يمكنه الخروج من الحاوية من خلال ثغرة غير معروفة حتى الآن ، فسيحصل على الجذر على المضيف.
أفضل طريقة لتجنب ذلك هي عدم تشغيل أي شيء كجذر في المقام الأول. للقيام بذلك ، يمكنك استخدام توجيه
USER في ملف
Dockerfile أو
runAsUser في Kubernetes. يمكن أيضًا لمسؤول نظام المجموعة تكوين التنفيذ باستخدام
سياسة أمان Pod .
5. تسهيل مراقبة التطبيق.
مثل التسجيل ، تعد المراقبة جزءًا لا يتجزأ من إدارة التطبيق. يعد
Prometheus أحد حلول المراقبة الشائعة في مجتمع Kubernetes ، وهو نظام يكتشف تلقائيًا القرون والخدمات التي تتطلب المراقبة.
( ملاحظة : انظر أيضًا تقريرنا التفصيلي حول المراقبة باستخدام Prometheus و Kubernetes.) Stackdriver قادر على مراقبة مجموعات Kubernetes ويتضمن نسخته الخاصة من Prometheus لمراقبة التطبيقات.
لوحة معلومات Kubernetes في Stackdriverيتوقع Prometheus من التطبيق إعادة توجيه المقاييس إلى نقطة نهاية HTTP. تتوفر
مكتبات عميل Prometheus لهذا الغرض. تستخدم أدوات أخرى مثل
OpenCensus و
Istio نفس التنسيق.
6. جعل الحالة الصحية للتطبيق متاحة.
إدارة التطبيق في الإنتاج مدعومة بقدرته على إبلاغ حالته إلى النظام بأكمله. هل التطبيق يعمل؟ هل هذا جيد؟ هل هو جاهز لاستقبال حركة المرور؟ كيف يتصرف؟ الطريقة الأكثر شيوعًا لحل هذه المشكلة هي تنفيذ
الفحوصات الصحية . لدى Kubernetes نوعان:
تحقيقات الحيوية والاستعداد .
بالنسبة إلى تحقيق مدى الحياة ، يجب أن يكون للتطبيق نقطة نهاية HTTP تُرجع استجابة "200 OK" إذا كانت تعمل وتم اعتماد تبعياتها الرئيسية. بالنسبة لمسبار الجاهزية
(تحقق من الجاهزية للخدمة) ، يجب أن يكون للتطبيق نقطة نهاية HTTP مختلفة ، ويعيد الرد "200 OK" إذا كان التطبيق في حالة جيدة ، ويتم إكمال خطوات التهيئة ولا يؤدي أي طلب صحيح إلى حدوث خطأ. ستوجه Kubernetes حركة المرور فقط إلى الحاوية إذا كان التطبيق جاهزًا وفقًا لهذه الفحوصات. يمكن الجمع بين نقطتي نهاية إذا لم يكن هناك فرق بين الحيوية والاستعداد.
لمزيد من المعلومات ، راجع المقالة ذات الصلة بقلم Sandeep Dinesh ، محامي مطوري Google: "
أفضل ممارسات Kubernetes: إعداد الفحوصات الصحية باستخدام تحقيقات الاستعداد والحيوية ".
7. اختر بعناية نسخة الصورة
تستخدم معظم الصور العامة والخاصة نظام وضع علامات مشابه لذلك الموضح في
أفضل الممارسات لبناء الحاويات . إذا كانت الصورة تستخدم نظامًا قريبًا من
الإصدارات الدلالية ، فيجب أن تفكر في تفاصيل وضع العلامات. على سبيل المثال ، يمكن أن تنتقل العلامة
latest غالبًا من صورة إلى صورة - لا يمكنك الاعتماد عليها إذا كنت بحاجة إلى تركيبات وتركيبات يمكن التنبؤ بها وقابلة للتكرار.
يمكنك استخدام علامة
XYZ (تكون دائمًا دون تغيير تقريبًا) ، ولكن في هذه الحالة ، تتبع جميع التصحيحات والتحديثات للصورة. إذا كانت صورتك تحتوي على علامة
XY ، فهذا خيار وسطى جيد. باختياره ، تتلقى تصحيحات تلقائيًا وتعتمد في نفس الوقت على إصدار ثابت من التطبيق.
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: