chaoskube

chaoskube تقوم بشكل دوري بقتل pods عشوائية في عنقود Kubernetes الخاص بك.

لماذا

اختبر كيف يتصرف نظامك تحت حالات فشل pods عشوائية.

مثال

عند تشغيله، سيقتل pod في أي namespace كل 10 دقائق افتراضيًا.

$ chaoskube
INFO[0000] starting up              dryRun=true interval=10m0s version=v0.21.0
INFO[0000] connecting to cluster    master="https://kube.you.me" serverVersion=v1.10.5+coreos.0
INFO[0000] setting pod filter       annotations= labels= minimumAge=0s namespaces=
INFO[0000] setting quiet times      daysOfYear="[]" timesOfDay="[]" weekdays="[]"
INFO[0000] setting timezone         location=UTC name=UTC offset=0
INFO[0001] terminating pod          name=kube-dns-v20-6ikos namespace=kube-system
INFO[0601] terminating pod          name=nginx-701339712-u4fr3 namespace=chaoskube
INFO[1201] terminating pod          name=kube-proxy-gke-earthcoin-pool-3-5ee87f80-n72s namespace=kube-system
INFO[1802] terminating pod          name=nginx-701339712-bfh2y namespace=chaoskube
INFO[2402] terminating pod          name=heapster-v1.2.0-1107848163-bhtcw namespace=kube-system
INFO[3003] terminating pod          name=l7-default-backend-v1.0-o2hc9 namespace=kube-system
INFO[3603] terminating pod          name=heapster-v1.2.0-1107848163-jlfcd namespace=kube-system
INFO[4203] terminating pod          name=nginx-701339712-bfh2y namespace=chaoskube
INFO[4804] terminating pod          name=nginx-701339712-51nt8 namespace=chaoskube
...

chaoskube تسمح بتصفية pods المستهدفة حسب namespaces وlabels وannotations والعمر وكذلك استبعاد أيام معينة من الأسبوع، وأوقات معينة من اليوم، وأيام معينة من السنة من الفوضى (chaos).

كيفية الاستخدام

Helm

يمكنك تثبيت chaoskube باستخدام Helm. اتبع دليل Helm للبدء السريع ثم ثبّت مخطط (chart) chaoskube.

$ helm repo add chaoskube https://linki.github.io/chaoskube/
$ helm install chaoskube chaoskube/chaoskube --atomic --namespace=chaoskube --create-namespace

راجع chaoskube على kubeapps.com لتعلّم كيفية إعداده وللعثور على مخططات Helm مفيدة أخرى.

المانيفست الخام

راجع المانيفست المثال. تأكد من منح chaoskube الصلاحيات المناسبة باستخدام ClusterRole الموفّر.

الإعداد

افتراضيًا، يكون chaoskube ودودًا ولا يقتل أي شيء. عندما تتحقق من عنقودك المستهدف، يمكنك تعطيل وضع dry-run بتمرير العلامة --no-dry-run. يمكنك أيضًا تحديد فترة زمنية أكثر تكرارًا وعلامات أخرى مدعومة لنشرك.

إذا كنت تعمل داخل عنقود Kubernetes وتريد استهداف العنقود نفسه، فهذا كل ما تحتاج إليه.

إذا كنت تريد استهداف عنقود مختلف أو تشغيله محليًا، فحدد عنقودك عبر علامة --master أو وفّر kubeconfig صالحًا عبر علامة --kubeconfig. افتراضيًا، يستخدم مسار kubeconfig القياسي في مجلدك الرئيسي. وهذا يعني أنه سيتم استهداف أي سياق (context) حالي موجود فيه.

إذا أردت زيادة أو تقليل مقدار الفوضى، غيّر الفترة الزمنية بين عمليات القتل بعلامة --interval. بدلًا من ذلك، يمكنك زيادة عدد نسخ (replicas) نشر chaoskube.

تذكّر أن chaoskube يقتل افتراضيًا أي pod في جميع namespaces الخاصة بك، بما في ذلك pods النظام ونفسه.

chaoskube يوفّر نقطة نهاية HTTP بسيطة يمكن استخدامها للتحقق من أنه يعمل. يمكن استخدامها لـ فحوصات liveness و readiness الخاصة بـ Kubernetes. افتراضيًا، يستمع على المنفذ 8080. لتعطيل ذلك، مرّر --metrics-address="" إلى chaoskube.

تصفية الأهداف

ومع ذلك، يمكنك تقييد نطاق بحث chaoskube عبر توفير محددات label وannotation وnamespace، وأنماط تضمين/استبعاد لأسماء pods، بالإضافة إلى إعداد حد أدنى للعمر.

$ chaoskube --labels 'app=mate,chaos,stage!=production'
...
INFO[0000] setting pod filter       labels="app=mate,chaos,stage!=production"

يحدد هذا جميع pods التي تحتوي على label app بقيمة mate، وlabel chaos بأي قيمة، وlabel stage غير مضبوطة على production أو غير مضبوطة.

يمكنك أيضًا تصفية pods المستهدفة بمحدد namespace.

$ chaoskube --namespaces 'default,testing,staging'
...
INFO[0000] setting pod filter       namespaces="default,staging,testing"

سيؤدي هذا إلى تصفية pods في namespaces الثلاثة default وstaging وtesting.

يمكن تصفية namespaces أيضًا بمحدد label خاص بالـ namespaces.

$ chaoskube --namespace-labels='!integration'
...
INFO[0000] setting pod filter       namespaceLabels="!integration"

سيؤدي هذا إلى استبعاد جميع pods من namespaces التي تحمل label integration.

يمكنك تصفية pods المستهدفة بمحدد kind الخاص بـ OwnerReference.

$ chaoskube --kinds '!DaemonSet,!StatefulSet'
...
INFO[0000] setting pod filter       kinds="!DaemonSet,!StatefulSet"

سيؤدي هذا إلى استبعاد أي pods من نوع DaemonSet وStatefulSet.

$ chaoskube --kinds 'DaemonSet'
...
INFO[0000] setting pod filter       kinds="DaemonSet"

سيؤدي هذا إلى تضمين أي pods من نوع DaemonSet فقط.

يرجى ملاحظة: أي عامل تصفية include سيستبعد تلقائيًا جميع pods التي لا تحتوي على OwnerReference محدد.

يمكنك تصفية pods بالاسم:

$ chaoskube --included-pod-names 'foo|bar' --excluded-pod-names 'prod'
...
INFO[0000] setting pod filter       excludedPodNames=prod includedPodNames="foo|bar"

سيؤدي هذا إلى استهداف فقط pods التي يحتوي اسمها على 'foo' أو 'bar' ولا يحتوي لا على 'prod'.

يمكنك أيضًا استبعاد namespaces والجمع بين محددات label وannotation.

$ chaoskube \
    --labels 'app=mate,chaos,stage!=production' \
    --annotations '!scheduler.alpha.kubernetes.io/critical-pod' \
    --namespaces '!kube-system,!production'
...
INFO[0000] setting pod filter       annotations="!scheduler.alpha.kubernetes.io/critical-pod" labels="app=mate,chaos,stage!=production" namespaces="!kube-system,!production"

يحدّ هذا أيضًا من نطاق بحث محدد label أعلاه عبر استبعاد أي pods في namespaces kube-system وproduction وتجاهل جميع pods الموسومة بأنها حرجة (critical).

يمكن أيضًا استخدام محدد annotation لتشغيل chaoskube كإضافة (addon) للعنقود والسماح للـ pods بالاشتراك في أن يتم إنهاؤها كما تراه مناسبًا. على سبيل المثال، يمكنك تشغيل chaoskube هكذا:

$ chaoskube --annotations 'chaos.alpha.kubernetes.io/enabled=true' --debug
...
INFO[0000] setting pod filter       annotations="chaos.alpha.kubernetes.io/enabled=true"
DEBU[0000] found candidates         count=0
DEBU[0000] no victim found

ما لم تكن تستخدم هذا الـ annotation في مكان آخر، فسيتجاهل هذا جميع pods في البداية (يمكنك رؤية عدد المرشحين في وضع التصحيح). يمكنك بعد ذلك اختياريا إشراك نشرات (deployments) فردية في وضع الفوضى عبر إضافة تعليق توضيحي (annotation) إلى pods الخاصة بها بالقيمة chaos.alpha.kubernetes.io/enabled=true.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  template:
    metadata:
      annotations:
        chaos.alpha.kubernetes.io/enabled: "true"
    spec:
      ...

يمكنك استبعاد pods التي بدأت مؤخرًا باستخدام علامة --minimum-age.

$ chaoskube --minimum-age 6h
...
INFO[0000] setting pod filter       minimumAge=6h0m0s

الحد من الفوضى

يمكنك تحديد الوقت الذي تُدخَل فيه الفوضى حسب أيام الأسبوع، أو فترات زمنية من اليوم، أو أيام من السنة، أو كل ذلك معًا.

أضف قائمة مفصولة بفواصل من أيام الأسبوع المختصرة عبر خيار --excluded-weekdays، وقائمة مفصولة بفواصل من الفترات الزمنية عبر خيار --excluded-times-of-day و/أو قائمة مفصولة بفواصل من أيام السنة عبر خيار --excluded-days-of-year، وحدد --timezone لتفسيرها وفقًا له.

$ chaoskube \
    --excluded-weekdays=Sat,Sun \
    --excluded-times-of-day=22:00-08:00,11:00-13:00 \
    --excluded-days-of-year=Apr1,Dec24 \
    --timezone=Europe/Berlin
...
INFO[0000] setting quiet times      daysOfYear="[Apr 1 Dec24]" timesOfDay="[22:00-08:00 11:00-13:00]" weekdays="[Saturday Sunday]"
INFO[0000] setting timezone         location=Europe/Berlin name=CET offset=1

استخدم UTC أو Local أو اختر اسم منطقة زمنية من قاعدة بيانات (IANA) tz. إذا كنت تختبر chaoskube من جهازك المحلي، فإن Local هو الخيار الأكثر منطقية. بمجرد نشر chaoskube في عنقودك، يجب نشره بمنطقة زمنية محددة، مثل المنطقة التي يعيش فيها معظم أعضاء فريقك، بحيث يكون لدى فريقك وchaoskube فهم مشترك لمتى يبدأ وينتهي يوم أسبوعي معين، على سبيل المثال. إذا كان فريقك موزعًا عبر مناطق زمنية متعددة، فمن الأرجح اختيار UTC، وهو أيضًا الافتراضي. اختيار منطقة زمنية خاطئة يغيّر معنى يوم أسبوعي معين ببضع ساعات بينك وبين الخادم.

الخيارات

أعمال ذات صلة

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

• kube-monkey هو قرد فوضى (chaos monkey) متطور قائم على pods لـ Kubernetes. كل صباح يقوم بتجميع جدول لعمليات إنهاء pods التي يجب أن تحدث على مدار اليوم. يسمح بتحديد متوسط الوقت بين حالات الفشل على أساس كل pod، وهي ميزة يفتقر إليها chaoskube lacks. كما يمكنه أن يكون على دراية بمجموعات pods التي تشكل تطبيقًا بحيث يمكنه التعامل معها بشكل خاص، مثل قتل جميع pods لتطبيق ما دفعة واحدة. يسمح kube-mokey بتصفية الأهداف عالميًا عبر خيارات الإعداد بالإضافة إلى السماح للـ pods بالاشتراك في الفوضى عبر annotations، ويسمح للتطبيقات الفردية بالاشتراك بطريقتها الخاصة الفريدة، على سبيل المثال، يمكن للتطبيق-أ أن يطلب قتل pod واحد كل يوم من أيام الأسبوع، بينما التطبيق-ب الأكثر شجاعة يمكنه طلب قتل 50% من pods. إنه يفهم ملف إعداد مشابهًا لذلك الذي يستخدمه Netflix's ChaosMonkey.
• PowerfulSeal هي أداة قوية بالفعل لإزعاج إعداد Kubernetes الخاص بك. بالإضافة إلى قتل pods، يمكنها أيضًا إخراج أجهزة Cloud VMs أو قتل Docker daemon لديك. لديها عدد كبير من خيارات الإعداد لتحديد ما يمكن قتله ومتى. كما أن لديها وضعًا تفاعليًا يسمح لك بقتل pods بسهولة.
• fabric8's chaos monkey: قرد فوضى يأتي مضمّنًا كتطبيق مع منصة Kubernetes الخاصة بـ fabric8. يمكن نشره عبر واجهة مستخدم ويبلغ عن أي إجراءات تم اتخاذها كرسالة دردشة و/أو إشعار سطح مكتب. يمكن إعداده بفترة زمنية ونمط اسم pod يجب أن تطابقه الأهداف المحتملة.
• k8aos: أداة تفاعلية يمكنها إصدار سلسلة من عمليات حذف pods عشوائية عبر عنقود Kubernetes بأكمله أو مقتصرة على namespace.
• pod-reaper يقتل pods بناءً على فترة زمنية واحتمال فوضى قابل للإعداد. يسمح بتحديد pods محتملة كأهداف عبر محدد label وnamespace. لديه القدرة على إيقاف تشغيل نفسه بنجاح بعد فترة، وبالتالي قد يكون مناسبًا للعمل بشكل جيد مع كائنات Kubernetes Job. يمكن أيضًا إعداده لقتل كل pod ظل يعمل لفترة أطول من مدة قابلة للإعداد.

شكر وتقدير

هذا المشروع لن يصل إلى ما هو عليه دون أفكار ومساعدة العديد من المساهمين الرائعين:

• شكرًا لـ @twildeboer و@klautcomputing اللذين أطلقا فكرة الحد من الفوضى خلال أوقات معينة، مثل ساعات العمل أو العطلات بالإضافة إلى أول تطبيقات لهذه الميزة في #54 و#55.
• شكرًا لـ @klautcomputing على المحاولة الأولى لحل ميزة النسبة المئوية المفقودة وكذلك لتوفير ملفات إعداد RBAC.
• شكرًا لـ @j0sh3rs لرفع مخطط Helm إلى أحدث إصدار.
• شكرًا لـ @klautcomputing و@grosser و@twz123 و@hchenxa و@bavarianbidi لتحسينات Dockerfile والوثائق في #31 و#40 و#58.
• شكرًا لـ @bakins لإضافة مرشح الحد الأدنى للعمر في #86.
• شكرًا لـ @bakins لإضافة فحص الصحة ومقاييس Prometheus في #94 و#97.

المساهمة

لا تتردد في إنشاء issues أو إرسال pull requests.