chaostoolkit/chaostoolkit-kubernetesExtension 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.
En plus de vos informations d'identification Kubernetes (via le fichier ~/.kube/config), vous devez vous authentifier auprès de la plateforme Google Cloud elle-même. Cela se fait généralement via :
$ gcloud auth login
Mais cela peut aussi être réalisé en définissant la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.
Si vous souhaitez contribuer avec d'autres fonctions à ce paquet, vous êtes plus que bienvenu. Veuillez forker ce projet, écrire des tests unitaires pour couvrir les changements proposés, implémenter les changements, vous assurer qu'ils respectent les normes de formatage, puis soumettre une PR au dépôt pour examen.
Veuillez vous référer à la section formatage pour plus d'informations sur les normes de formatage.
Les projets Chaos Toolkit exigent que tous les contributeurs signent un Developer Certificate of Origin sur chaque commit qu'ils souhaitent fusionner dans la branche master du dépôt. Assurez-vous de pouvoir respecter les règles du DCO avant de soumettre une PR.
Si vous souhaitez développer sur ce projet, assurez-vous d'installer les dépendances de développement. Mais d'abord, installez PDM puis installez les dépendances.
$ pdm install
Vous pouvez maintenant modifier les fichiers, et ils seront automatiquement détectés par votre environnement, même lors de l'exécution de la commande chaos en local.
Pour exécuter les tests du projet, lancez la commande suivante :
$ pdm run tests
Nous utilisons ruff pour lint et formater le code de ce dépôt.
Avant de soumettre une Pull Request, nous vous recommandons d'exécuter le formatage sur votre code avec :
$ pdm run format
Cela formatera automatiquement tout code qui ne respecte pas les normes de formatage.
Comme certaines choses ne sont pas détectées par le formatage, nous vous recommandons également d'exécuter :
$ pdm run lint
Afin de garantir que les instructions d'import inutilisées, les chaînes trop longues, etc. soient également détectées.