يعتبر مشغلو Kubernetes آلية ملائمة لتوسيع إمكانيات منصة الحاويات هذه ، والتي حازت بحق على اعتراف واسع بين بيئة مهندسي العمليات والمتعاطفين معهم. تحدثنا عن كيفية ترتيبها وعملها في عام 2017 البعيد بالفعل. وفي ابريل من العام الماضي، فإننا قدم المصدر المفتوح مشغل قذيفة المشروع ، الذي تبسيطها إلى حد كبير عملية إنشاء شركات Kubernetes.
لهذا ، تم تطوير إطار عمل يسمح لك بتشغيل نصوص عشوائية (في Bash و Python وما إلى ذلك) في حالة وقوع أحداث معينة في مجموعة K8s.
على مدار الماضي ، اكتسب مشغل shell قاعدة مستخدميه (انظر التفاصيل في نهاية المقالة) ، وبالطبع الميزات الجديدة. بمناسبة الإصدار الأخيرv1.0.0-beta.11 (حول حالة بيتا ، انظر أدناه) قررنا التحدث عما وصل إليه المشروع أثناء وجوده ، منذ الإعلان عن الإصدار العام الأول.
حول الجهاز والغرض منه
ولكن دعونا نبدأ بتوضيح موجز لكيفية عمل مشغل القشرة ولماذا ، من حيث المبدأ ، قد تكون هناك حاجة إليه.
يتم تشغيل مشغل Shell في جراب مجموعة Kubernetes. يتم تقديمها هناك على النحو التالي:
- اذهب ثنائي الذي يشترك في الأحداث في K8s API ويطلق الخطافات (إعطاءهم تفاصيل حول ما حدث) ؛
- مجموعة من الخطافات ، كل منها عبارة عن نص Bash أو نص Python أو أي ملف قابل للتنفيذ.
خطاف:
- هم أنفسهم يحددون الأحداث والأشياء التي يحتاجونها ؛
- تنفيذ الإجراءات اللازمة في حالة حدوث هذه الأحداث في K8s.
وبالتالي ، فإن عامل التشغيل shell هو طبقة بين الأحداث في Kubernetes API والنصوص البرمجية لمعالجتها.
لماذا تم إنشاء مشغل القشرة على الإطلاق؟ عوامل التشغيل هي المعيار "للقيام بالشيء الصحيح" داخل Kubernetes ، ولكن تطويرها بالكامل (في Go باستخدام حزمة SDK المناسبة ) ليس بالأمر السهل. إن وجود مثل هذا الإطار البسيط مثل مشغل القشرة يقلل بشكل كبير من عتبة الدخول إلى هذه المنطقة ، مما يسمح لك بحل المشاكل التشغيلية الصغيرة بسرعة وفعالية * داخل الكتلة. وبنفس القدر من الأهمية ، افعلها بالطريقة الصحيحة.
ما المهام التي نتحدث عنها؟ يمكن العثور على أمثلة جاهزة لاستخدام عامل التشغيل shell في مستودع المشروع . نحن في Flant نستخدمها كمكتبة(نعم ، كان ذلك ممكنًا أيضًا!) . أصبح الأساس لعامل الإضافات ، الذي يدير مكونات إضافية في Kubernetes.
ملحوظة : يمكن العثور على الإعلان عن هذا المشروع مفتوح المصدر (addon-operator) هنا . وفي تقرير " توسيع واستكمال Kubernetes " ، تحدثنا بالتفصيل عن أسباب ظهوره ، والعلاقة مع مشغل القشرة ومبادئ التشغيل.
الآن حول التغييرات الرئيسية التي أدخلت على مشغل القشرة خلال العام الماضي.
الابتكارات الرئيسية
في الإصدارات الأولى من عامل التشغيل shell ، كان هناك كائن واحد فقط متاحًا للخطاف - الكائن المرتبط بالحدث من المجموعة. نتج عن تطور الخطافات المستخدمة داخل عامل التشغيل الإضافي ربط الخطاف في تغيير كائن ، ولكن الاتصال
kubectlللحصول على قائمة محدثة بالكائنات الأخرى . لإزالة المكالمات غير الضرورية kubectlوبالتالي تسريع عمل الخطافات ، تم تنفيذ العديد من الاحتمالات للوصول إلى قوائم الكائنات الحالية:
- وضع التزامن + الحدث ، عندما يتلقى الخطاف في البداية قائمة بالكائنات الفعلية ، ثم يعمل مع كائن واحد فقط. يتم تمكين هذا الوضع افتراضيًا - يمكننا القول أن النتيجة هي تناظرية من حلقة التوفيق من operator-sdk.
- snapshot', . (Snapshot’ Kubernetes, .)
- snapshot'. , , , .
- أصبح من الممكن أيضًا مراقبة المورد ، ولكن لا يتفاعل مع تغييراته ، أي "تجميع اللقطة". على سبيل المثال ، يمكن أن يتفاعل ربط مع التغييرات في CustomResource ويستمر في تلقي كائن ConfigMap الفعلي بدون استدعاء إضافي
kubectl. (انظر الأعلامexecuteHookOnSynchronizationو لمزيد من التفاصيلexecuteHookOnEvent).
ابتكارات مهمة أخرى:
- بفضل الانتقال إلى استخدام عميل Kubernetes الديناميكي في مشغل shell ، أصبح من الممكن الاشتراك في أي
kindنوع موجود (نوع المورد في Kubernetes API) ، بما في ذلك الموارد المخصصة. - (.
queue). endpoints. - .
- « », namespace’ .
- scraping' Prometheus'. .
- , shell.
- YAML- ( JSON).
- JSON logrus (.
LOG_TYPE). -
listen-addresshostNetwork: true. - rate limit (qps, burst) Kubernetes API.
-
kube-serverKubernetes API. - .
- jqFilter libjq-go, jq.
- zombie reaper,
SIGCHLD-, Bash-. — tini. - تم تنفيذ العديد من التبسيط لربط مشغل الأصداف كمكتبة.
- نسخة محدثة
kubectl(من 1.13 إلى 1.17.4) وعملت على أساس جبال الألب 3.11.
الخطط والخطط
لا يزال مشروع القاذفة رسميا في مرحلة تجريبية . على الرغم من ذلك ، كما هو مذكور أعلاه ، فإننا نستخدمه بشكل مكثف للغاية كأساس لعامل التشغيل الإضافي - وهي أداة يتم استخدامها باستمرار في العديد من مجموعات (K8s) (100+).
من أجل إطلاق مستقر لمشغل shell كمشروع عام ، نخطط (على الأقل):
- إضافة اختبار e2e ( # 63 ) ،
- تنفيذ بناء متعدد المعمارية ( # 184 ) ،
- قم بتحديث client-go إلى 0.18.0 ،
contextثم نفذ التخزين المؤقت للكائن ومعالجته أخيرًا في client-go ( # 188 ).
اعتراف المجتمع
على مر السنين ، رأينا اهتمامًا واضحًا من المجتمع في شركة shell:
- لم يتم ذكر المشروع فقط في قوائم مختلفة من المرافق المفيدة لـ Kubernetes ( awesome-kubernetes ، Cloud Zone ) ، ولكن أيضًا في ندوات عبر الإنترنت متخصصة ( Weaveworks ) ، والاجتماعات ( K8s Meetup Tokyo ) وحتى في كتاب .
- ( — K8s- KubeSphere). GitHub , shell-operator ( ).
- : , .
- GitHub 600+ — , ! ;-)
يسعدنا أيضًا أن نعلن أنه في المؤتمر الافتراضي القادم KubeCon + CloudNativeCon Europe 2020 ، الذي سيعقد في أغسطس ، سيكون هناك تقريرنا عن شركة shell. التفاصيل على موقع الحدث .
شكرًا لاهتمامك بشركة shell! إذا كانت لديك أي أسئلة ، فاطلبها هنا في التعليقات أو في قناة tg-channelkubeoperator .
ملاحظة
اقرأ أيضا على مدونتنا: