
Extensión de controlador de Kubernetes para la API de sondas y acciones de Chaos Toolkit
Este proyecto contiene actividades, como sondas y acciones, que puedes invocar desde tu experimento a través de Chaos Toolkit para llevar a cabo Chaos Engineering contra la API de Kubernetes: matar un pod, eliminar un statefulset o un nodo...
Para usarlo desde tu experimento, este paquete debe instalarse en el entorno de Python donde ya vive chaostoolkit.
$ pip install chaostoolkit-kubernetes
Para usar las sondas y acciones de este paquete, añade lo siguiente a tu archivo de experimento:
{
"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
}
}
]
}
¡Eso es todo! Observa cómo la acción te ofrece la forma de matar un pod al azar.
Explora la documentación para ver las sondas y acciones existentes.
Ten en cuenta que, para los factores de estrés de red, CPU y memoria, nos apoyamos en el fantástico proyecto Chaos Mesh, que proporciona una excelente interfaz para inyectar estos fallos.
Necesitarás instalar Chaos Mesh primero en tu clúster para poder usarlos.
Si tienes una entrada válida en tu archivo ~/.kube/config para el clúster al
que quieres apuntar, no hay nada que hacer.
Puedes especificar KUBECONFIG para indicar una ubicación diferente.
$ export KUBECONFIG=/tmp/my-config
Muy a menudo, tu configuración de Kubernetes contiene varias entradas y necesitas definir la que se usará como contexto predeterminado cuando no se proporcione explícitamente.
Por supuesto, puedes cambiar tu valor predeterminado usando
kubectl config use-context KUBERNETES_CONTEXT, pero también puedes ser explícito
en tu experimento de la siguiente manera:
{
"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
}
}
]
}
Debes especificar la clave secreta KUBERNETES_CONTEXT con el nombre del contexto
que quieres que use el experimento. Asegúrate también de informar a las acciones y
sondas sobre las entradas secretas que deben recibir: "secrets": ["k8s"].
Cuando se ejecuta desde un pod (no desde tu máquina local ni desde un CI, por
ejemplo), el archivo ./.kube/config no existe. En su lugar, las credenciales se
pueden encontrar en /var/run/secrets/kubernetes.io/serviceaccount/token.
Para que la extensión lo sepa, simplemente establece CHAOSTOOLKIT_IN_POD mediante
la variable de entorno de la especificación del pod:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
Cuando se usa esta variable de entorno, se asume que el experimento apunta al mismo
clúster desde el que se ejecuta. Si tu experimento apunta a un clúster diferente, no
debes establecer esta variable. En su lugar, puedes montar un volumen con una
configuración de Kubernetes para el clúster de destino y establecer KUBECONFIG
para que apunte a él.
Finalmente, puedes pasar explícitamente toda la información de credenciales requerida al experimento de la siguiente manera:
{
"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"
}
}
}
}
En algunos clústeres de Kubernetes gestionados, también necesitas autenticarte contra la propia plataforma porque la autenticación de Kubernetes está delegada en ella.