
Chaos 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 प्रमाणीकरण उसे सौंप दिया गया है।