مرحبًا بك في سلسلة دروس Kubernetes السريعة. هذا عمود منتظم يحتوي على أكثر الأسئلة إثارة للاهتمام التي نتلقاها عبر الإنترنت وفي دوراتنا التدريبية. يجيب الخبير في Kubernetes.
خبير اليوم هو دانييلي بولينيتش . دانيال هو مدرس ومطور برامج في Learnk8s .
إذا كنت تريد الإجابة عن سؤالك في المنشور التالي ، فالرجاء الاتصال بنا عبر البريد الإلكتروني أو على Twitter: @ learnk8s .
تخطي الوظائف السابقة؟ ابحث عنهم هنا .
كيفية توصيل مجموعات Kubernetes في مراكز بيانات مختلفة؟
باختصار : سيتم طرح Kubefed v2 قريبًا ، كما أنصحك أن تقرأ عن Shipper ومشروع جدولة المجموعات المتعددة .
في كثير من الأحيان ، يتم تكرار البنية التحتية وتوزيعها عبر مناطق مختلفة ، خاصة في البيئات التي يتم التحكم فيها.
في حالة عدم توفر منطقة ما ، تتم إعادة توجيه حركة المرور إلى منطقة أخرى لتجنب الانقطاع.
مع Kubernetes ، يمكنك استخدام استراتيجية مماثلة وتوزيع أعباء العمل عبر مناطق مختلفة.
يمكنك الحصول على مجموعة واحدة أو أكثر لكل فريق أو منطقة أو بيئة أو مجموعة من هذه العناصر.
يمكن استضافة المجموعات الخاصة بك في السحب المختلفة وفي البيئة المحلية.
ولكن كيف تخطط للبنية التحتية لمثل هذا الانتشار الجغرافي؟
هل تحتاج إلى إنشاء مجموعة كبيرة واحدة عبر بيئات سحابية متعددة عبر شبكة واحدة؟
أو بدء الكثير من المجموعات الصغيرة وإيجاد طريقة للتحكم فيها ومزامنتها؟
كتلة واحدة الرصاص
إنشاء كتلة واحدة على شبكة واحدة ليست بهذه البساطة.
تخيل أن لديك حادث ، فقد الاتصال بين شرائح الكتلة.
إذا كان لديك خادم رئيسي واحد ، فلن تتمكن نصف الموارد من تلقي أوامر جديدة ، لأنها لن تكون قادرة على الاتصال بالسيد.
وفي الوقت نفسه ، لديك جداول توجيه قديمة (لا يمكن لـ kube-proxy تحميل جداول جديدة) ولا توجد ملفات إضافية (لا يمكن لـ kubelet طلب تحديثات).
ومما زاد الطين بلة ، إذا Kubernetes لا يرى العقدة ، فإنه يصنفها على أنها ضائعة ويوزع القرون المفقودة على العقد الموجودة.
نتيجة لذلك ، لديك ضعف عدد القرون.
إذا قمت بإنشاء خادم رئيسي واحد لكل منطقة ، فستحدث مشكلات في خوارزمية الإجماع في قاعدة بيانات etcd. ( تقريبا. Ed. - في الواقع ، لا يجب أن تكون قاعدة البيانات etcd موجودة على الخوادم الرئيسية. يمكن تشغيلها على مجموعة منفصلة من الخوادم في نفس المنطقة. ومع ذلك ، فقد حصلت على نقطة فشل نظام المجموعة. ولكن بسرعة. )
يستخدم etcd خوارزمية الطوافة للتفاوض على القيمة قبل كتابتها على القرص.
أي أن معظم الحالات يجب أن تتوصل إلى إجماع قبل أن تتمكن الدولة من الكتابة إلى غيرها.
إذا زاد التأخير بين مثيلات etcd بشكل كبير ، كما هو الحال مع ثلاث حالات من etcd في مناطق مختلفة ، فسيتطلب الأمر وقتًا طويلاً للتوفيق بين القيمة وكتابتها على القرص.
وينعكس ذلك في وحدات تحكم Kubernetes.
يحتاج مدير وحدة التحكم إلى مزيد من الوقت للتعرف على التغيير وكتابة الاستجابة إلى قاعدة البيانات.
وإذا لم تكن وحدة التحكم واحدة ، ولكن متعددة ، يتم الحصول على تفاعل سلسلة ، وتبدأ المجموعة بأكملها في العمل ببطء شديد .
إن etcd حساس للغاية تجاه الكمون الذي توصي به الوثائق الرسمية باستخدام محركات أقراص الحالة الثابتة بدلاً من محركات الأقراص الصلبة العادية .
لا توجد حاليًا أمثلة جيدة على شبكة كبيرة لمجموعة واحدة.
في الأساس ، يحاول مجتمع التطوير ومجموعة SIG المجموعة معرفة كيفية تنظيم التجمعات بنفس الطريقة التي تدير بها Kubernetes الحاويات.
الخيار 1: اتحاد الكتلة مع kubefed
الجواب الرسمي من SIG-cluster هو kubefed2 ، وهو إصدار جديد من الاتحاد الأصلي للعميل والمشغل kube .
لأول مرة ، حاولوا إدارة مجموعة الكتل ككائن واحد باستخدام أداة اتحاد kube.
كانت البداية جيدة ، ولكن في النهاية ، لم يصبح اتحاد الكوبي شعبية لأنه لم يدعم جميع الموارد.
لقد دعم عمليات التسليم والخدمات المشتركة ، ولكن ، على سبيل المثال ، ليس StatefulSets.
وتم نقل تكوين الاتحاد في شكل شروح ولم تختلف في المرونة.
تخيل كيف يمكنك وصف فصل النسخ المتماثلة لكل كتلة في الاتحاد باستخدام التعليقات التوضيحية فقط.
اتضح أن تكون فوضى كاملة.
قامت SIG-cluster بعمل رائع بعد kubefed v1 وقررت التعامل مع المشكلة من الجانب الآخر.
بدلاً من التعليقات التوضيحية ، قرروا تحرير وحدة تحكم مثبتة على الكتل. يمكن تكوينه باستخدام Custom Resource Definition (CRD).
لكل مورد سيكون جزءًا من الاتحاد ، لديك تعريف CRD مخصص من ثلاثة أقسام:
- التعريف القياسي للمورد ، مثل النشر ؛
- قسم
placement ، حيث تحدد كيفية توزيع المورد في الاتحاد ؛ override القسم ، حيث يمكن لمورد معين تجاوز الوزن والمعلمات من الموضع.
فيما يلي مثال للتسليم المشترك مع أقسام المواضع وتجاوزها.
apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: metadata: labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster2 - cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5
كما ترون ، يتم توزيع العرض عبر مجموعتين: cluster1 و cluster2 .
توفر المجموعة الأولى ثلاث نسخ متماثلة بينما يتم تعيين المجموعة الثانية على 5.
إذا كنت بحاجة إلى مزيد من التحكم في عدد النسخ المتماثلة ، يوفر kubefed2 كائنًا جديدًا لـ ReplicaSchedulingPreference ، حيث يمكن ترجيح النسخ المتماثلة:
apiVersion: scheduling.federation.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 9 clusters: A: weight: 1 B: weight: 2
بنية CRD و API ليست جاهزة بعد ، ويتم تنفيذ العمل النشط في مستودع المشروع الرسمي.
احترس من kubefed2 ، لكن تذكر أنه غير مناسب لبيئة العمل حتى الآن.
تعرف على المزيد حول kubefed2 في مقالة kubefed2 الرسمية على مدونة Kubernetes وفي مستودع مشروع kubefed الرسمي .
الخيار 2: تجميع المجموعات على غرار Booking.com
لم يتعامل مطورو Booking.com مع kubefed v2 ، لكنهم توصلوا إلى Shipper ، المشغل للتسليم في العديد من المجموعات ، في العديد من المناطق وفي العديد من السحب.
الشاحن هو شيء مشابه ل kubefed2.
تسمح لك كلتا الأداتين بتكوين إستراتيجية النشر للعديد من الكتل (أي الكتل يتم استخدامها وعدد النسخ المتماثلة الموجودة لديها).
لكن هدف Shipper هو تقليل مخاطر أخطاء التسليم.
في Shipper ، يمكنك تحديد سلسلة من الخطوات التي تصف فصل النسخ المتماثلة بين النشر السابق والحالي ومقدار حركة المرور الواردة.
عند إرسال مورد إلى كتلة ، تنشر وحدة التحكم Shipper هذا التغيير خطوة بخطوة عبر كافة الكتل المدمجة.
والشاحن محدود جدا.
على سبيل المثال ، يقبل مخططات Helm كمدخلات ولا يدعم موارد الفانيليا.
بشكل عام ، يعمل الشاحن على النحو التالي.
بدلاً من التسليم القياسي ، تحتاج إلى إنشاء مورد تطبيق يتضمن مخطط Helm:
apiVersion: shipper.booking.com/v1alpha1 kind: Application metadata: name: super-server spec: revisionHistoryLimit: 3 template: chart: name: nginx repoUrl: https://storage.googleapis.com/shipper-demo version: 0.0.1 clusterRequirements: regions: - name: local strategy: steps: - capacity: contender: 1 incumbent: 100 name: staging traffic: contender: 0 incumbent: 100 - capacity: contender: 100 incumbent: 0 name: full on traffic: contender: 100 incumbent: 0 values: replicaCount: 3
يعد Shipper خيارًا جيدًا لإدارة مجموعات متعددة ، ولكن علاقته الوثيقة مع Helm تتداخل فقط.
ماذا لو انتقلنا جميعًا من Helm إلى kustomize أو kapitan ؟
تعرف على المزيد حول Shipper وفلسفتها في هذا البيان الصحفي الرسمي .
إذا كنت ترغب في الخوض في الكود ، فانتقل إلى مستودع المشروع الرسمي .
الخيار 3: الانضمام العنقودي "السحري"
تعمل Kubefed v2 و Shipper مع اتحاد الكتلة ، مما يوفر للمجموعات موارد جديدة من خلال تعريفات الموارد المخصصة.
ولكن ماذا لو كنت لا ترغب في إعادة كتابة جميع المستلزمات ، StatefulSets ، DaemonSets ، وما إلى ذلك للجمع؟
كيفية تضمين كتلة موجودة في اتحاد دون تغيير YAML؟
multi-cluster-scheduler هو مشروع Admirality الذي يتعامل مع أعباء عمل التخطيط في مجموعات.
ولكن بدلاً من الوصول إلى طريقة جديدة للتفاعل مع الكتلة والتفاف الموارد في التعاريف المعرفة من قبل المستخدم ، يتم تضمين جدولة تكتلات متعددة في دورة حياة Kubernetes القياسية ويعترض جميع المكالمات التي تنشئها السنفات.
كل خلق تحت تحل محلها على الفور دمية.
multi-cluster-scheduler يستخدم خطافات الويب لتعديل الوصول إلى اعتراض المكالمة وإنشاء دمية خاملة.
يمر جراب المصدر من خلال دورة تخطيط أخرى ، حيث يتم اتخاذ قرار بشأن التنسيب بعد إجراء مسح للاتحاد بأكمله.
أخيرًا ، يتم تسليم pod إلى الكتلة الهدف.
نتيجة لذلك ، لديك جراب إضافي لا يفعل شيئًا ، فقط يأخذ مساحة.
الميزة هي أنه لم يكن عليك كتابة موارد جديدة لدمج اللوازم.
كل مورد يقوم بإنشاء جراب جاهز تلقائيًا للاندماج.
هذا أمر مثير للاهتمام ، نظرًا لأن لديك عمليات توزيع موزعة فجأة عبر عدة مناطق ، لكنك لم تلاحظ ذلك. ومع ذلك ، هذا أمر محفوف بالمخاطر ، لأن كل شيء هنا يعتمد على السحر.
ولكن إذا حاولت شركة Shipper التخفيف من آثار الإمدادات ، فإن برنامج جدولة المجموعات المتعددة يؤدي مهام أكثر عمومية وربما يكون أكثر ملاءمة لوظائف الدُفعات.
ليس لديها آلية متقدمة للإمداد التدريجي.
يمكنك معرفة المزيد حول برنامج جدولة المجموعات المتعددة على صفحة مستودع التخزين الرسمية .
إذا كنت تريد أن تقرأ عن جدولة مجموعات متعددة في العمل ، فإن Admiralty لديه حالة استخدام مثيرة للاهتمام مع Argo - سير العمل ، والأحداث ، والأقراص المدمجة CI و Kubernetes.
أدوات وحلول أخرى
يعد توصيل وإدارة مجموعات متعددة مهمة معقدة ؛ لا يوجد حل عالمي.
إذا كنت تريد معرفة المزيد حول هذا الموضوع ، فإليك بعض الموارد:
هذا كل شيء لهذا اليوم
شكرا لك على القراءة حتى النهاية!
إذا كنت تعرف كيفية توصيل مجموعات متعددة بشكل أكثر كفاءة ، أخبرنا .
سنضيف طريقتك إلى الروابط.
شكر خاص لكريس نسبيت سميث وفينسنت دي سميت (مهندس موثوقية في swatmobile.io ) لقراءة هذا المقال ومشاركة بعض المعلومات المفيدة حول كيفية عمل الاتحاد.