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

النقاط الرئيسية:

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

تتطلب التوفرية العالية تخطيطًا دقيقًا وبنية أساسية قوية واختبارًا مستمرًا لضمان الأداء المستمر ووقت التشغيل.

[ Kube 1.5 ] إعداد مجموعة Kubernetes عالية التوفر خطوة بخطوة | Keepalived & Haproxy

تخطيط مجموعة Kubernetes عالية التوفر

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

تقييم المتطلبات التجارية والفنية

ابدأ بتحديد مدى تحملك لوقت التوقف وفقدان البيانات. ستؤثر هذه المعايير على كل خيار تقني تتخذه لمجموعتك.

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

ستحتاج أيضًا إلى تحديد هدف التوفر. للرجوع إليه:

• 99.9% وقت التشغيل يسمح بحوالي 8.77 ساعة من التوقف سنويًا.
• 99.99% وقت التشغيل ويقلص ذلك إلى حوالي 52.6 دقيقة.

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

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

اختيار الهندسة المعمارية الإقليمية مقابل الهندسة المعمارية النطاقية

طريقة توزيعك الجغرافي لمجموعة خدماتك تلعب دورًا هامًا في مرونتها. توفر كلٌّ من البنى الإقليمية والبنيات المناطقية مزايا مميزة حسب احتياجاتك.

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

تُعدّ عمليات النشر الإقليمية الأنسب للتطبيقات ذات قواعد المستخدمين العالمية أو عندما تشترط اللوائح تخزين البيانات في بلدان محددة. كما أنها مثالية للمؤسسات التي لديها احتياجات صارمة للتعافي من الكوارث.

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

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

متطلبات الشبكات والتكرار

تُعدّ استراتيجية الشبكات القوية أساسيةً لدعم حركة المرور من الشمال إلى الجنوب (من العميل إلى المجموعة) ومن الشرق إلى الغرب (التواصل بين مكونات المجموعة). ويُعدّ التكرار في طبقات متعددة أمرًا لا غنى عنه.

• يستخدم موازنات تحميل متعددة مع /صحة فحوصات موزعة على المناطق. يجب أن يكون كل موازن تحميل قادرًا على التعامل مع كامل حمل الحركة المرورية لتجنب نقاط الفشل الفردية.
• يضمن تنوع مسار الشبكة للحماية من مشاكل الاتصال. يجب أن يكون لحركة المرور بين المناطق مسارات مادية متعددة، و مزود الخدمات السحابية أو يجب أن يوفر مركز البيانات بنية أساسية للشبكة زائدة عن الحاجة.
• ل DNS واكتشاف الخدمةانشر خوادم DNS متعددة بتكوينات TTL مناسبة لنقاط نهاية المجموعة. مع أن موازنة التحميل القائمة على DNS تُضيف التكرار، انتبه إلى أن تخزين DNS المؤقت من جانب العميل قد يُؤخر اكتشاف الأعطال.

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

إذا كنت تفكر البنية التحتية لـServionتوفر مواقع مراكز البيانات العالمية الخاصة بهم دعمًا قويًا للبنى التحتية الإقليمية والإقليمية. توفر خيارات الخوادم الافتراضية الخاصة (VPS) والخوادم المخصصة أساسًا حاسوبيًا متينًا لعقد مجموعاتكم، بينما تتيح خدمات التشارك في الموقع نشرًا هجينًا يجمع بين مرونة السحابة والتحكم في الإعدادات المحلية. بالإضافة إلى ذلك، صُممت البنية التحتية الشبكية الاحتياطية لديهم لتلبية متطلبات الاتصال لمجموعات التوافر العالي، مما يضمن مرونة وموثوقية نشر Kubernetes لديكم.

المكونات الأساسية والطوبولوجيات لتحقيق توفر عالي

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

مكونات Kubernetes الرئيسية لـ HA

تُعدّ مستوى التحكم العمود الفقري لمجموعة Kubernetes الخاصة بك. وهي تشمل خادم API, المجدول, مديري التحكم، و إلخ، والتي تلعب جميعها أدوارًا حاسمة في الحفاظ على العمليات.

• خادم API:خادم API هو المحور المركزي الذي يعالج الطلبات من كوبيكتلوعقد العمل والمكونات الداخلية الأخرى. يضمن تشغيل خوادم API متعددة عبر المناطق عدم تعطل المجموعة بسبب فقدان خادم واحد.
• المجدوليُعيّن المُجدول وحداتٍ للعُقد بناءً على الموارد المتاحة والقيود المُحددة. مع أنه يُمكنك نشر مُجدولاتٍ متعددةٍ لتوفير الوقت، إلا أن مُجدولًا واحدًا فقط هو الذي يتخذ القرارات بنشاطٍ في كل مرة. في حال فشل المُجدول النشط، يتدخل مُجدولٌ آخر.
• مديري التحكمتراقب هذه الأنظمة حالة المجموعة باستمرار، مما يضمن توافق الموارد مع التكوين المطلوب. تستخدم هذه الأنظمة انتخاب القائد، ما يعني أن نسخة واحدة فقط تدير الموارد بنشاط، بينما تكون النسخ الاحتياطية جاهزة لتولي المسؤولية عند الحاجة.
• إلخيحتوي هذا المخزن الموزع للمفتاح والقيمة على بيانات التكوين والأسرار ومعلومات الحالة. ويستخدم خوارزمية إجماع، مما يتطلب أغلبية العقد (النصاب القانوني) للعمل. على سبيل المثال، يمكن لمجموعة etcd ثلاثية العقد التعامل مع فقدان عقدة واحدة دون فقدان الوظيفة.
• كوبيليتيعمل kubelet على كل عقدة عاملة، ويتواصل مع خادم واجهة برمجة التطبيقات (API) لتلقي مواصفات البود والإبلاغ عن حالة العقدة. مع أن kubelet نفسها ليست مُجمّعة لتوفير توافر عالٍ، إلا أن وجود عقد عاملة متعددة يضمن استمرار أحمال العمل حتى في حال تعطل بعض العقد.

بمجرد فهمك لهذه المكونات، فإن الخطوة التالية هي اختيار الطوبولوجيا التي تناسب احتياجاتك بشكل أفضل.

طوبولوجيات HA: المكدسة مقابل الخارجية وما إلى ذلك

عند تنظيم مكونات مستوى التحكم، لديك خياران رئيسيان، ولكل منهما مقايضاته الخاصة من حيث الموثوقية والتعقيد.

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

ميزة	مكدسة الخ	الخ خارجي
إعداد التعقيد	أسهل في النشر والإدارة	يتطلب المزيد من العقد والإدارة
عزل الموارد	الموارد المشتركة مع مستوى التحكم	موارد مخصصة لـ etcd
تأثير الفشل	تأثر كل من etcd ومستوى التحكم	الأعطال التي تتم إدارتها بشكل مستقل
قابلية التوسع	محدودة بالموارد المشتركة	إمكانية التوسع المستقل

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

بعد اختيار طوبولوجيتك، فإن الخطوة التالية هي تكوين موازنات التحميل لضمان العمليات السلسة.

تكوين موازن التحميل

تلعب موازنات الأحمال دورًا محوريًا في توزيع طلبات واجهة برمجة التطبيقات (API) عبر خوادمها المتعددة، وإدارة عمليات التعافي من الأعطال عند تعطل الخوادم. بدونها، سيحتاج العملاء إلى تتبع نقاط نهاية كل خادم واجهة برمجة تطبيقات على حدة، مما يُعقّد العملية.

يجب أن يكون موازن التحميل المُهيأ بشكل صحيح:

• إجراء فحوصات صحية على /صحة نقطة نهاية كل خادم واجهة برمجة تطبيقات. تشير استجابة HTTP 200 إلى الجاهزية، بينما تشير استجابة HTTP 500 إلى وجود مشكلة. يجب إجراء فحوصات السلامة كل 10-15 ثانية مع مهلة زمنية مدتها 5 ثوانٍ لضمان سرعة اكتشاف المشكلات.
• وزّع الطلبات بالتساوي، لأن خوادم API الخاصة بـ Kubernetes عديمة الجنسية. عادةً، لا يلزم وجود تقارب للجلسة، مما يسمح بتدفق حركة المرور بسلاسة حتى في حالات تعطل الخادم.
• معالجة إنهاء SSL. يمكنك تفريغ معالجة TLS في مُوازن التحميل لتقليل عبء عمل خوادم واجهة برمجة التطبيقات (API)، أو تمرير حركة مرور مُشفّرة للتشفير الشامل إذا تطلبت الامتثال ذلك.

لمزيد من التكرار، انشر موازنات تحميل متعددة عبر مناطق مختلفة. يمكن أن توفر موازنة التحميل القائمة على DNS طبقة إضافية من التعافي من الأعطال، ولكن تذكر أن تخزين DNS المؤقت قد يسبب تأخيرات أثناء عمليات الانتقال.

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

إس بي بي-آي تي بي-59إي1987

دليل خطوة بخطوة: نشر HA Kubernetes مع kubeadm

الآن وقد تعرفت على المكونات والطوبولوجيات، حان الوقت لبناء مجموعة Kubernetes عالية التوافر. سنستخدم kubeadm في هذا الدليل، فهو يُبسط عملية النشر مع تمكينك من التحكم في التكوين.

إعداد البنية التحتية والمتطلبات الأساسية

ابدأ بإعداد البنية التحتية الخاصة بك للتعامل مع أحمال العمل الإنتاجية.

ستحتاج إلى ثلاث عقد تحكم على الأقل (الحد الأدنى: نواتان للمعالج وذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت؛ الموصى به: 4 أنوية وذاكرة وصول عشوائي (RAM) سعة 8 جيجابايت) وعقدتين عاملتين أو أكثر (الحد الأدنى: نواة واحدة وذاكرة وصول عشوائي (RAM) سعة 2 جيجابايت). ثبّت توزيعة لينكس مدعومة، مثل Ubuntu 20.04/22.04 أو CentOS 8 أو Rocky Linux 9، على جميع العقد. تأكد من أن لكل عقدة اسم مضيف فريد وإمكانية التواصل مع العقد الأخرى عبر الشبكة.

تعطيل التبديل على جميع العقد لأن Kubernetes لا يدعمها. قم بتشغيل sudo swapoff -a وتعليق على أي إدخالات مبادلة في /etc/fstab لجعل التغيير دائمًا. افتح المنافذ المطلوبة: 6443 (خادم واجهة برمجة التطبيقات)، 2379-2380 (إلخ)، 10250 (kubelet)، و10251-10252 (مجدول/مدير وحدة التحكم).

تثبيت وقت تشغيل الحاوية على كل عقدة. يختار معظم المستخدمين Containerd، وهو مدعوم جيدًا. قم بتكوينه لاستخدام systemd كبرنامج تشغيل cgroup ليتوافق مع إعدادات Kubernetes الافتراضية. ثم ثبّت kubeadm وkubelet وkubectl على جميع العقد، مع التأكد من أنها تعمل جميعها بنفس إصدار Kubernetes لتجنب مشاكل التوافق.

إعداد موازن التحميل قبل تهيئة المجموعة. يمكن أن يكون مُوازن الأحمال مُدمجًا في الأجهزة، أو جزءًا من عروض مُزودي الخدمات السحابية، أو حلاً برمجيًا مثل HAProxy. يجب أن يستمع على المنفذ 6443 ويُعيد توجيه حركة المرور إلى خوادم واجهة برمجة التطبيقات (API) على عُقد مستوى التحكم لديك.

للحصول على إعداد متسامح مع الأخطاء على مستوى العالم، فكر في استخدام خوادم مخصصة لعقد مستوى التحكم ومثيلات VPS لعقد العمال.

إعداد عقد مستوى التحكم

عقدة مستوى التحكم الأولى هي أساس مجموعتك. بدلاً من استخدام علامات سطر الأوامر، أنشئ ملف تكوين kubeadm لتحديد إعدادات التوفر العالي (HA).

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

قم بتهيئة عقدة مستوى التحكم الأولى باستخدام الأمر التالي:
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs
ال --تحميل الشهادات يُبسّط العلم عملية توزيع الشهادات على عُقد مستوى التحكم الأخرى. تستغرق هذه الخطوة بضع دقائق، وتُصدر أوامر ربط لإضافة عُقد إضافية.

خزّن أوامر الربط هذه بأمان، فهي تحتوي على رموز حساسة. بعد ذلك، قم بتكوين kubectl على أول عقدة في مستوى التحكم:
mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

قبل إضافة المزيد من العقد، قم بتثبيت مكون إضافي CNI مناسب لبيئتك.

استخدم أمر الانضمام من مخرجات التهيئة لإضافة عقد مستوى التحكم المتبقية:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256: --control-plane --certificate-key
قم بتشغيل هذا الأمر على كل عقدة إضافية في مستوى التحكم.

تأكد من أن جميع عقد مستوى التحكم تعمل عن طريق تشغيل:
kubectl الحصول على العقد
يجب أن ترى جميع العقد المدرجة بحالة "جاهزة".

تكوين etcd وموازنات التحميل

قم بضبط إعدادات etcd وموازن التحميل لإكمال إعداد HA.

إذا كنت تستخدم بنية etcd مكدسة، فسيقوم kubeadm بتكوينها تلقائيًا. بالنسبة لمجموعات etcd الخارجية، ستحتاج إلى إعداد etcd على عقد مخصصة، وإنشاء شهادات اتصال آمنة، وتكوين كل عضو في etcd للتعرف على الأعضاء الآخرين. استخدم دائمًا عددًا فرديًا من أعضاء etcd (مثل 3 أو 5 أو 7) للحفاظ على النصاب القانوني أثناء الأعطال.

التحقق من صحة etcd عن طريق تشغيل:
Sudo kubectl exec -n kube-system etcd- -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key صحة نقطة النهاية
ينبغي أن تكون جميع نقاط النهاية سليمة.

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

لاختبار موازن التحميل، أوقف خادم API على عقدة واحدة في مستوى التحكم (sudo systemctl stop kubelet) وتأكد من أن أوامر kubectl لا تزال تعمل. أعد تشغيل الخدمة وتأكد من عودة العقدة إلى المجموعة.

إذا كنت تستخدم عدة موازنات تحميل، فقم بتكوينها في إعداد نشط-سلبي أو استخدم نظام DNS الدوري لتوزيع الحمل الأولي. وثّق إجراءات التعافي من الأعطال لتوجيه فريقك في التعامل مع مشاكل موازنات التحميل.

إضافة عقد العمل واختبار صحة المجموعة

تُعدّ عُقد العمل العمود الفقري لمجموعتك، حيث تُوفّر قوة الحوسبة لتطبيقاتك. إضافتها سهلة، لكن اختبارها يضمن مرونة المجموعة.

استخدم أمر الانضمام إلى عقدة العامل المقدم أثناء إعداد kubeadm الأولي:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256:
إذا انتهت صلاحية الرمز المميز، فيمكنك إنشاء رمز مميز جديد.

تأكد من انضمام عقد العمال بنجاح عن طريق تشغيل:
kubectl الحصول على العقد
يجب أن تُظهر جميع العقد حالة "جاهزة". إذا بقيت عقدة في حالة "غير جاهزة"، فافحص سجلات kubelet باستخدام:
sudo journalctl -u kubelet -f

انشر تطبيق اختبار للتأكد من سلامة المجموعة. على سبيل المثال، أنشئ نشر nginx مع نسخ متماثلة متعددة:
kubectl إنشاء نشر nginx-test --image=nginx --replicas=5
ثم تحقق من توزيع الجراب عبر العقد:
kubectl get pods -o wide

محاكاة الأعطال لاختبار وظائف التوفر العالي (HA). بالنسبة لعقد مستوى التحكم، أوقف خدمة kubelet على عقدة واحدة وتأكد من أن أوامر kubectl لا تزال تعمل. إذا كان لديك أكثر من ثلاث عقد مستوى تحكم، فحاول إيقاف عقدتين في آنٍ واحد - يجب أن تظل المجموعة قيد التشغيل طالما أن غالبية العقد سليمة.

بالنسبة لعقد العمال، قم بمحاكاة الفشل عن طريق تطويق عقدة واستنزافها:
حبل كوبيكتل && استنزاف كوبيكتل --تجاهل-daemonsets --حذف-بيانات-الدليل-الفارغة
راقب كيف يقوم Kubernetes بإعادة جدولة الأوعية إلى عقد أخرى.

قم بمراقبة مكونات المجموعة باستخدام:
kubectl الحصول على حالات المكونات و kubectl احصل على pods -n kube-system
يجب أن تكون جميع وحدات النظام قيد التشغيل، وأن تُبلغ المكونات عن أدائها السليم. للمراقبة المستمرة، استخدم أدوات مثل Prometheus لتتبع المقاييس بمرور الوقت.

لا تنسى الإعداد النسخ الاحتياطية لـ etcd والشهاداتقم باختبار إجراءات النسخ الاحتياطي والاستعادة بشكل منتظم في بيئة غير إنتاجية للتأكد من فعاليتها.

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

أفضل الممارسات لعمليات HA Kubernetes

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

المراقبة والصيانة

المراقبة الفعّالة هي أساس التوافر العالي (HA). استخدم أدوات مثل بروميثيوس و جرافانا لتتبع المقاييس الرئيسية مثل استخدام وحدة المعالجة المركزية، واستهلاك الذاكرة، وزمن وصول الشبكة، وأداء etcd. انتبه جيدًا لسلامة etcd من خلال مقاييس المراقبة مثل انتخابات القادة، وفشل المقترحات، وزمن وصول إدخال/إخراج القرص. جهّز تنبيهات للحدود الحرجة - على سبيل المثال، إذا تجاوز استخدام وحدة المعالجة المركزية 80% عبر عدة عقد، أو إذا تجاوز زمن وصول etcd 100 مللي ثانية، يلزم اتخاذ إجراء فوري. استخدم بانتظام حالة نقطة نهاية etcdctl أمر للتأكد من مزامنة جميع أعضاء etcd وعملهم بشكل صحيح.

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

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

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

اختبار إجراءات الفشل والنسخ الاحتياطي

المراقبة وحدها لا تكفي، بل عليك أيضًا اختبار عمليات التعافي من الأعطال والنسخ الاحتياطي بدقة. أجرِ اختبارات حقن الأخطاء شهريًا لمحاكاة الأعطال الفعلية. على سبيل المثال، أوقف تشغيل عُقد مستوى التحكم، أو أنشئ أقسامًا في الشبكة، أو حمّل عُقد العمل فوق طاقتها لمعرفة كيفية استجابة نظامك. تتبع أوقات التعافي لكل سيناريو، واعمل على تقليلها.

اختبر إجراءات النسخ الاحتياطي والاستعادة لـ etcd بانتظام لضمان سلامة البيانات. أجرِ هذه الاختبارات في بيئة منفصلة للتحقق من دقتها وقياس الوقت المستغرق للاستعادة. إذا تجاوزت عملية الاستعادة هدف وقت الاسترداد (RTO)، ففكّر في حلول تخزين أسرع أو تبسيط إجراءاتك. أتمت عمليات النسخ الاحتياطي لـ etcd كل ست ساعات، وخزّنها في مواقع موزعة لمزيد من الأمان.

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

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

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

تصميم تطبيقات HA

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

استخدم قواعد مكافحة التقارب لمنع نقاط الفشل الفردية. مع جراب مضاد للتقاربيمكنك توزيع النسخ المتماثلة عبر عُقد أو مناطق توفر مختلفة. بالنسبة للتطبيقات التي تعتمد على الحالة، مثل قواعد البيانات، اجمع بين عدم التقارب وقيود انتشار الطوبولوجيا لتوزيع أحمال العمل بالتساوي.

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

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

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

استخدام Serverionالبنية التحتية لـ HA Kubernetes

تُبسّط شبكة مراكز البيانات العالمية من Serverion التوزيع الجغرافي، وهو عنصر أساسي لتحقيق التوافر العالي. انشر عُقد مستوى التحكم عبر مناطق متعددة لتحقيق التكرار الحقيقي. توفر خوادمها المخصصة الأداء الثابت اللازم لمجموعات etcd، بينما توفر خوادم VPS قابلية توسع فعالة من حيث التكلفة لعُقد العمل.

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

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

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

خاتمة

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

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

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

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

الأسئلة الشائعة

ما هو الفرق بين إعدادات etcd المكدسة والخارجية في Kubernetes، وكيف أختار الأفضل لمجموعتي؟

التمييز الرئيسي بين مكدسة و الخ خارجي تكمن أهمية التكوينات في مكان عمل قاعدة بيانات etcd وكيفية إدارتها. في الإعداد المكدس، تعمل etcd على نفس العقد التي تعمل عليها مكونات مستوى تحكم Kubernetes. هذه الطريقة أسهل في التنفيذ وأقل تكلفة، ولكنها تأتي مع عيب: قد يؤثر عطل العقدة على كلٍّ من مستوى التحكم وetcd، مما قد يُسبب أعطالاً كبيرة.

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

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

ما هي أفضل الممارسات لمراقبة وصيانة مجموعة Kubernetes عالية التوفر لتحقيق أهداف التشغيل المستمر؟

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

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

كيف يمكنني تصميم تطبيقاتي لتحقيق توفر عالي في مجموعة Kubernetes؟

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

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

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

منشورات المدونة ذات الصلة

• التخزين المقاوم للأخطاء لتدفق البيانات: الأساسيات
• اختبار فشل قاعدة البيانات: الخطوات الرئيسية
• تكوين NGINX لـ DevOps: حيلة Serverion لنشر عمليات خالية من التوقف
• التوسع التلقائي لأحمال عمل Kubernetes