فهم نماذج Kubernetes: الأنواع والتكوين وأفضل الممارسات

المصدر تدور



هذه المقالة حول تكوين تحقيقات الاستعداد والصحة وبدء التشغيل لاكتشاف الوحدات غير الصحية والعمل معها كما ترجمها فريق Kubernetes aaS .

لماذا يلزم التحقق من صحة Kubernetes

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



بشكل افتراضي ، يراقب Kubernetes دورة حياة الكبسولة ويبدأ في توجيه حركة المرور إلى الحاوية عندما تنتقل الحاويات من معلق إلى تم بنجاح. يراقب Kubelet أيضًا أعطال التطبيق ويعيد تشغيل الوحدة لاستردادها.



يعتقد العديد من المطورين أن هذا الإعداد الأساسي كافٍ ، خاصةً عندما يتم تكوين التطبيق داخل الوحدة النمطية باستخدام مديري العمليات مثل PM2 لـ Node.js.



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



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



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



في هذه المقالة ، يناقش المؤلف أنواعًا مختلفة من التحقيقات ، بالإضافة إلى أفضل الممارسات والأدوات لاكتشاف عمليات النشر التي بها مشكلات تكوين محتملة.

تحقيقات Kubernetes

يدعم Kubernetes تحقيقات الجاهزية والصحة للإصدارات ≤ 1.15. تمت إضافة مجسات الإطلاق في 1.16 كميزة ألفا وانتقلت إلى الإصدار التجريبي في 1.18.



تحذير: في الإصدار 1.16 ، تم إهمال أجزاء من Kubernetes API. استخدم دليل الترحيل هذا للتحقق من التوافق.



تحتوي جميع العينات على المعلمات التالية:

• initialDelaySeconds
  
  
  
  : ;
• periodSeconds
  
  
  
  : ;
• timeoutSeconds
  
  
  
  : - ( );
• successThreshold
  
  
  
  : , ;
• failureThreshold
  
  
  
  : . . , .

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





المصدر من



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



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

اختبارات الأداء

تستخدم المجسات الصحية لإعادة تشغيل الحاويات غير الصحية. يستدعي Kubelet بشكل دوري اختبارًا صحيًا ويكتشف صحة الكبسولة ويقتلها إذا فشل في الفحص الصحي



يمكن أن تساعد التجربة التطبيق في الخروج من مأزق. بدون فحوصات صحية ، يعتبر Kubernetes أنه مقفل في حالة صحية لأن العملية الرئيسية تستمر في العمل من منظور Kubernetes. من خلال إعداد فحص صحي ، يمكن لـ kubelet اكتشاف أن التطبيق في حالة سيئة وسيعيد تشغيل الكبسولة لاستعادة الإتاحة.





مصدر

عينات الإطلاق

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



لتحديد مدة الانتظار قبل التحقق من الجاهزية.



الآن ضع في اعتبارك تطبيقًا يحتاج أحيانًا إلى تحميل كميات كبيرة من البيانات أو إجراء عملية كثيفة الاستخدام للموارد في بداية العملية. نظرًا لأنه initialDelaySeconds



رقم ثابت ، فنحن مضطرون دائمًا إلى اتخاذ السيناريو الأسوأ (أو زيادة القيمة failureThreshold



، مما قد يؤثر على المزيد من السلوك) والانتظار لفترة طويلة ، حتى لو لم يكن هذا التطبيق بحاجة إلى إجراء تهيئة طويلة.



بدلاً من ذلك ، باستخدام تحقيقات بدء التشغيل ، يمكننا تكوينfailureThreshold



و periodSeconds



على نحو أفضل التعامل مع هذا الغموض. على سبيل المثال ، يعني الإعداد failureThreshold



15 و periodSeconds



5 أن التطبيق سيكون لديه 15 × 5 = 75 ثانية للبدء قبل تشخيص الفشل.

إعداد العينة

الآن بعد أن فهمنا الأنواع المختلفة للعينات ، يمكننا استكشاف ثلاث طرق مختلفة لإعداد كل عينة.

HTTP

يرسل Kubelet طلب HTTP GET إلى عنوان URL المحدد ويتحقق من استجابة 2xx أو 3xx. يمكنك استخدام نقطة نهاية HTTP موجودة أو تكوين خادم HTTP خفيف الوزن للاختبار (على سبيل المثال ، خادم Express مع نقطة نهاية /healthz



).



تأخذ تحقيقات HTTP معلمات إضافية:

• host
  
  
  
  : اسم المضيف للاتصال (افتراضيًا ، هذا هو عنوان IP الخاص بالوحدة) ؛
• scheme
  
  
  
  : افتراضي HTTP أو HTTPS ؛
• path
  
  
  
  : المسار على خادم HTTP / S ؛
• httpHeaders
  
  
  
  : رؤوس مخصصة إذا كنت بحاجة إلى قيم رأس للمصادقة وإعدادات CORS وما إلى ذلك.
• port
  
  
  
  : الاسم أو رقم المنفذ للوصول إلى الخادم.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

TCP

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

readinessProbe:
  tcpSocket:
    port: 21

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

أمر

يمكنك أيضًا تكوين المسبار لتشغيل أمر shell. يجتاز الفحص إذا عاد الأمر برمز الإنهاء 0. وإلا فسيتم وضع علامة على الوحدة النمطية على أنها معيبة.



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

readinessProbe:
  exec:
    command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

أفضل الممارسات لأخذ عينات Kubernetes

تعتمد معلمات العينة الدقيقة على التطبيق الخاص بك ، ولكن إليك بعض الإرشادات العامة للبدء:

1. بالنسبة لمجموعات Kubernetes الأقدم (≤ 1.15) ، استخدم مسبارًا أوليًا جاهزًا للتأخر للتعامل مع مرحلة بدء تشغيل الحاوية. للقيام بذلك ، استخدم الوقت المئوي 99٪. لكن اجعل هذا الفحص سهلاً ، حيث سيتم تشغيل اختبار الاستعداد طوال عمر الوحدة. لا نريد انتهاء مهلة المسبار لأن فحص الجاهزية يستغرق وقتًا طويلاً.
2. (≥ 1.16) Kubernetes . (, /healthz
   
   
   
   ), . failureThreshold
   
   
   
   , , . .
3. , . , , , . .
4. , . , , , . , .

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

أدوات

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

• Polaris هي أداة مساعدة لتحليل الموارد مع شريط أدوات جميل يمكن استخدامه أيضًا كخطاف ويب للتحقق من الصحة أو أداة سطر أوامر.
• kube -score هي أداة تحليل التعليمات البرمجية الثابتة التي تعمل مع ملفات Helm و Kustomize وملفات YAML القياسية.
• popeye هي أداة مساعدة للقراءة فقط تفحص مجموعات Kubernetes وتبلغ عن مشكلات التكوين المحتملة.

في هاتين القناتين على Telegram ، ستجد أخبارًا من Kubernetes aaS وإعلانات عن أحداث لقاءKubernetes .



ماذا تقرأ:

• 90 أداة للعمل مع Kubernetes .
• كيف يعمل Kubernetes aaS على منصة MCS .
• خمس أخطاء عند نشر تطبيقك الأول على Kubernetes .