Geekly articles weekly

تقديم مكتبة kubedog لتتبع موارد Kubernetes

يسرنا أن نعلن عن تطوير جديد مفتوح المصدر لشركة Flant لمتخصصي DevOps وليس فقط kubedog . هذه مكتبة مكتوبة بخط اليد و CLI بناءً عليها لتتبع أحداث موارد Kubernetes وجمع سجلاتهم.


تدعم المكتبة حاليًا تتبع الموارد التالية: Pod (و Container) و Job و Deployment و StatefulSet و DaemonSet. تنتقل الأحداث والسجلات من خلال عمليات الاسترجاعات.

لدى kubedog CLI وضعان للتشغيل:

  • مسار بدء التشغيل - تتبع المورد حتى يتم الوصول إلى حالة الاستعداد والخروج في حالة وجود خطأ للاستخدام المريح في CI / CD ؛
  • متابعة - طباعة الأحداث والسجلات على الشاشة دون الخروج ، على غرار tail -f .

المشكلة


لماذا بدأنا في كتابة مكتبة جديدة في حالة وجود مشاريع مماثلة بالفعل (راجع "العمل باستخدام السجلات" في هذا الاستعراض ) ؟ يتم استخدام Kubedog في الأداة المساعدة DevOps dapp لدينا لتتبع نشر مخططات Helm. لا تعرف Helm نفسها كيفية مراقبة حالة الموارد التي تضيفها ، ولا يتم توفير نقل السجل على مستوى تفاعل GRPC بين Helm و tiller. في هذه المناسبة ، هناك مشكلتنا 3481 ، والتي قمنا في إطارها أيضًا بتطبيق تتبع الموارد المضافة ... ومع ذلك ، فإن مشروع Helm يتردد الآن في إضافة ميزات جديدة إلى Helm 2 ، حيث تتركز كل الجهود على الإصدار الجديد من Helm 3 . لهذا السبب ، قررنا فصل kubedog إلى مشروع منفصل.

ماذا تحتاج مكتبة تتبع الموارد؟

  • الحصول على سجلات Pods التي تنتمي إلى مورد - على سبيل المثال ، النشر.
  • الاستجابة للتغيرات في تكوين Pods التي تنتمي إلى المورد: إضافة سجلات استلام من Pods جديدة ، تعطيل سجلات من Pods من ReplicaSets القديمة.
  • تتبع الأحداث التي تأتي فك تشفير الأخطاء المختلفة. على سبيل المثال ، لا يمكن إنشاء Pod بسبب صورة غير معروفة أو يتم إنشاء Pod ، ولكن الأمر المحدد في القالب ليس في الصورة.
  • ويتمثل أحد المتطلبات الأخرى في تتبع انتقال مورد من rollout إلى وضع ready . ولكل مورد شروطه الخاصة لهذا الغرض.

كما تعتقد ، حاولنا في kubedog أن نأخذ بعين الاعتبار كل ما سبق .

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

الحلول الحالية


kubespy


→ جيثب

  • قادر على مراقبة النشر والخدمة فقط ، ويتفاعل مع السنفات الجديدة.
  • هناك طريقة تتبع لوصف المورد وحالته ومخرجات التغييرات في شكل فرق json.
  • يوجد تمثيل جدولي باللون للتغييرات التي توضح حالة النسخ المتماثلة والشروط.
  • لا تظهر سجلات جراب.
  • إنه مكتوب في Go ، لكن لا يمكن استخدامه كمكتبة.

kubetail


→ جيثب

  • نص باش يستدعي kubectl.
  • قادرة على إظهار سجلات السنفات الموجودة.
  • لا يكشف عن السنفات الجديدة ؛ في حالة حدوث الاستعادة ، يجب إعادة تشغيل kubetail.

صارمة


→ جيثب

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

قتل


→ جيثب

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

k8stail


→ جيثب

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

kubedog


→ جيثب

  • يعمل CLI في وضعين: التعقب والتتبع اللانهائيان حتى يتغير المورد إلى حالة READY.
  • بتتبع مورد واحد.
  • يتفاعل مع التغييرات في الموارد ، وتؤيد سجلات السنفات الجديدة.
  • قادرة على مراقبة النشر ، StatefulSet ، DaemonSet ، الوظيفة أو قرنة منفصلة.
  • مكتوب في Go ، يمكنك استخدامه كمكتبة لإضافة موارد إلى البرنامج لمراقبة حالة الموارد وتلقي السجلات من الحاويات.

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

kubedog جدا!


جوهر عمل kubedog هو كما يلي: بالنسبة للمورد المحدد ، قم بتشغيل Watchers on Events وعلى Pods المنتمين إلى المورد ، وعندما يظهر Pod ، قم بتشغيل المسجل الخاص به. يتم بث كل ما يحدث مع المورد إلى العميل عن طريق استدعاء عمليات الاسترجاعات.

دعونا نلقي نظرة على مثال DaemonSet ، والذي يتوفر للرمز الذي يستخدم المكتبة. واجهة رد الاتصال لـ Deployment و StatefulSet و DaemonSet هي نفسها * - هذا هو ControllerFeed :

 type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error }

* الاستثناء هو AddedReplicaSet ، وهو أمر منطقي فقط AddedReplicaSet (لا يمكنك تحديد هذه الطريقة لتتبع DaemonsSet).

توضيحات لطرق الواجهة الأخرى:

  • Added يتوافق مع الحدث watch.Added للمراقب للمورد المحدد ؛
  • يتم استدعاء Ready عندما يكون المورد قد دخل في حالة Ready (على سبيل المثال ، في DaemonSet ، هذه هي اللحظة التي يتزامن فيها عدد Pods المحدثة والمتاحة مع العدد "المطلوب" من Pods) ؛
  • Failed - تسمى هذه الطريقة عند حذف مورد أو في حالة تلقي حدث مع سبب الخطأ ووصفه (على سبيل المثال ، FailedCreate ) ؛
  • يتم استدعاء EventMsg لكل حدث تم استلامه من المورد أو وحداته: هذه أحداث حول إنشاء المورد ، حول تحميل الصور ، إلخ. بما في ذلك رسائل الخطأ ؛
  • AddedPod - طريقة يمكنك من خلالها اللحاق بخلق قرون جديدة ؛
  • يتم استدعاء PodLogChunk عندما تأتي قطعة أخرى من سجلات من Kubernetes API ؛
  • سيتم PodError إذا فشل Pod.

قد يؤدي كل رد اتصال إلى إرجاع StopTrack نوع StopTrack وسيتم إكمال التتبع. لذلك ، على سبيل المثال ، تم القيام به في تعقب بدء التشغيل - تقوم Ready StopTrack و CLI تنهي عملها.

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

هذه هي الطريقة التي يبدو بها ، على سبيل المثال ، الناتج غير المحدود لسجلات DaemonSet بدون معلومات إضافية حول الأحداث والحالة:

 // kubedog     Kubernetes',    // . https://github.com/flant/kubedog/blob/master/pkg/kube/kube.go kubeClient, err := kubernetes.NewForConfig(config) if err != nil { return err } feed := &tracker.ControllerFeedProto{ PodLogChunkFunc: func(chunk *tracker.ReplicaSetPodLogChunk) error { for _, line := range chunk.LogLines { fmt.Printf(">> po/%s %s: %s\n", chunk.PodName, chunk.ContainerName, line) } return nil }, } //    timeout   API   ,     .   ,     ,    Pod'. opts := tracker.Options{ Timeout: time.Second * time.Duration(300), LogsFromTime: time.Now(), } tracker.TrackDaemonSet(dsName, dsNamespace, kubeClient, feed, opts)

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

أمثلة التطبيق


يمكن رؤية استخدام kubedog كمكتبة في الأداة المساعدة dapp. هذا هو المكان الذي يتم فيه تشغيل Trackers الجاهزة للتشغيل للتحقق من الموارد التي ينشئها Helm أو التحديثات.

Kubedog CLI قادر على المساعدة في بدء التشغيل في نظام CI / CD ، وبغض النظر عما إذا كان يتم استخدامه: kubectl ، Helm أو أي شيء آخر. بعد كل شيء ، يمكنك تشغيل kubectl apply ، ثم kubedog rollout track ، وسترى خطأ في سجلات kubedog rollout track إذا حدث خطأ في المورد. سيساعد استخدام kubedog هذا على تقليل الوقت اللازم لتشخيص مشكلات بدء التشغيل.

ما التالي؟


نحن نخطط لتطوير المكتبة في اتجاه دعم المزيد من الموارد - على سبيل المثال ، أريد حقًا متابعة الخدمة والدخول. بالإضافة إلى ذلك ، من المفترض أن تنفذ العمل على تصنيف reason في Event'ah ، من أجل تحديد أكثر دقة اللحظة التي يمكن أن نفترض فيها فشل تعميم المورد. هناك متجه آخر لتطوير المكتبة وهو تتبع العديد من الموارد في وقت واحد ، على سبيل المثال ، من خلال labelSelector أو حسب مساحة الاسم. أرغب أيضًا في دعم التعليقات التوضيحية المختلفة التي يمكن أن تغير طبيعة التتبع ، على سبيل المثال ، بالنسبة لخطافات Helm ، ولكن هذا لا يزال أكثر ملاءمة لـ dapp.

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

كيف تجرب؟


تتوفر إصدارات kubedog CLI لنظامي التشغيل Linux و macOS على bintray .

أتطلع حقًا إلى تعليقاتك ومشكلاتك حول جيثب !

PS


اقرأ أيضًا في مدونتنا:

Source: https://habr.com/ru/post/ar434160/

More articles:


All Articles