على مدى السنوات الخمس الماضية، أبحرت في المياه المضطربة أحيانًا لإدارة مجموعات Kubernetes. لقد منحتني هذه الرحلة المليئة بالتحديات والاكتشافات فهمًا عميقًا لهذه التكنولوجيا المتطورة وأوجهها المتعددة. في هذه المقالة، أود أن أشارككم أهم عشرة دروس تعلمتها كمدير لمجموعة Kubernetes. تشمل هذه الدروس مجموعة من المواضيع، بدءًا من إدارة البنية التحتية الأساسية وحتى تحسين عمليات النشر، وتتضمن أفضل الممارسات لضمان قابلية التوسع وأمان مجموعاتك. سواء كنت جديدًا في عالم Kubernetes أو خبيرًا متمرسًا، ستزودك هذه الأفكار بمنظور غني حول كيفية إدارة مجموعات Kubernetes الخاصة بك بشكل فعال. دعونا نغوص معًا في هذه التعاليم، ثمار ثلاث سنوات من التجارب والنجاحات والتحديات التي تم التغلب عليها. الدرس 1: استخدام Kubernetes في السحابة ما لم يكن هناك قيد شديد، فليس من الضروري إدارة البنية التحتية الأساسية لـ Kubernetes بنفسك. ستقضي وقتك في تصحيح الأخطاء التي لا تضيف قيمة إلى عملك. أن تكون خبيرًا في kube-api، وkube-apiserver، وkubelet، وما إلى ذلك، وkube-proxy، وما إلى ذلك، يعد أمرًا رائعًا، ولكن الاضطرار إلى الحفاظ على ذلك بنفسك يوميًا لا يضيف قيمة. لا تحتاج إلى أن تكون خبيرًا في هذه المفاهيم لإدارة المجموعة بفعالية. قم بتفويض هذه المهمة ذات المستوى المنخفض لمقدمي الخدمات السحابية (AWS، وAzure، وGCP، وOVH، وما إلى ذلك) الذين يقومون بذلك بشكل أفضل منك. في HK-TECH، اخترنا AWS ومجموعة EKS (ECS ليست Kubernetes!). الدرس 2: نشر البنية الأساسية المتعلقة بـ Kubernetes بالكامل باستخدام التعليمات البرمجية. لا ينبغي تنفيذ أي جزء من مجموعتك يدويًا على وحدة التحكم، ولا حتى علامة بسيطة. تجنب بشكل خاص عقلية “لقد أصلحت المشكلة بسرعة على وحدة التحكم، وسأقوم بتحديث الكود لاحقًا”. الأسطورة: لن تفعل ذلك أبدًا. الدرس 3: تجنب الإفراط في استخدام مخططات الدفة التي لا يمكنك التحكم فيها بشكل كامل. نعم، إنها رائعة، وتعمل بسرعة، ولا يتعين عليك أن تنشغل بكتابة YAMLs الخاصة بك، إلا في اليوم الذي يعطل فيه التحديث كل شيء. إذا كنت كسولًا أو ليس لديك وقت كافٍ، على الأقل ابذل جهدًا لفهم كل متغير في ملفvalues.yaml وتجنب القيم الافتراضية. في HK-Tech، القاعدة هي عدم وجود مخطط للخوذة؛ وفي أسوأ الأحوال، نقوم باسترداد القوالب. الدرس 4: Kubernetes لا يحب الرفع والتحويل. لذا، ستحتاج إلى استخدام تطبيقاتك القديمة لإعادة تصميمها لتكون متوافقة مع السحابة. لا يعود الأمر إلى Kube للتكيف مع تطبيقك، بل يجب على التطبيق أن يتكيف. إذا لم تكن في وضع يسمح لك بإعادة ترميز تطبيقاتك، فربما عليك الالتزام بأجهزة VM القديمة الخاصة بك. الدرس الخامس: شبكة أم لا شبكة؟ لا تقم بتثبيت شبكة الخدمة إذا لم تكن بحاجة إليها. كيف تعرف إذا كنت في حاجة إليها؟ اسأل نفسك سؤالين: هل تتواصل التطبيقات الموجودة في مجموعتي مع بعضها البعض؟ هل يجب تأمين التبادلات بين التطبيقات الموجودة في مجموعتي؟ إذا كانت الإجابة بنعم على كليهما، فقد يكون تثبيت شبكة الخدمة مفيدًا. ليس لدي توصية محددة. بشكل عام، كلها متشابهة. الدرس السادس: تجنب مضاعفة الأدوات. يقدم Kubernetes الكثير من الأدوات الإضافية التي تعد بالجبال والمعجزات لإدارة مجموعاتك بشكل أفضل: argocd، lens، k9s، keda، krew، kubectx، kubens، kail… تجنب تكديسها، kubectl القديم الجيد يلبي 90% من الاحتياجات. أنا شخصياً أقتصر على kubectx وkubens وk9s لتحقيق مكاسب حقيقية في إدارة مجموعاتي. الدرس 7: يجب عليك دائمًا تحديد حدود الموارد (الذاكرة ووحدة المعالجة المركزية) المخصصة للبودات الخاصة بك. سيمنع ذلك خطر قيام تطبيق سيئ الترميز أو التهيئة بالتهام جميع موارد المجموعة الخاصة بك وإزالة تطبيقاتك واحدًا تلو الآخر لأن بعض القرون جشعة للغاية. إنه أيضًا أحد الأسباب التي تجعلك حذرًا من المخططات الرئيسية والتحقق دائمًا من الكود المصدري للبيانات الموجودة خلف العبوة الجميلة. الدرس الثامن: فكر في عديمي الجنسية. من الناحية المثالية، من الأفضل تجنب استمرار البيانات في كبسولاتك. إذا لم يكن من الممكن خلاف ذلك لسبب ما، ففضل التثبيت على NAS بدلاً من الأقراص. وإلا، فسوف تتفاجأ بشكل غير سار عندما تجد أن بعض القرون الموجودة في عملية النشر الخاصة بك لا تتمتع بإمكانية الوصول إلى الموارد المستمرة. نعم، لا يمكن تركيب القرص الصلب إلا على عقدة واحدة، لذلك إذا تم توزيع البودات الخاصة بك عبر عقد متعددة، فسوف ترى البودات الموجودة على نفس العقدة نفس البيانات ولكن ليس تلك الموجودة على العقد الأخرى. مع التركيب من نوع NAS مثل EFS، سوف تتجنب هذه المشكلة. الدرس 9: تكوين HPA (المقياس التلقائي للجراب الأفقي). إذا كنت تريد التوقف عن العمل كما كان الحال في العالم القديم والاستفادة من قدرة Kubernetes على إدارة استخدام الموارد تلقائيًا وفقًا للطلب، فستحتاج إلى تكوين HPA في جميع مشاريع التطبيقات الخاصة بك. (حد آخر لمخططات الدفة، حيث غالبًا ما يكون غائبًا جدًا للأسف). الدرس العاشر: لا تخف من التغيير. في المتوسط، يجب أن تخطط لإجراء ثلاث ترقيات لإصدار مجموعتك سنويًا، أي تحديث واحد تقريبًا كل أربعة أشهر. تتسم بعض التحديثات بالشفافية، ولكن غالبًا ما تكون هناك تغييرات ذات تأثيرات. للاستعداد بشكل أفضل لهذه التحديثات، أوصي بقراءة ملاحظات الإصدار وإعادة قراءتها ومراجعة تجارب الأشخاص الذين قاموا بالتحديث قبلك. ما أوصي به وما قمنا بتنفيذه في HK-TECH هو دائمًا أن يكون إصدارًا واحدًا أقل من الإصدار الأحدث (ما لم تكن هناك تغييرات أمنية).
كوبيرنيتيس سعيد!
