
امتداد برنامج تشغيل Kubernetes لواجهة برمجة تطبيقات الفحوصات والإجراءات الخاصة بـ Chaos Toolkit
يحتوي هذا المشروع على أنشطة، مثل الفحوصات (probes) والإجراءات (actions)، يمكنك استدعاؤها من تجربتك عبر Chaos Toolkit لتنفيذ هندسة الفوضى (Chaos Engineering) ضد واجهة برمجة تطبيقات Kubernetes: قتل جراب (pod)، إزالة مجموعة حليّة (statefulset) أو عقدة (node)...
لاستخدامها من تجربتك، يجب تثبيت هذه الحزمة في بيئة Python التي يوجد بها chaostoolkit بالفعل.
$ pip install chaostoolkit-kubernetes
لاستخدام الفحوصات والإجراءات من هذه الحزمة، أضف ما يلي إلى ملف تجربتك:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
هذا كل شيء! لاحظ كيف يمنحك الإجراء طريقة لقتل جراب واحد بشكل عشوائي.
يرجى استكشاف التوثيق للاطلاع على الفحوصات والإجراءات الموجودة.
لاحظ، بالنسبة لمسببات إجهاد الشبكة والمعالج والذاكرة، نعتمد على مشروع Chaos Mesh الرائع الذي يوفر واجهة رائعة لحقن هذه الأعطال.
ستحتاج إلى تثبيت Chaos Mesh أولاً في مجموعتك لاستخدامها.
إذا كان لديك إدخال صالح في ملف ~/.kube/config الخاص بك للمجموعة التي
تريد استهدافها، فلا حاجة لفعل أي شيء.
يمكنك تحديد KUBECONFIG لتحديد موقع مختلف.
$ export KUBECONFIG=/tmp/my-config
غالباً ما يحتوي إعداد Kubernetes الخاص بك على عدة إدخالات، وتحتاج إلى تحديد الإدخال الذي سيُستخدم كسياق افتراضي عندما لا يتم توفيره صراحةً.
يمكنك بالطبع تغيير الافتراضي باستخدام
kubectl config use-context KUBERNETES_CONTEXT ولكن يمكنك أيضاً أن تكون صريحاً
في تجربتك كما يلي:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"secrets": {
"k8s": {
"KUBERNETES_CONTEXT": "..."
}
},
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
تحتاج إلى تحديد مفتاح السر KUBERNETES_CONTEXT باسم السياق الذي تريد أن تستخدمه التجربة. تأكد أيضاً من إعلام الإجراءات والفحوصات بإدخالات السر التي يجب تمريرها إليها عبر "secrets": ["k8s"].
عند التشغيل من داخل جراب (وليس من جهازك المحلي أو بيئة CI مثلاً)، فإن ملف
./.kube/config غير موجود. بدلاً من ذلك، يمكن العثور على بيانات الاعتماد
في /var/run/secrets/kubernetes.io/serviceaccount/token.
لإعلام الإضافة بذلك، ما عليك سوى تعيين CHAOSTOOLKIT_IN_POD من
متغيرات البيئة في مواصفات الجراب:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
عند استخدام متغير البيئة هذا، يُفترض أن التجربة
تستهدف نفس المجموعة التي تُشغَّل منها التجربة. إذا كانت
تجربتك تستهدف مجموعة مختلفة، فلا يجب عليك تعيين هذا المتغير.
بدلاً من ذلك، يمكنك تركيب وحدة تخزين (volume) تحتوي على إعداد Kubernetes للمجموعة
المستهدفة وتعيين KUBECONFIG للإشارة إليها.
أخيراً، يمكنك تمرير جميع معلومات بيانات الاعتماد المطلوبة صراحةً إلى التجربة كما يلي:
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_API_KEY": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_USERNAME": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_PASSWORD": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_CERT_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_KEY_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
في بعض مجموعات Kubernetes المُدارة، تحتاج أيضاً إلى المصادقة ضد المنصة نفسها لأن مصادقة Kubernetes مفوَّضة إليها.
بالإضافة إلى بيانات اعتماد Kubernetes الخاصة بك (عبر ملف ~/.kube/config)،
تحتاج إلى المصادقة ضد Google Cloud Platform نفسها. عادةً
يتم ذلك عبر:
$ gcloud auth login
ولكن يمكن تحقيقه أيضاً بتعريف متغير البيئة
GOOGLE_APPLICATION_CREDENTIALS.
إذا كنت ترغب في المساهمة بمزيد من الدوال في هذه الحزمة، فنحن نرحب بك كثيراً. يرجى عمل fork لهذا المشروع، وكتابة اختبارات وحدة لتغطية التغييرات المقترحة، وتنفيذ التغييرات، والتأكد من أنها تلبي معايير التنسيق، ثم رفع PR إلى المستودع للمراجعة.
يرجى الرجوع إلى قسم التنسيق لمزيد من المعلومات حول معايير التنسيق.
تتطلب مشاريع Chaos Toolkit من جميع المساهمين التوقيع على شهادة مصدر المطوّر (Developer Certificate of Origin) في كل التزام (commit) يرغبون في دمجه في الفرع الرئيسي للمستودع. يرجى التأكد من قدرتك على الالتزام بقواعد DCO قبل تقديم PR.
إذا كنت ترغب في التطوير على هذا المشروع، فتأكد من تثبيت اعتماديات التطوير. لكن أولاً، قم بتثبيت PDM ثم ثبّت الاعتماديات.
$ pdm install
الآن، يمكنك تعديل الملفات، وستتم رؤيتها تلقائياً في
بيئتك، حتى عند التشغيل من الأمر chaos محلياً.
لتشغيل اختبارات المشروع نفذ ما يلي:
$ pdm run tests
نستخدم ruff لفحص وتنسيق كود هذا المستودع.
قبل رفع طلب سحب (Pull Request)، نوصي بتشغيل التنسيق على الكود الخاص بك باستخدام:
$ pdm run format
سيؤدي هذا تلقائياً إلى تنسيق أي كود لا يلتزم بمعايير التنسيق.
نظراً لأن بعض الأشياء لا يلتقطها التنسيق، نوصي أيضاً بتشغيل:
$ pdm run lint
لضمان التقاط أي عبارات استيراد غير مستخدمة/سلاسل طويلة جداً، وما إلى ذلك.