مشغلي 🥇Kubernetes: كيفية تشغيل التطبيقات ذات الحالة

مشكلة التطبيقات ذات الحالة الخاصة في Kubernetes

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

ببساطة ، لتشغيل خمس نسخ أخرى من PHP / Ruby / Python الخلفية في مجموعة من الحاويات ، ما عليك سوى رفع خادم جديد 5 مرات ونسخ المصادر. نظرًا لأن كلاً من الكود المصدري والنص الأولي موجودان في الصورة ، فإن تحجيم تطبيق عديم الحالة يصبح أمرًا أساسيًا تمامًا. كما يدرك عشاق الحاويات وبنى الخدمات المصغرة جيدًا ، تبدأ الصعوبات التطبيقات ذات الحالة، أي. مع استمرار البيانات مثل قواعد البيانات وذاكرة التخزين المؤقت (MySQL و PostgreSQL و Redis و ElasticSearch و Cassandra ...). ينطبق هذا على كل من البرنامج الذي ينفذ بشكل مستقل كتلة النصاب (على سبيل المثال ، Percona XtraDB و Cassandra) ، والبرامج التي تتطلب أدوات مساعدة إدارية منفصلة (مثل Redis و MySQL و PostgreSQL ...).

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

مشغلي CoreOS

من أجل "برمجة" المعرفة التشغيلية ، في نهاية العام الماضي مشروع CoreOS المقدمة "فئة جديدة من البرامج" لمنصة Kubernetes - المشغلون (المشغلون ، من "العملية" الإنجليزية ، أي "التشغيل").

المشغلين ، باستخدام وتوسيع القدرات الأساسية لـ Kubernetes (بما في ذلك. الدولة، انظر أدناه لمعرفة الاختلافات) السماح لـ DevOps بإضافة المعرفة التشغيلية إلى كود التطبيق.

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

كيف يعمل المشغلون

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

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

وهكذا، كيف يعمل هذا كله؟ عامل التشغيل هو برنامج تحكم خفي:

الاشتراك في حدث API في Kubernetes ؛
يتلقى منه بيانات حول النظام (حوله مجموعات المقلدة, القرون, خدمات وما إلى ذلك وهلم جرا.)؛
يتلقى معلومات حول موارد الطرف الثالث (انظر الأمثلة أدناه) ؛
يتفاعل مع المظهر / التغيير موارد الطرف الثالث (على سبيل المثال ، لتغيير الحجم وتغيير الإصدار وما إلى ذلك) ؛
يستجيب للتغيير في حالة النظام (حوله مجموعات المقلدة, القرون, خدمات وما إلى ذلك وهلم جرا.)؛
الأهم:
1. يصل إلى Kubernetes API لإنشاء كل ما تحتاجه (مرة أخرى ، خاص بك مجموعات المقلدة, القرون, خدمات...) ،
2. يؤدي بعض السحر (يمكنك ، من أجل التبسيط ، التفكير في أن العميل يذهب إلى البودات بنفسه ويستدعي الأوامر ، على سبيل المثال ، للانضمام إلى المجموعة أو لترقية تنسيق البيانات عند تحديث الإصدار).

في الواقع ، كما ترى من الصورة ، تمت إضافة تطبيق منفصل ببساطة إلى Kubernetes (المعتاد قابل للفتح с مجموعة النسخ المتماثلة) ، والذي يسمى المشغل. إنه يعيش في جراب عادي (عادة ما يكون واحدًا) ، وكقاعدة عامة ، فهو مسؤول فقط عن جرابها مساحة الاسم. يقوم تطبيق المشغل هذا بتنفيذ API الخاص به - ولكن ليس بشكل مباشر ، ولكن من خلال موارد الطرف الثالث في Kubernetes.

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

مثال على الخ (انظر الى التفاصيل بالاسفل):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

مثال على Elasticsearch:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

متطلبات المشغلين

قامت CoreOS بصياغة الأنماط الرئيسية التي حصل عليها المهندسون أثناء العمل على المشغلين. على الرغم من حقيقة أن جميع المشغلين أفراد (تم إنشاؤها لتطبيق معين بخصائصهم واحتياجاتهم الخاصة) ، يجب أن يعتمد إنشائهم على نوع من الإطار الذي يفرض المتطلبات التالية:

يجب أن يتم التثبيت من خلال واحد قابل للفتح: kubectl create -f SOME_OPERATOR_URL / publish.yaml - ولا تتطلب إجراءات إضافية.
يجب أن يؤدي تثبيت عامل تشغيل في Kubernetes إلى إنشاء نوع أجنبي جديد (مورد الطرف الثالث). لتشغيل طبعات التطبيق (مثيلات المجموعة) وإدارتها بشكل أكبر (إصدارات التحديث ، وتغيير الحجم ، وما إلى ذلك) ، سيستخدم المستخدم هذا النوع.
كلما كان ذلك ممكنًا ، يجب استخدام العناصر الأولية المضمنة في Kubernetes ، مثل خدمات и مجموعات المقلدةلاستخدام كود تم اختباره جيدًا ومفهومًا.
مطلوب التوافق مع الإصدارات السابقة للمشغلين ودعم الإصدارات الأقدم من الموارد التي أنشأها المستخدم.
عند إزالة المشغل ، يجب أن يستمر التطبيق نفسه في العمل دون تغييرات.
يجب أن يكون المستخدمون قادرين على تحديد إصدار التطبيق المطلوب وتنسيق تحديثات إصدار التطبيق. يعد نقص تحديثات البرامج مصدرًا شائعًا لمشاكل التشغيل والأمان ، ويجب على المشغلين مساعدة المستخدمين في هذا الأمر.
يجب اختبار المشغلين بواسطة أداة مثل Chaos Monkey ، والتي تكتشف الأعطال المحتملة في البودات والتكوينات والشبكة.

مشغل الخ

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

ونظرًا لأن etcd تم إنشاؤه أيضًا في CoreOS ، كان من المنطقي تمامًا رؤية ظهور مشغلها أولاً. كيف يعمل؟ etcd منطق المشغل محددة بثلاثة مكونات:

ملاحظة. يراقب المشغل حالة المجموعة باستخدام Kubernetes API.
تحليل (تحليل). يبحث عن الاختلافات بين الحالة الحالية والحالة المرغوبة (المحددة بواسطة تكوين المستخدم).
العمل (قانون). يزيل الاختلافات المكتشفة باستخدام etcd و / أو واجهات برمجة تطبيقات خدمة Kubernetes.

لتنفيذ هذا المنطق ، أعد المشغل وظائف إنشاء / تدمير (إنشاء وإزالة أعضاء الكتلة وما إلى ذلك) و تغيير حجم (تغيير في عدد أعضاء الكتلة). تم التحقق من صحة أدائها باستخدام أداة تم إنشاؤها على غرار Chaos Monkey من Netflix ، أي قتل القرون بشكل عشوائي.

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

كيف يبدو العمل مع أحد العملاء؟

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

الحالة الحالية لمشغل etcd هي إصدار تجريبي يتطلب Kubernetes 1.5.3+ و 3.0+ للتشغيل. يتوفر كود المصدر والوثائق (بما في ذلك تعليمات الاستخدام) على الموقع GitHub جيثب:.

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

الوضع والتوقعات

لقد مرت 5 أشهر منذ الإعلان عن مشغلي Kubernetes. لا يزال هناك تطبيقان فقط متاحان في مستودع CoreOS الرسمي (لـ etcd و Prometheus). كلاهما لم يصل بعد إلى نسختهما المستقرة ، لكنهما يلتزمان على أساس يومي.

يتوقع المطورون "مستقبلًا يقوم فيه المستخدمون بتثبيت مشغلي Postgres أو مشغلي Cassandra أو Redis Operators على مجموعات Kubernetes الخاصة بهم والعمل مع الكيانات القابلة للتطوير لهذه التطبيقات بنفس سهولة نشر النسخ المتماثلة للتطبيقات عديمة الحالة للويب اليوم." أولاً مشغلي الطرف الثالث بدأت تظهر بالفعل.

مشغل Elasticsearch من UPMC Enterprises؛
مشغل PostgreSQL من Crunchy Data (تم الإعلان عنها في نهاية مارس 2017) ؛
عامل الغراب من مؤلفي نظام التخزين الموزع المستند إلى Ceph (Rook في حالة alpha) ؛
فتح مشغلي المكدس من SAP CCloud.

في أكبر مؤتمر أوروبي للبرمجيات الحرة ، FOSDEM ، الذي عقد في فبراير 2017 في بروكسل ، أعلن Josh Wood من CoreOS عن المشغلين في نقل (يتوفر الفيديو على الرابط!) مما يساهم في زيادة شعبية هذا المفهوم في مجتمع المصادر المفتوحة الأوسع.

PS شكرا لاهتمامك بالمقال! اشترك في مركزنا، حتى لا تفوتك المواد والوصفات الجديدة على إدارة نظام DevOps و GNU / Linux - سننشرها بانتظام!

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

عوامل تشغيل Kubernetes: كيفية تشغيل التطبيقات ذات الحالة