Kubernetes للأشخاص الذين يتعين عليهم تشغيله

دروس Kubernetes تعلمك نشر pod. لا أحد يعلمك ماذا تفعل عندما تسقط عقدة بصمت من حالة Ready في تمام الساعة الثالثة صباحاً ولن يتوقف هاتف on-call عن الرنين. هذا يتعلق بالجزء الثاني.

طلبات الموارد والحدود ليست اختيارية

إذا تخطيت resources.requests و resources.limits على حاوياتك، فإن الـ scheduler يقوم بالتخمين، و kubelet ليس لديه فكرة عما يجب إزالته أولاً عندما تنخفض الذاكرة على عقدة. اضبط الطلبات على ما تستهلكه الحاوية فعلياً تحت الحمل الطبيعي، وليس على ما تأمل أنها تستهلكه. اضبط حدود الذاكرة قريبة من الطلبات لأن pods التي تم قتلها بسبب OOM تعيد التشغيل بنظافة، لكن حدود CPU يجب أن تكون أفضل بشكل عام أو غائبة إلا إذا كنت تحارب جيران مزعجين، لأن تقليل CPU تحت حد صارم يسبب قفزات الكمون التي يصعب جداً تصحيح أخطائها. شغّل kubectl top pods -n your-namespace بانتظام وقارن مقابل ما قد أعلنته. عدم التطابق يتراكم بسرعة في المجموعات التي تحتوي على أكثر من حفنة من الخدمات.

etcd هو كل المجموعة، تعامل معها بهذه الطريقة

كل ما يعرفه Kubernetes يعيش في etcd. فقدانها يعني فقدان حالة المجموعة، وليس فقط بعض البيانات الوصفية. شغّل etcdctl snapshot save /backup/etcd-snapshot.db على جدول زمني، واختبر فعلياً استعادتها على مجموعة خدش مرة واحدة على الأقل. رأيت فرقاً لديها نسخ احتياطية ليلية اتضح أنها كانت معيبة لمدة ثلاثة أشهر لأن لا أحد تحقق منها. إذا كنت على لوحة تحكم مُدارة (EKS أو GKE أو AKS)، فأنت لا تدير etcd مباشرة، لكن يجب أن تعرف قصة النسخ الاحتياطي والاستعادة من مزودك قبل أن تحتاجها، وليس أثناء حادثة.

اختبارات الحياة والجاهزية تحتاج أحياناً إلى الاختلاف

خطأ شائع هو استخدام نفس endpoint لكل من اختبارات liveness و readiness. يجب أن تجيب Liveness