كيفية توصيل مجموعات Kubernetes في مراكز بيانات مختلفة

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

خبير اليوم هو دانيال بولينشيك (دانييل بولينسيك). يعمل دانيال كمدرس ومطور برامج في Learnk8s.

إذا كنت تريد إجابة لسؤالك في المنشور التالي ، اتصل بنا عبر البريد الإلكتروني أو تويتر: @ learnk8s.

غاب عن الوظائف السابقة؟ ابحث عنها هنا.

كيفية توصيل مجموعات Kubernetes في مراكز البيانات المختلفة؟

موجز: Kubefed v2 قريباوانصحكم ايضا ان تقرأوا عنها شاحن и مشروع متعدد الجدولة.

في كثير من الأحيان ، يتم تكرار البنية التحتية وتوزيعها عبر مناطق مختلفة ، لا سيما في البيئات الخاضعة للرقابة.

في حالة عدم توفر منطقة ما ، يتم إعادة توجيه حركة المرور إلى منطقة أخرى لتجنب الانقطاعات.

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

يمكن أن يكون لديك مجموعة واحدة أو أكثر لكل فريق أو منطقة أو بيئة أو مجموعة من هذه المجموعات.

يمكن استضافة مجموعاتك عبر سحابة متعددة وفي أماكن العمل.

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

مجموعة قيادة واحدة

إن إنشاء مجموعة واحدة عبر شبكة واحدة ليس بهذه السهولة.

تخيل أنك تعرضت لحادث ، فقد الاتصال بين أجزاء الكتلة.

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

وفي نفس الوقت لديك جداول توجيه قديمة (kube-proxy لا يمكن تنزيل ملفات جديدة) ولا توجد وحدات قرون إضافية (لا يمكن لـ kubelet الاستعلام عن التحديثات).

والأسوأ من ذلك ، إذا لم يتمكن Kubernetes من رؤية العقدة ، فإنه يميزها على أنها يتيمة ويوزع القرون المفقودة على العقد الموجودة.

نتيجة لذلك ، لديك ضعف عدد القرون.

إذا قمت بإنشاء خادم رئيسي واحد لكل منطقة ، فستكون هناك مشاكل في خوارزمية الإجماع في قاعدة البيانات إلخ. (تقريبا. إد. - في الواقع ، لا يجب أن تكون قاعدة البيانات etcd موجودة على الخوادم الرئيسية. يمكن تشغيله على مجموعة منفصلة من الخوادم في نفس المنطقة. ومع ذلك ، فقد تلقى في نفس الوقت نقطة فشل الكتلة. لكن بسرعة.)

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

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

يحتاج مدير وحدة التحكم إلى مزيد من الوقت للتعرف على التغيير وكتابة الرد على قاعدة البيانات.

وبما أن وحدة التحكم ليست واحدة ، بل عدة ، يتم الحصول على تفاعل متسلسل ، وتبدأ المجموعة بأكملها في العمل ببطء شديد.

وما إلى ذلك حساس لوقت الاستجابة لدرجة أن توصي الوثائق الرسمية باستخدام SSD بدلاً من محركات الأقراص الثابتة العادية.

لا توجد حاليًا أمثلة جيدة لشبكة كبيرة لمجموعة واحدة.

في الأساس ، يحاول مجتمع المطورين ومجموعة SIG-الكتلة اكتشاف كيفية تنظيم المجموعات بنفس الطريقة التي ينظم بها Kubernetes الحاويات.

الخيار 1: اتحاد الكتل مع kubefed

الجواب الرسمي من SIG-الكتلة - kubefed2 ، نسخة جديدة من عميل ومشغل اتحاد kube الأصلي.

لأول مرة ، حاولنا إدارة مجموعة من المجموعات ككائن واحد باستخدام أداة اتحاد kube.

كانت البداية جيدة ، لكن في النهاية ، لم يكتسب اتحاد كيوب شعبيته ، لأنه لم يدعم جميع الموارد.

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

تخيل كيف يمكنك وصف تقسيم النسخ المتماثلة لكل مجموعة في اتحاد باستخدام تعليق توضيحي واحد.

اتضح أنها فوضى كاملة.

قامت SIG-الكتلة بعمل رائع بعد kubefed v1 وقررت التعامل مع المشكلة من زاوية مختلفة.

بدلاً من التعليقات التوضيحية ، قرروا إصدار وحدة تحكم مثبتة على المجموعات. يمكن تكوينه باستخدام تعريفات الموارد المخصصة (تعريف الموارد المخصصة ، 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 بنشر هذا التغيير بشكل متزايد على جميع الكتل الموحدة.

كما أن الشاحن محدود للغاية.

على سبيل المثال، يأخذ مخططات 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 إلى تخصيص أو كابيتان?

تعرف على المزيد حول Shipper وفلسفته في هذا البيان الصحفي الرسمي.

إذا كنت تريد البحث في الرمز ، انتقل إلى مستودع المشروع الرسمي.

الخيار 3: الدمج العنقودي "السحري"

يعمل Kubefed v2 و Shipper مع اتحاد الكتلة من خلال توفير موارد جديدة للمجموعات من خلال تعريف مورد مخصص.

ولكن ماذا لو كنت لا تريد إعادة كتابة جميع المستلزمات ، ومجموعات StatefulSets ، و DaemonSets ، وما إلى ذلك ليتم دمجها؟

كيف يتم تضمين كتلة موجودة في الاتحاد دون تغيير YAML؟

جدولة المجموعات المتعددة هو مشروع Admirality، الذي يتعامل مع جدولة أعباء العمل على المجموعات.

ولكن بدلاً من ابتكار طريقة جديدة للتفاعل مع المجموعة وموارد الالتفاف في تعريفات مخصصة ، يتم إدخال برنامج الجدولة متعدد المجموعات في دورة حياة Kubernetes القياسية واعتراض جميع المكالمات التي تنشئ pods.

يتم استبدال كل جراب تم إنشاؤه على الفور بلهاية.

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

يمر الكبسولة الأصلية بدورة جدولة أخرى حيث يتم اتخاذ قرار الاستضافة بعد استقصاء الاتحاد بأكمله.

أخيرًا ، يتم تسليم الكبسولة إلى الكتلة المستهدفة.

نتيجة لذلك ، لديك حجرة إضافية لا تفعل شيئًا ، فقط تشغل مساحة.

الميزة هي أنك لست مضطرًا إلى كتابة موارد جديدة للجمع بين الإمدادات.

كل مورد يقوم بإنشاء جراب جاهز تلقائيًا للتوحيد.

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

ولكن بينما تحاول شركة Shipper بشكل أساسي التخفيف من آثار الشحنات ، يكون برنامج الجدولة متعدد المجموعات أكثر عمومية وربما يكون أكثر ملاءمة لوظائف الدُفعات.

ليس لديها آلية تسليم تدريجية متقدمة.

يمكن العثور على المزيد حول برنامج الجدولة متعدد المجموعات على صفحة المستودع الرسمية.

إذا كنت تريد أن تقرأ عن جدولة المجموعات المتعددة أثناء العمل ، فإن Admiralty لديها حالة استخدام مثيرة للاهتمام مع Argo - سير العمل ، الأحداث ، CI و CD Kubernetes.

أدوات وحلول أخرى

يعد توصيل مجموعات متعددة وإدارتها مهمة معقدة ، ولا يوجد حل واحد يناسب الجميع.

إذا كنت تريد معرفة المزيد حول هذا الموضوع ، فإليك بعض الموارد:

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

هذا كل شيء لهذا اليوم

شكرا لك على القراءة حتى النهاية!

إذا كنت تعرف كيفية توصيل مجموعات متعددة بكفاءة أكبر ، أخبرنا.

سنضيف طريقتك إلى الروابط.

شكر خاص لكريس نيسبيت سميث (كريس نيسبيت سميث) وفينسنت دي سمي (فنسنت دي سميت) (لمهندس الموثوقية في swatmobile.io) لقراءة المقال ومشاركة معلومات مفيدة حول كيفية عمل الاتحاد.

المصدر: www.habr.com