chaostoolkit/chaostoolkit-kubernetesExtensió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.
Además de tus credenciales de Kubernetes (a través del archivo ~/.kube/config),
necesitas autenticarte contra la propia Google Cloud Platform. Normalmente esto se
hace mediante:
$ gcloud auth login
Pero también se puede lograr definiendo la variable de entorno
GOOGLE_APPLICATION_CREDENTIALS.
Si deseas contribuir con más funciones a este paquete, eres más que bienvenido a hacerlo. Por favor, haz un fork de este proyecto, escribe pruebas unitarias que cubran los cambios propuestos, implementa los cambios, asegúrate de que cumplan con los estándares de formato y luego abre un PR al repositorio para su revisión.
Consulta la sección formato para obtener más información sobre los estándares de formato.
Los proyectos de Chaos Toolkit requieren que todos los contribuyentes firmen un Developer Certificate of Origin en cada commit que quieran fusionar en la rama master del repositorio. Asegúrate de poder cumplir con las reglas del DCO antes de enviar un PR.
Si deseas desarrollar en este proyecto, asegúrate de instalar las dependencias de desarrollo. Pero primero, instala PDM y luego instala las dependencias.
$ pdm install
Ahora puedes editar los archivos y tu entorno los verá automáticamente, incluso
cuando ejecutes el comando chaos localmente.
Para ejecutar las pruebas del proyecto, ejecuta lo siguiente:
$ pdm run tests
Usamos ruff para aplicar lint y formato al código de este repositorio.
Antes de abrir un Pull Request, te recomendamos ejecutar el formato sobre tu código con:
$ pdm run format
Esto formateará automáticamente cualquier código que no se adhiera a los estándares de formato.
Como algunas cosas no se corrigen con el formato, también te recomendamos ejecutar:
$ pdm run lint
Para asegurarte de que también se detecten importaciones sin usar, cadenas demasiado largas, etc.