تقريبا. العابرة. : الإثارة التي عاشها قادة فريقنا عندما رأوا هذه المادة على مدونة IBM Cloud - وهو نوع من "امتداد" تطبيق Twelve-Factor الأسطوري - يتحدث عن نفسه. الأسئلة التي أثارها المؤلف ليست فقط عن طريق الأذن ، ولكنها حيوية حقًا ، أي ذات الصلة في الحياة اليومية. فهمهم مفيد ليس فقط لمهندسي DevOps ، ولكن أيضًا للمطورين الذين يقومون بإنشاء تطبيقات حديثة تعمل في Kubernetes.منهجية
تطبيق العوامل المعروفة
12 عبارة عن مجموعة من القواعد المحددة بوضوح لتطوير الخدمات المصغرة. يتم استخدامها على نطاق واسع لتشغيل التطبيقات وتوسيع نطاقها ونشرها. في النظام الأساسي IBM Cloud Private ، نتبع نفس المبادئ الـ 12 عند تطوير التطبيقات في حاويات. تتناول المقالة "
Kubernetes & 12-factor apps " تفاصيل استخدام هذه العوامل الـ 12 (يتم دعمها بواسطة نموذج تزامن حاوية Kubernetes).
بالتفكير في مبادئ تطوير الخدمات الميكروية في حاويات والتي تعمل تحت سيطرة Kubernetes ، توصلنا إلى الاستنتاج التالي: العوامل الـ 12 المذكورة أعلاه صحيحة تمامًا ، لكن العوامل الأخرى مهمة للغاية لتنظيم بيئة الإنتاج ، على وجه الخصوص:
- قابلية الملاحظة (ملحوظة)؛
- القدرة على التنبؤ (جدولة) ؛
- التحديث (قابلة للترقية) ؛
- الحد الأدنى من الامتيازات
- السيطرة (قابل للتدقيق) ؛
- الأمن (آمن) ؛
- قياس (قياس).
دعونا نتناول هذه المبادئ ونحاول تقييم أهميتها. للحفاظ على التوحيد ، نضيفها إلى الموجودة - وفقًا لذلك ، سنبدأ بـ XIII ...
المبدأ الثالث عشر: الملاحظة
يجب أن تقدم التطبيقات معلومات حول حالتها ومؤشراتها الحالية.قد يكون من الصعب إدارة الأنظمة الموزعة نظرًا لأن العديد من الخدمات المصغرة المدمجة في تطبيق ما. في الواقع ، يجب أن تتحرك التروس المختلفة بالتنسيق حتى تعمل الآلية (التطبيق). في حالة حدوث فشل في إحدى الخدمات المصغرة ، يجب على النظام اكتشافه تلقائيًا وتصحيحه. يوفر Kubernetes آليات إنقاذ ممتازة ، مثل
اختبارات الاستعداد
والحيوية .
من خلال مساعدتهم ، يتأكد Kubernetes من أن التطبيق جاهز لاستقبال حركة المرور. في حالة فشل الاستعداد ، يتوقف Kubernetes عن إرسال حركة المرور إلى pod حتى يظهر الاختبار التالي أن الجهاز جاهز.
لنفترض أن لدينا تطبيقًا يتكون من 3 خدمات مجهرية: الواجهة الأمامية ومنطق العمل وقاعدة البيانات. لكي يعمل التطبيق ، قبل قبول حركة المرور ، يجب أن تضمن الواجهة الأمامية أن منطق الأعمال وقواعد البيانات جاهزة. يمكن القيام بذلك باستخدام اختبار الاستعداد - يتيح لك التأكد من أن جميع التبعيات تعمل.
يوضح الرسم المتحرك أن الطلبات إلى جراب لا يتم إرسالها حتى يظهر اختبار الجاهزية استعدادها:
اختبار الاستعداد في العمل: يستخدم Kubernetes مسبار الاستعداد للتحقق مما إذا كانت القرون جاهزة لاستقبال حركة المرورهناك ثلاثة أنواع من الاختبارات: استخدام HTTP وطلبات TCP والأوامر. يمكنك التحكم في تكوين الاختبارات ، على سبيل المثال ، الإشارة إلى عدد مرات بدء التشغيل ، وعتبات النجاح / الفشل ومدة انتظار الإجابة. في حالة اختبارات الثقل ، تحتاج إلى تعيين معلمة واحدة مهمة للغاية -
initialDelaySeconds . تأكد من أن الاختبار يبدأ فقط بعد أن يكون التطبيق جاهزًا. إذا تم تعيين هذه المعلمة بشكل غير صحيح ، فسيتم إعادة تشغيل التطبيق باستمرار. إليك كيفية تنفيذها:
livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5
من خلال اختبارات حيوية ، يتحقق Kubernetes لمعرفة ما إذا كان تطبيقك قيد التشغيل. إذا كان التطبيق يعمل بشكل طبيعي ، فإن Kubernetes لا يفعل شيئًا. إذا "مات" ، فإن Kubernetes يزيل السنفرة ويبدأ واحدة جديدة في المقابل. هذا يتوافق مع احتياجات microservice عديمي الجنسية وإعادة تدويرها (
العامل التاسع ، التخلص منها ). توضح الرسوم المتحركة أدناه موقفًا يقوم فيه Kubernetes بإعادة تشغيل الجهاز بعد فشل اختبار حيوية:
اختبار حيوية في العمل: Kubernetes يتحقق ما إذا كانت القرون "على قيد الحياة" معهاالميزة الكبيرة لهذه الاختبارات هي أنه يمكنك نشر التطبيقات بأي ترتيب دون القلق بشأن التبعيات.
ومع ذلك ، وجدنا أن هذه الاختبارات ليست كافية لبيئة الإنتاج. عادةً ما يكون للتطبيقات مقاييس خاصة بها تحتاج إلى تتبع ، على سبيل المثال ، عدد المعاملات في الثانية. حدد العملاء عتبات لهم وتكوين الإخطارات. يقوم IBM Cloud Private بتعبئة هذه الفجوة من خلال مجموعة المراقبة الآمنة للغاية من Prometheus و Grafana بنظام التحكم في الوصول القائم على الدور. راجع قسم
مراقبة نظام مجموعة IBM Cloud Private لمزيد من المعلومات.
تقوم بروميثيوس بجمع البيانات المستهدفة من مقاييس نقطة النهاية. يجب أن يحدد تطبيقك مقاييس نقطة النهاية باستخدام التعليق التوضيحي التالي:
prometheus.io/scrape: 'true'
بعد ذلك ، يكتشف Prometheus تلقائيًا نقطة النهاية ويجمع المقاييس منها (كما هو موضح في الرسوم المتحركة التالية):
مجموعة من المقاييس المخصصةتقريبا. العابرة. : سيكون من الأصح تحويل الأسهم في الاتجاه المعاكس ، حيث إن Prometheus يمشي ونقاط النهاية للاستطلاعات ، بينما يأخذ Grafana نفسه البيانات من Prometheus ، لكن بمعنى التوضيح العام ، هذا ليس بالغ الأهمية.المبدأ الرابع عشر: القدرة على التنبؤ
يجب أن توفر التطبيقات إمكانية التنبؤ بمتطلبات الموارد.تخيل أن الدليل قد اختار فريقك لتجربة مشروع Kubernetes. لقد عملت بجد لتهيئة بيئة مناسبة. والنتيجة هي تطبيق يوضح وقت الاستجابة المثالي والأداء. ثم انضم فريق آخر إلى العمل. ابتكرت تطبيقها وأطلقته في نفس البيئة. بعد إطلاق التطبيق الثاني ، انخفض أداء أول تطبيق فجأة. في هذه الحالة ، يجب البحث عن سبب هذا السلوك في موارد الحوسبة (وحدة المعالجة المركزية والذاكرة) المتاحة للحاويات الخاصة بك. احتمال كبير من نقصهم. السؤال الذي يطرح نفسه: كيف نضمن تخصيص موارد الحوسبة التي يحتاجها التطبيق؟
Kubernetes لديه خيار ممتاز يسمح لك بتعيين الحد الأدنى من الموارد وتعيين قيود للحاويات. الحد الأدنى مضمون. إذا كانت الحاوية تتطلب موردًا ، فإن Kubernetes تقوم بتشغيله فقط على المضيف الذي يمكن لهذا المورد توفيره. من ناحية أخرى ، يضمن الحد الأعلى ألا تتجاوز قيمة الحاوية أبدًا قيمة معينة.
الحد الأدنى والقيود المفروضة على الحاوياتيعرض مقتطف شفرة YAML التالي ضبط موارد الحوسبة:
resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"
تقريبا. العابرة. : لمزيد من المعلومات حول توفير الموارد في Kubernetes والطلبات والحدود ، راجع تقريرنا الأخير ومراجعته ، " Autoscaling وإدارة الموارد في Kubernetes " ، وكذلك وثائق K8s .هناك فرصة أخرى مثيرة للاهتمام للمسؤولين في بيئة الإنتاج وهي تحديد الحصص
لمساحة الاسم . إذا تم تعيين الحصة النسبية ، فلن تقوم Kubernetes بإنشاء حاويات لم يتم تعريف الطلب / الحدود في مساحة الاسم هذه. يمكن العثور على مثال لإعداد الحصص لمساحة الاسم في الشكل أدناه:
حصص لمساحات الأسماءالمبدأ الخامس عشر. تجددها
يجب على التطبيقات تحديث تنسيقات البيانات من الأجيال السابقة.غالبًا ما تكون هناك حاجة إلى تصحيح تطبيق إنتاج عامل من أجل التخلص من مشكلة عدم الحصانة أو توسيع الوظيفة. من المهم أن يتم التحديث دون مقاطعة في العمل. يوفر Kubernetes
آلية للتحديث المستمر تتيح لك تحديث التطبيق الخاص بك دون توقف. باستخدام هذه الآلية ، يمكنك التحديث عن طريق جراب في وقت واحد دون إيقاف الخدمة بأكملها. فيما يلي عرض تخطيطي لهذه العملية (عليه يتم تحديث التطبيق إلى الإصدار الثاني):
مثال على وصف YAML المقابل:
minReadySeconds: 5 strategy: # , type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
انتبه إلى
maxSurge و
maxSurge :
maxUnavailable - معلمة اختيارية تحدد الحد الأقصى لعدد القرون التي قد لا تكون متاحة أثناء عملية التحديث. على الرغم من أنها اختيارية ، إلا أنها لا تزال تستحق تحديد قيمة محددة لضمان توفر الخدمة ؛maxSurge هو معلمة اختيارية أخرى ولكن حرجة. يقوم بتعيين الحد الأقصى لعدد القرون التي يمكن إنشاؤها بما يزيد عن العدد المطلوب.
المبدأ السادس عشر: الامتيازات الدنيا
يجب أن تعمل الحاويات مع الحد الأدنى من الامتيازات.يبدو هذا متشائمًا ، لكن يجب أن تفكر في كل دقة في الحاوية على أنها نقطة ضعف محتملة (انظر الشكل). على سبيل المثال ، إذا تم تشغيل الحاوية كجذر ، فيمكن لأي شخص لديه حق الوصول إليها حقن عملية ضارة هناك. يوفر Kubernetes
سياسة أمان Pod (PSP) لتقييد الوصول إلى نظام الملفات ، ومنفذ المضيف ، وقدرات Linux ، وأكثر من ذلك. يقدم IBM Cloud Private مجموعة جاهزة من PSPs ترتبط بالحاويات عندما يتم توفيرها في مساحة الاسم. لمزيد من المعلومات ، راجع
استخدام مساحات الأسماء مع سياسات تأمين Pod .
كل القرار هو ناقل هجوم محتملالمبدأ السابع عشر: التحكم
تحتاج إلى معرفة من وماذا وأين ومتى لجميع العمليات الحيوية المهمة.تعتبر إمكانية التحكم ضرورية لأي عملية مع مجموعة أو تطبيق Kubernetes. على سبيل المثال ، إذا كان التطبيق يعالج معاملات بطاقات الائتمان ، فستحتاج إلى تمكين التدقيق من أجل الحصول على تتبع تحكم لكل معاملة. يستخدم IBM Cloud Private
اتحاد بيانات التدقيق السحابي (CADF) المعياري في الصناعة ، والذي يعد ثابتًا للتطبيقات السحابية المحددة. لمزيد من المعلومات ، راجع
تدوين التسجيل في IBM Cloud Private .
حدث CADF يحتوي على البيانات التالية:
initiator_id - معرف المستخدم الذي أجرى العملية ؛target_uri - الهدف CADF URI (على سبيل المثال: data / security / project) ؛action - action المطلوب تنفيذه ، وعادةً ما يكون operation: resource_type .
المبدأ الثامن عشر: الأمن (تحديد الهوية ، الشبكة ، النطاق ، الشهادات)
من الضروري حماية التطبيق والموارد من الغرباء.هذا البند يستحق مقالة منفصلة. يكفي القول أن تطبيقات الإنتاج تحتاج إلى حماية شاملة. يتخذ IBM Cloud Private التدابير التالية لضمان أمان بيئات الإنتاج:
- المصادقة: التحقق من الهوية ؛
- إذن: التحقق من وصول المستخدم المصدق ؛
- إدارة الشهادات: العمل باستخدام الشهادات الرقمية ، بما في ذلك الإنشاء والتخزين والتجديد ؛
- حماية البيانات: ضمان أمن البيانات المرسلة والمخزنة ؛
- أمن الشبكة وعزلها: منع الوصول إلى الشبكة من قبل المستخدمين والعمليات غير المصرح بها ؛
- مستشار الضعف: تحديد نقاط الضعف في الصور ؛
- مستشار الطفرة: كشف الطفرات في الحاويات.
لمزيد من المعلومات ، راجع
دليل الأمن الخاص بـ IBM Cloud .
من الجدير بالذكر هو مدير الشهادة.
تعتمد هذه الخدمة في IBM Cloud Private على مشروع
Jetstack مفتوح
المصدر . يتيح لك مدير الشهادات إصدار وإدارة الشهادات للخدمات التي تعمل على IBM Cloud Private. وهو يدعم كل من الشهادات العامة والشهادات الموقعة ذاتيا ، ويتكامل بشكل كامل مع التحكم في الوصول إلى
kubectl والدور القائم على الدور.
المبدأ التاسع عشر: قابلية القياس
يجب أن يكون استخدام التطبيق قابلاً للقياس لأغراض الحصص والتسويات بين الإدارات.في النهاية ، يتعين على الشركات دفع تكاليف تكنولوجيا المعلومات (انظر الشكل أدناه). يجب أن تكون موارد الحوسبة المخصصة لحاويات التشغيل قابلة للقياس ، ويجب أن تكون المؤسسات التي تستخدم هذه المجموعة قابلة للمساءلة. تأكد من اتباع المبدأ الرابع عشر - القدرة على التنبؤ. يقدم IBM Cloud Private
خدمة محاسبة تجمع البيانات حول موارد الحوسبة لكل حاوية وتجمعها على مستوى مساحة الاسم لإجراء مزيد من العمليات الحسابية (كجزء من عمليات الاسترجاع أو إعادة تحميل التكاليف).
يجب أن يكون استخدام التطبيق قابلاً للقياس.استنتاج
آمل أن تكونوا قد أحببت الموضوع الذي أثيرت في هذه المقالة ، ولاحظت العوامل التي تستخدمها بالفعل وفكرت في تلك التي لا تزال على الهامش.
لمزيد من المعلومات ، أوصي بأن تتعرف على
تسجيل أدائنا في KubeCon 2019 في شنغهاي. في ذلك ، ناقش
أنا و
مايكل إلدر 12 + 7 مبادئ لتنسيق الحاويات القائم على Kubernetes.
PS من المترجم
اقرأ أيضًا في مدونتنا: