
مشغّل Kubernetes لحقن تجارب الفوضى في أعباء العمل السحابية الأصلية، وأتمتة اختبارات المرونة وتحصين أعباء العمل عبر موارد CRD التصريحية.
يُستخدم مشغّل فوضى Litmus من قبل مطوّري تطبيقات Kubernetes ومهندسي الموثوقية (SREs) لحقن الفوضى في التطبيقات والبنية التحتية لـ Kubernetes بطريقة مُدارة. تتمثل أهدافه في جعل عملية التحقق وتقوية أعباء العمل التطبيقية على Kubernetes سهلة من خلال أتمتة تنفيذ تجارب الفوضى. يمكن أن يكون سير عمل نموذجي لحقن الفوضى ببساطة كما يلي:
تشمل الفوائد التي يقدمها مشغّل الفوضى ما يلي:
مشغّل الفوضى هو مشغّل Kubernetes (Kubernetes Operator)، وهو ليس سوى وحدات تحكم مخصصة (custom-controllers) بوصول مباشر إلى Kubernetes API يمكنها إدارة دورة حياة موارد أو تطبيقات معينة، مع الحرص دائمًا على ضمان بقاء المورد في "الحالة المرغوبة". تُسمى المنطقية التي تضمن ذلك عادةً بوظيفة "reconcile".
تم بناء مشغّل الفوضى باستخدام إطار العمل الشهير Operator-SDK، والذي يوفر دعمًا أوليًا (bootstrap) لمشاريع المشغّلات الجديدة، مما يسمح للفرق بالتركيز على المنطق التشغيلي/الأعمال.
يساعد مشغّل فوضى Litmus في مزامنة (reconcile) حالة ChaosEngine، وهو مورد مخصص يحتوي على نية الفوضى المحددة من قبل مطور/مهندس DevOps تجاه نشر Kubernetes معين عديم الحالة أو ذي حالة. ينفذ المشغّل إجراءات محددة عند عمليات الإنشاء والقراءة والتحديث والحذف (CRUD) لـ ChaosEngine، مورده الأساسي. كما يعرّف المشغّل موردًا ثانويًا (وهو pod مشغّل المحرك)، يتم إنشاؤه وإدارته بواسطته لتنفيذ وظائف المزامنة.
ChaosEngine هو المخطط الأساسي الذي يحدد سير عمل الفوضى لتطبيق معين. حاليًا، يحدد ما يلي:
يُشار إلى ChaosEngine بصفته مالك المورد الثانوي (المزامنة) مع خاصية deletePropagation في Kubernetes لضمان إزالتها أيضًا عند حذف مورد ChaosEngine.
فيما يلي نموذج لـ ChaosEngineSpec للمرجعية: https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine
تُستخدم Litmus Chaos Charts لتثبيت "حزم تجارب الفوضى" وتُصنَّف بناءً على طبيعة التجارب (فوضى Kubernetes العامة، فوضى خاصة بالبائع/المزود - مثل OpenEBS أو فوضى خاصة بتطبيق معين، مثل NuoDB). وهي تتكون من موارد مخصصة تحتوي على معاملات فوضى (اختبار) منخفضة المستوى، والتي يستعلمها المشغّل من أجل تنفيذ التجارب. تُستخدم fields الموجودة في spec.definition و values المقابلة لها لبناء الأداة التنفيذية النهائية التي تشغّل تجربة الفوضى (عادةً ما تكون litmusbook، وهي مورد وظيفة K8s). كما تحدد الأذونات اللازمة لتنفيذ التجربة.
فيما يلي نموذج لـ ChaosEngineSpec للمرجعية:
apiVersion: litmuschaos.io/v1alpha1
description:
message: |
Deletes a pod belonging to a deployment/statefulset/daemonset
kind: ChaosExperiment
metadata:
name: pod-delete
labels:
name: pod-delete
app.kubernetes.io/part-of: litmus
app.kubernetes.io/component: chaosexperiment
app.kubernetes.io/version: latest
spec:
definition:
scope: Namespaced
permissions:
- apiGroups:
- ""
- "apps"
- "batch"
- "litmuschaos.io"
resources:
- "deployments"
- "jobs"
- "pods"
- "configmaps"
- "chaosengines"
- "chaosexperiments"
- "chaosresults"
verbs:
- "create"
- "list"
- "get"
- "patch"
- "update"
- "delete"
image: "litmuschaos/go-runner:latest"
imagePullPolicy: Always
args:
- -c
- ./experiments -name pod-delete
command:
- /bin/bash
env:
- name: TOTAL_CHAOS_DURATION
value: '15'
# Period to wait before/after injection of chaos in sec
- name: RAMP_TIME
value: ''
- name: FORCE
value: 'true'
- name: CHAOS_INTERVAL
value: '5'
## percentage of total pods to target
- name: PODS_AFFECTED_PERC
value: ''
- name: LIB
value: 'litmus'
- name: TARGET_PODS
value: ''
## it defines the sequence of chaos execution for multiple target pods
## supported values: serial, parallel
- name: SEQUENCE
value: 'parallel'
labels:
name: pod-delete
app.kubernetes.io/part-of: litmus
app.kubernetes.io/component: experiment-job
app.kubernetes.io/version: latest
راجع توثيق LitmusChaos وثائق litmus
يمكنك المساهمة عن طريق فتح القضايا (issues)، وتحسين التوثيق، والمساهمة في الإطار الأساسي والأدوات، وما إلى ذلك.
توجّه إلى دليل المساهمة