
Extension du pilote Kubernetes de l'API de sondes et d'actions du Chaos Toolkit
Ce projet contient des activités, telles que des sondes et des actions, que vous pouvez appeler depuis votre expérience via le Chaos Toolkit pour effectuer de l'ingénierie du chaos contre l'API Kubernetes : tuer un pod, supprimer un statefulset ou un nœud...
Pour être utilisé depuis votre expérience, ce paquet doit être installé dans l'environnement Python où chaostoolkit existe déjà.
$ pip install chaostoolkit-kubernetes
Pour utiliser les sondes et actions de ce paquet, ajoutez ce qui suit à votre fichier d'expérience :
{
"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
}
}
]
}
Et voilà ! Remarquez comment l'action vous permet de tuer un pod aléatoirement.
Veuillez explorer la documentation pour découvrir les sondes et actions existantes.
Notez que pour les stress tests réseau, CPU et mémoire, nous nous appuyons sur le fantastique projet Chaos Mesh qui fournit une excellente interface pour injecter ces pannes.
Vous devrez d'abord installer Chaos Mesh dans votre cluster pour les utiliser.
Si vous avez une entrée valide dans votre fichier ~/.kube/config pour le cluster que vous souhaitez cibler, alors il n'y a rien à faire.
Vous pouvez spécifier KUBECONFIG pour indiquer un autre emplacement.
$ export KUBECONFIG=/tmp/my-config
Bien souvent, votre configuration Kubernetes contient plusieurs entrées, et vous devez définir celle à utiliser comme contexte par défaut lorsqu'il n'est pas fourni explicitement.
Vous pouvez bien sûr changer votre contexte par défaut en utilisant kubectl config use-context KUBERNETES_CONTEXT, mais vous pouvez aussi être explicite dans votre expérience comme suit :
{
"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
}
}
]
}
Vous devez renseigner la clé secrète KUBERNETES_CONTEXT avec le nom du contexte que l'expérience doit utiliser. Assurez-vous également d'informer les actions et les sondes des entrées secrètes qui doivent leur être transmises : "secrets": ["k8s"].
Lorsque vous exécutez depuis un pod (et non depuis votre machine locale ou un CI par exemple), le fichier ./.kube/config n'existe pas. À la place, les identifiants se trouvent dans /var/run/secrets/kubernetes.io/serviceaccount/token.
Pour informer l'extension de cela, définissez simplement CHAOSTOOLKIT_IN_POD dans les variables d'environnement de la spécification du pod :
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
Lorsque cette variable d'environnement est utilisée, il est supposé que l'expérience cible le même cluster depuis lequel l'expérience est exécutée. Si votre expérience cible un cluster différent, vous ne devez pas définir cette variable. À la place, vous pouvez monter un volume contenant une configuration Kubernetes pour le cluster cible et définir KUBECONFIG pour pointer vers celle-ci.
Enfin, vous pouvez transmettre explicitement toutes les informations d'identification requises à l'expérience comme suit :
{
"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"
}
}
}
}
Sur certains clusters Kubernetes gérés, vous devez également vous authentifier auprès de la plateforme elle-même car l'authentification Kubernetes lui est déléguée.