chaostoolkit/chaostoolkit-kubernetesChaos Toolkit प्रोब्स और एक्शन्स API का Kubernetes ड्राइवर एक्सटेंशन
इस परियोजना में गतिविधियाँ (activities) शामिल हैं, जैसे probes और actions, जिन्हें आप अपने प्रयोग से Chaos Toolkit के माध्यम से कॉल कर सकते हैं, ताकि Kubernetes API के विरुद्ध Chaos Engineering किया जा सके: किसी pod को समाप्त करना, statefulset या node को हटाना...
अपने प्रयोग में उपयोग करने के लिए, इस पैकेज को उस Python वातावरण में स्थापित किया जाना चाहिए जहाँ chaostoolkit पहले से मौजूद है।
$ pip install chaostoolkit-kubernetes
इस पैकेज के probes और actions का उपयोग करने के लिए, अपनी experiment फ़ाइल में निम्नलिखित जोड़ें:
{
"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
}
}
]
}
बस इतना ही! ध्यान दें कि action आपको यादृच्छिक रूप से एक pod को समाप्त करने का तरीका देता है।
कृपया मौजूदा probes और actions देखने के लिए प्रलेखन देखें।
ध्यान दें, network, cpu और memory stressors के लिए हम शानदार Chaos Mesh परियोजना पर निर्भर हैं, जो इन faults को इंजेक्ट करने के लिए एक बेहतरीन इंटरफ़ेस प्रदान करती है।
इनका उपयोग करने के लिए आपको पहले अपने cluster में Chaos Mesh स्थापित करना होगा।
यदि आपके ~/.kube/config फ़ाइल में उस cluster के लिए एक मान्य प्रविष्टि है जिसे आप लक्षित करना चाहते हैं, तो करने के लिए कुछ भी नहीं है।
आप एक अलग स्थान निर्दिष्ट करने के लिए KUBECONFIG निर्दिष्ट कर सकते हैं।
$ export KUBECONFIG=/tmp/my-config
अक्सर, आपकी Kubernetes कॉन्फ़िगरेशन में कई प्रविष्टियाँ होती हैं, और आपको उसे परिभाषित करने की आवश्यकता होती है जिसे डिफ़ॉल्ट context के रूप में उपयोग किया जाना चाहिए जब इसे स्पष्ट रूप से प्रदान न किया गया हो।
आप निश्चित रूप से kubectl config use-context KUBERNETES_CONTEXT का उपयोग करके अपना डिफ़ॉल्ट बदल सकते हैं, लेकिन आप अपने experiment में निम्नानुसार स्पष्ट भी हो सकते हैं:
{
"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 secret key को उस context के नाम पर निर्दिष्ट करना होगा जिसे experiment उपयोग करना चाहता है। सुनिश्चित करें कि actions और probes को उन secret प्रविष्टियों के बारे में भी सूचित किया जाए जो उन्हें "secrets": ["k8s"] के रूप में दी जानी चाहिए।
किसी pod से चलाते समय (उदाहरण के लिए आपकी स्थानीय मशीन या CI से नहीं), ./.kube/config फ़ाइल मौजूद नहीं होती है। इसके बजाय, क्रेडेंशियल /var/run/secrets/kubernetes.io/serviceaccount/token पर पाए जा सकते हैं।
एक्सटेंशन को इसके बारे में बताने के लिए, बस pod specification के environment variable में CHAOSTOOLKIT_IN_POD सेट करें:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
इस environment variable का उपयोग करते समय, यह मान लिया जाता है कि experiment उसी cluster को लक्षित करता है जहाँ से experiment चल रहा है। यदि आपका experiment किसी भिन्न cluster को लक्षित करता है, तो आपको यह variable सेट नहीं करना चाहिए। इसके बजाय, आप लक्षित cluster के लिए Kubernetes config के साथ एक volume माउंट कर सकते हैं और KUBECONFIG को उसकी ओर इंगित करने के लिए सेट कर सकते हैं।
अंत में, आप experiment को सभी आवश्यक क्रेडेंशियल जानकारी स्पष्ट रूप से निम्नानुसार पास कर सकते हैं:
{
"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 environment variable को परिभाषित करके भी प्राप्त किया जा सकता है।
यदि आप इस पैकेज में और अधिक फ़ंक्शन जोड़ना चाहते हैं, तो आपका स्वागत है। कृपया, इस परियोजना को fork करें, प्रस्तावित परिवर्तनों को कवर करने के लिए unit tests लिखें, परिवर्तनों को लागू करें, सुनिश्चित करें कि वे formatting मानकों को पूरा करते हैं, और फिर समीक्षा के लिए repository में एक PR बनाएँ।
कृपया formatting मानकों के बारे में अधिक जानकारी के लिए formatting अनुभाग देखें।
Chaos Toolkit परियोजनाओं के लिए आवश्यक है कि सभी योगदानकर्ता repository की master branch में merge किए जाने वाले प्रत्येक commit पर Developer Certificate of Origin पर हस्ताक्षर करें। कृपया सुनिश्चित करें कि PR जमा करने से पहले आप DCO के नियमों का पालन कर सकते हैं।
यदि आप इस परियोजना पर विकास करना चाहते हैं, तो सुनिश्चित करें कि आप development निर्भरताएँ स्थापित करें। लेकिन पहले, PDM स्थापित करें और फिर निर्भरताएँ स्थापित करें।
$ pdm install
अब, आप फ़ाइलों को संपादित कर सकते हैं, और वे स्वचालित रूप से आपके वातावरण द्वारा देखी जाएँगी, भले ही आप स्थानीय रूप से chaos कमांड से चला रहे हों।
परियोजना के लिए परीक्षण चलाने हेतु निम्नलिखित निष्पादित करें:
$ pdm run tests
हम इस repository के कोड को lint और format दोनों के लिए ruff का उपयोग करते हैं।
Pull Request बनाने से पहले, हम अनुशंसा करते हैं कि आप अपने कोड पर निम्न के साथ formatting चलाएँ:
$ pdm run format
यह स्वचालित रूप से किसी भी कोड को format करेगा जो formatting मानकों का पालन नहीं करता है।
चूँकि कुछ चीज़ें formatting द्वारा पकड़ में नहीं आती हैं, हम यह भी अनुशंसा करते हैं कि आप निम्न चलाएँ:
$ pdm run lint
यह सुनिश्चित करने के लिए कि कोई भी अप्रयुक्त import statements/अत्यधिक लंबी strings, आदि भी पकड़ में आ जाएँ।