أفضل ممارسات Kubernetes. اصنع حاويات صغيرة

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



على الرغم من أن هذه التقنية رائعة للبدء ، إلا أن استخدام الصور الأساسية افتراضيًا يمكن أن يؤدي إلى عمل غير آمن مع صور كبيرة مليئة بالثغرات.

بالإضافة إلى ذلك ، تستخدم معظم الصور في Docker Debian أو Ubuntu كصورة أساسية ، وعلى الرغم من أن هذا يوفر توافقًا ممتازًا وتكييفًا سهلاً (يأخذ ملف Docker سطرين فقط من التعليمات البرمجية) ، يمكن للصور الأساسية إضافة مئات الميغابايت من الحمل الإضافي إلى حاويتك. على سبيل المثال ، يستغرق ملف node.js البسيط لتطبيق Go hello-world حوالي 700 ميغا بايت ، في حين أن حجم التطبيق نفسه لا يتجاوز سوى بضعة ميغا بايت.



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

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



بشكل افتراضي ، في Docker ، حجم العقدة الأساسية: 8 صورة هي 670 ميغابايت ، وحجم العقدة: 8-alpine هو 65 ميغابايت فقط ، أي 10 مرات أصغر. سيؤدي استخدام الصورة الأساسية الأصيلة في جبال الألب إلى تقليل حجم الحاوية بشكل كبير. Alpine هو توزيع صغير وخفيف الوزن لنظام Linux يحظى بشعبية كبيرة بين مستخدمي Docker لأنه متوافق مع العديد من التطبيقات ، مع الحفاظ على الحجم الصغير للحاويات. على عكس صورة "عقدة" Docker القياسية ، تزيل "node: alpine" العديد من الملفات والبرامج المساعدة ، تاركة فقط تلك التي تكفي لتشغيل التطبيق الخاص بك.

للتبديل إلى صورة أساسية أصغر ، ما عليك سوى تحديث ملف Docker لبدء العمل مع الصورة الأساسية الجديدة:



الآن ، على عكس صورة onbuild القديمة ، تحتاج إلى نسخ الرمز الخاص بك في الحاوية وتثبيت أي تبعيات. في ملف Docker الجديد ، تبدأ الحاوية بالعقدة: صورة جبال الألب ، ثم تنشئ دليلًا للكود ، وتثبت التبعيات باستخدام مدير حزم NPM ، وأخيرًا تبدأ server.js.



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



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



يتم إنشاء الكود في الحاوية الأولى وتجميعه. بعد ذلك ، يتم تجميع الكود المترجم في الحاوية النهائية بدون المترجمات والأدوات اللازمة لتجميع هذا الكود. دعنا نتخطى تطبيق Go من خلال هذه العملية. أولاً ، سننتقل من صورة onbuild إلى Alpine Linux.



في ملف Docker الجديد ، تبدأ الحاوية بـ golang: صورة جبال الألب. ثم يقوم بإنشاء دليل للرمز ، ونسخه إلى رمز المصدر ، وإنشاء رمز المصدر هذا وتشغيل التطبيق. هذه الحاوية أصغر بكثير من الحاوية الموجودة في البناء ، لكنها لا تزال تحتوي على المترجم وأدوات Go الأخرى التي لا نحتاجها حقًا. لذلك دعونا مجرد استخراج البرنامج المترجمة ووضعه في الحاوية الخاصة بنا.



قد تلاحظ شيئًا غريبًا في ملف Docker هذا: يحتوي على سطرين من FROM. يبدو القسم الأول المكون من 4 أسطر تمامًا مثل ملف Docker السابق ، باستثناء أنه يستخدم الكلمة الأساسية AS لتسمية هذه الخطوة. في القسم التالي ، هناك خط FROM جديد يسمح لك ببدء صورة جديدة ، وبدلاً من golang: صورة alpine ، سنستخدم Raw alpine كصورة أساسية.

لا يحتوي Raw Alpine Linux على أي شهادات SSL مثبتة ، مما سيؤدي إلى فشل معظم مكالمات API HTTPS ، لذا دعنا نثبت بعض شهادات الجذر CA.

والآن الأكثر إثارة للاهتمام: لنسخ الشفرة المترجمة من الحاوية الأولى إلى الحاوية الثانية ، يمكنك ببساطة استخدام الأمر COPY الموجود في السطر الخامس من القسم الثاني. ستقوم بنسخ ملف تطبيق واحد فقط ولن تؤثر على أدوات Go المساعدة. سيحتوي ملف Docker الجديد متعدد الخطوات على صورة حاوية بحجم 12 ميغابايت فقط ، في حين كانت صورة الحاوية الأصلية 700 ميجابايت ، وهذا فرق كبير!
وبالتالي ، فإن استخدام الصور الأساسية الصغيرة وأنماط البناء هي طرق رائعة لإنشاء حاويات أصغر بكثير بدون الكثير من العمل.
من الممكن أنه اعتمادًا على رصة التطبيق ، هناك طرق إضافية لتقليل حجم الصورة والحاوية ، ولكن هل تتمتع الحاويات الصغيرة بالفعل بميزة قابلة للقياس؟ دعونا نلقي نظرة على جانبين حيث تكون الحاويات الصغيرة فعالة للغاية - الأداء والأمن.

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



ستقوم Docker بتخزين الطبقات مؤقتًا ، لذلك ستكون البنيات اللاحقة سريعة جدًا. ومع ذلك ، في العديد من أنظمة CI التي يتم استخدامها لبناء واختبار الحاويات ، لا يتم تخزين الطبقات مؤقتًا ، لذلك هناك توفير كبير في الوقت. كما ترون ، فإن وقت بناء حاوية كبيرة ، اعتمادًا على قوة جهازك ، من 34 إلى 54 ثانية ، وعند استخدام حاوية مخفضة بنمط البناء ، من 23 إلى 28 ثانية. بالنسبة للعمليات من هذا النوع ، ستكون مكاسب الإنتاجية 40-50٪. لذا فكر فقط في عدد المرات التي تقوم فيها بإنشاء واختبار التعليمات البرمجية الخاصة بك.

بعد بناء الحاوية ، تحتاج إلى إدراج صورتها (دفع صورة الحاوية) في سجل الحاوية من أجل استخدام Kubernetes في مجموعتك. أوصي باستخدام سجل حاويات Google.



باستخدام Google Container Registry (GCR) ، لا تدفع إلا مقابل سعة التخزين الأولية والشبكة ، ولا توجد رسوم إضافية لإدارة الحاويات. إنه سري وآمن وسريع جدا. يستخدم GCR العديد من الحيل لتسريع عملية السحب. كما ترى ، فإن إدراج صورة حاوية Docker Container Image باستخدام go: onbuild ، اعتمادًا على أداء الكمبيوتر ، سيستغرق من 15 إلى 48 ثانية ، وستستغرق نفس العملية مع حاوية أصغر من 14 إلى 16 ثانية ، وبالنسبة للأجهزة الأقل كفاءة ، تزداد الميزة في سرعة التشغيل بمقدار ثلاث مرات. بالنسبة للأجهزة الكبيرة ، فإن الوقت هو نفسه تقريبًا ، نظرًا لأن GCR يستخدم ذاكرة التخزين المؤقت العالمية لقاعدة بيانات مشتركة للصور ، أي أنك لا تحتاج إلى تنزيلها على الإطلاق. في كمبيوتر منخفض الطاقة ، وحدة المعالجة المركزية هي اختناق ،لذلك ، فإن ميزة استخدام الحاويات الصغيرة هنا أكثر واقعية.

إذا كنت تستخدم GCR ، أوصي بشدة باستخدام Google Container Builder (GCB) كجزء من نظام البناء لديك.



كما ترون ، فإن استخدامه يسمح لك بتحقيق نتائج أفضل بكثير في تقليل مدة عملية Build + Push من حتى على آلة منتجة - في هذه الحالة ، فإن عملية بناء وإرسال الحاويات إلى المضيف أسرع مرتين تقريبًا. بالإضافة إلى ذلك ، تحصل كل يوم على 120 دقيقة من التجميع مجانًا ، وهو ما يلبي في معظم الحالات احتياجات إنشاء الحاويات.

بعد ذلك يأتي أهم مقياس للأداء - السرعة التي تسترد بها حاويات السحب أو تقوم بتنزيلها. وإذا كنت لا تهتم حقًا بالوقت الذي تقضيه في عملية الدفع ، فإن مدة عملية السحب تؤثر بشكل خطير على الأداء العام للنظام. افترض أن لديك مجموعة من ثلاث عقد وتعطل أحدها. إذا كنت تستخدم نظام إدارة ، مثل Google Kubernetes Engine ، فسيقوم تلقائيًا باستبدال العقدة الخاملة بأخرى جديدة. ومع ذلك ، ستكون هذه العقدة الجديدة فارغة تمامًا ، وسيتعين عليك سحب جميع حاوياتك إليها لتشغيلها. إذا كانت عملية السحب طويلة بما يكفي ، فستعمل الكتلة الخاصة بك طوال هذا الوقت بأداء أقل.

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



ألق نظرة على المقارنة: تستغرق عملية السحب عند العمل مع حاويات صغيرة وقتًا أقل من 4 إلى 9 مرات حسب قوة الماكينة مقارنة بنفس العملية باستخدام go: onbuild. يؤدي استخدام الصور الأساسية الشائعة لحاويات الحاويات الصغيرة إلى تسريع الوقت والسرعة اللذين يمكن بهما نشر عقد Kubernetes الجديدة والوصول إلى الإنترنت.

دعونا نلقي نظرة على قضية الأمن. يُعتقد أن الحاويات الصغيرة أكثر أمانًا من الحاويات الكبيرة لأنها تحتوي على سطح هجوم أصغر. هل هي حقا؟ واحدة من أكثر الميزات المفيدة في Google Container Registry هي القدرة على فحص حاوياتك تلقائيًا بحثًا عن نقاط الضعف. قبل بضعة أشهر ، قمت بإنشاء حاويات داخلية ومتعددة المراحل ، لذلك دعونا نرى ما إذا كانت هناك أي ثغرات هناك.



كانت النتيجة مذهلة: تم العثور على 3 ثغرات متوسطة فقط في حاوية صغيرة ، و 16 ثغرة حرجة و 376 ثغرة أخرى في حاوية كبيرة. إذا نظرت إلى محتويات حاوية كبيرة ، يمكنك أن ترى أن معظم مشاكل الأمان لا علاقة لها بتطبيقنا ، ولكنها تتعلق بالبرامج التي لا نستخدمها حتى. لذلك عندما يتحدث الناس عن مساحة كبيرة للهجمات ، فإنهم يعنون ذلك بالضبط.



الاستنتاج واضح: قم بإنشاء حاويات صغيرة لأنها توفر فوائد حقيقية في أداء وأمان نظامك.

أفضل ممارسات Kubernetes. منظمة Kubernetes مع مساحة الاسم

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟