kube-monkey es una implementación de Chaos Monkey de Netflix para clústeres de Kubernetes. Elimina aleatoriamente pods de Kubernetes (k8s) en el clúster, fomentando y validando el desarrollo de servicios resilientes a fallos.

Únete a nosotros en #kube-monkey en Kubernetes Slack.

kube-monkey se ejecuta a una hora preconfigurada (run_hour, por defecto a las 8 am) entre semana, y genera un cronograma de deployments que enfrentarán una muerte aleatoria de Pods en algún momento del mismo día. El intervalo de tiempo durante el día en el que puede ocurrir la muerte aleatoria de Pods es configurable y por defecto es de 10 am a 4 pm.

kube-monkey se puede configurar con una lista de namespaces

para incluir en la lista negra (cualquier deployment dentro de un namespace en la lista negra no se tocará)

Para deshabilitar la lista negra, proporciona [""] en el config.param de blacklisted_namespaces.

Optar por el caos

kube-monkey funciona con un modelo de adhesión voluntaria y solo programará terminaciones para aplicaciones de Kubernetes (k8s) que hayan aceptado explícitamente que kube-monkey termine sus pods.

La adhesión se realiza estableciendo las siguientes etiquetas en una aplicación k8s:

kube-monkey/enabled: Establécelo en "enabled" para aceptar participar en kube-monkey
kube-monkey/mtbf: Tiempo medio entre fallos, como un número entero y una unidad: d para días, h para horas o m para minutos. Por ejemplo, si se establece en "3d", la aplicación k8s puede esperar que se elimine un Pod aproximadamente cada tercer día laborable, y si se establece en "2h", puede esperar perder un Pod cada dos horas. Un valor sin unidad se interpreta como días, por lo que "3" y "3d" significan lo mismo. El tiempo medio entre fallos más corto es de un minuto. Ten en cuenta que todas las terminaciones ocurren dentro de la ventana de ejecución diaria (consulta start_hour y end_hour), por lo que un mtbf más corto que un día concentra las terminaciones de ese día en dicha ventana. : Un identificador único para las aplicaciones k8s. Se utiliza para identificar los pods que pertenecen a una aplicación k8s, ya que los Pods heredan las etiquetas de su aplicación k8s. Entonces, si kube-monkey detecta que la aplicación se ha inscrito para ser víctima, kube-monkey buscará todos los pods que tengan la etiqueta para determinar qué pods son candidatos a ser eliminados. La recomendación es establecer este valor igual al nombre de la aplicación. : El comportamiento predeterminado es que kube-monkey elimine solo UN pod de tu aplicación. Puedes anular este comportamiento estableciendo el valor en:

kill-all si quieres que kube-monkey elimine TODOS tus pods independientemente de su estado (incluidos los pods no listos y no en ejecución). No requiere kill-value. Usa esta etiqueta con cuidado.
fixed si quieres eliminar un número específico de pods en ejecución con kill-value. Si especificas un número mayor, eliminará todos los pods en ejecución y emitirá una advertencia.
random-max-percent para especificar un % máximo con kill-value que puede ser eliminado. En el momento programado, se terminará un % aleatorio uniforme especificado de los pods en ejecución.
fixed-percent para especificar un % fijo con kill-value que puede ser eliminado. En el momento programado, se terminará un % especificado de los pods en ejecución.

kube-monkey/kill-value: Especifica el valor para kill-mode

si fixed, proporciona un número entero de pods a eliminar
si random-max-percent, proporciona un número del 0-100 para especificar el % máximo de pods que kube-monkey puede eliminar
si fixed-percent, proporciona un número del 0-100 para especificar el % de pods a eliminar

Ejemplo de un Deployment inscrito que elimina un pod por purga

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
        kube-monkey/mtbf: '2'
        kube-monkey/kill-mode: "fixed"
        kube-monkey/kill-value: '1'
[... omitted ...]

Para versiones más recientes de Kubernetes, es posible que también necesites agregar las etiquetas a los metadatos de la aplicación k8s.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
  labels:
    kube-monkey/enabled: enabled
    kube-monkey/identifier: monkey-victim
    kube-monkey/mtbf: '2'
    kube-monkey/kill-mode: "fixed"
    kube-monkey/kill-value: '1'
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
[... omitted ...]

Anular el apiserver

Casos de uso:

Dado que client-go no admite cluster dns explícitamente, con una nota // TODO: switch to using cluster DNS. en el código, es posible que necesites anular el apiserver.
Si estás ejecutando un sistema no autenticado, es posible que necesites forzar el endpoint http del apiserver.

Para anular el apiserver, especifícalo en el archivo config.toml

[kubernetes]
host="https://your-apiserver-url.com:apiport"

Cómo funciona kube-monkey

Hora de programación

La programación ocurre una vez al día, de lunes a viernes; este es el momento en que se genera un cronograma de terminaciones para el día actual. Durante la programación, kube-monkey:

Genera una lista de aplicaciones k8s elegibles (aplicaciones k8s que se han inscrito y no están en la lista negra, si se especificó, y están en la lista blanca, si se especificó)
Para cada aplicación k8s elegible, calcula cuántos pods eliminar hoy según kube-monkey/mtbf. Una aplicación tiene un Pod eliminado 24h/mtbf veces al día, por lo que un mtbf de un día o más da como máximo una terminación, y uno más corto da varias
Para cada terminación, calcula una hora aleatoria en la que se eliminará un pod

Hora de terminación

Es la hora generada aleatoriamente durante el día en que a una aplicación k8s víctima se le eliminará un pod. En el momento de la terminación, kube-monkey:

Comprueba si la aplicación k8s sigue siendo elegible (no se ha dado de baja, no ha sido incluida en la lista negra ni eliminada de la lista blanca desde la programación)
Comprueba si la aplicación k8s ha actualizado kill-mode y kill-value
Según kill-mode y kill-value, ejecuta las eliminaciones de pods

Imágenes de Docker

Las imágenes de Docker para kube-monkey se pueden encontrar en DockerHub

Compilación

Clona el repositorio y compila el contenedor.

go get github.com/asobti/kube-monkey
cd $GOPATH/src/github.com/asobti/kube-monkey
make build
make container

Configuración

kube-monkey se configura mediante variables de entorno o un archivo toml ubicado en /etc/kube-monkey/config.toml, y espera que el configmap exista antes del despliegue de kube-monkey.

Las claves de configuración y sus descripciones se pueden encontrar en config/param/param.go

Ejemplo de archivo config.toml

[kubemonkey]
dry_run = true                           # Terminations are only logged
run_hour = 8                             # Run scheduling at 8am on weekdays
start_hour = 10                          # Don't schedule any pod deaths before 10am
end_hour = 16                            # Don't schedule any pod deaths after 4pm
blacklisted_namespaces = ["kube-system"] # Critical apps live here
time_zone = "America/New_York"           # Set tzdata timezone example. Note the field is time_zone not timezone

Ejemplo de variables de entorno

KUBEMONKEY_DRY_RUN=true
KUBEMONKEY_RUN_HOUR=8
KUBEMONKEY_START_HOUR=10
KUBEMONKEY_END_HOUR=16
KUBEMONKEY_BLACKLISTED_NAMESPACES=kube-system
KUBEMONKEY_TIME_ZONE=America/New_York

Configuración de ejemplo para probar que kube-monkey funciona habilitando el modo de depuración

Nota: esto seguirá atacando pods cada 60s, independientemente de lo que hayas configurado para startHour y endHour.

[debug]
enabled= true
schedule_immediate_kill= true

Notificaciones

Kube-monkey admite notificaciones y puede notificar a un endpoint de tu elección después de un ataque. Puede ser un webhook de Slack o una API personalizada.

Configuración de ejemplo para enviar notificaciones de ataque a un endpoint HTTP

[notifications]
  enabled = true
  reportSchedule = true
  [notifications.attacks]
    endpoint = "http://url1"
    message = "message1"
    headers = ["header1Key:header1Value","header2Key:header2/Value"]

Marcadores de posición

El mensaje admite los siguientes marcadores de posición:

{$name}: nombre de la víctima
{$kind}: tipo de la víctima
{$namespace}: namespace de la víctima
{$timestamp}: hora del ataque desde la época Unix en milisegundos
{$time}: hora del ataque
{$date}: fecha del ataque
{$error}: error del resultado, si lo hay
{$kubemonkeyid}: id de kube-monkey (se establece mediante la variable de entorno KUBE_MONKEY_ID; de lo contrario, vacío)

  message: '{
            "what": "Kube-monkey(${kubemonkeyid}) attack of {$name} in {$namespace}",
            "who": "{$name}",
            "when": {$timestamp}
           }'

El encabezado admite un marcador de posición especial para recuperar el valor de una variable de entorno. Esto es útil cuando se llama a una API que tiene un endpoint protegido. Un escenario típico es pasar un token de API al contenedor de Kube-monkey; ese token se almacena en un Secret de Kubernetes y quieres pasarlo mediante una variable de entorno.

headers = ["api-key:{$env:API_TOKEN}", "Content-Type:application/json"]

{$env:API_TOKEN} será reemplazado por el valor de la variable de entorno API_TOKEN.

Nota: si la variable de entorno no existe, la llamada de notificación NO se cancelará. El valor se resolverá como una cadena vacía y aparecerá una advertencia en los registros.

Despliegue

Manualmente

Primero, despliega el configmap esperado kube-monkey-config-map en el namespace donde pretendes ejecutar kube-monkey (por ejemplo, el namespace kube-system). Asegúrate de definir el nombre de la clave como config.toml

Por ejemplo, kubectl create configmap km-config --from-file=config.toml=km-config.toml o kubectl apply -f km-config.yaml

Ejecuta kube-monkey como una aplicación k8s dentro del clúster de Kubernetes, en un namespace que tenga permisos para eliminar Pods en otros namespaces (p. ej., kube-system).

Consulta el directorio examples/ para ver archivos yaml de Kubernetes de ejemplo.

Deberías poder ver los registros de depuración con kubectl logs -f deployment.apps/kube-monkey --namespace=kube-system; aquí, deployment.apps/kube-monkey es el despliegue k8s de kube-monkey.

Helm Chart

Consulta Cómo instalar kube-monkey con Helm.

Registro

kube-monkey usa glog y admite todas las funciones de línea de comandos de glog. Para especificar un nivel v personalizado o un directorio de registros personalizado en el pod, consulta args: ["-v=5", "-log_dir=/path/to/custom/log"] en el archivo de despliegue de ejemplo

Niveles estandarizados de glog grep -r V$[0-9]$ *

L0: Ninguno

L1: Información de estado actual de nivel más alto y errores con terminaciones

L2: Terminaciones exitosas

L3: Información de estado de programación más detallada

L4: Información detallada de depuración de programación y configuración

L5: Problemas intrascendentes resueltos automáticamente

Más recursos: Consulta la página de registro de k8s que sugiere convenciones de la comunidad para la severidad de los registros

Instrucciones para hacer que esto funcione en OpenShift 3.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-role-to-user -z deployer system:deployer
oc -n kube-system adm policy add-role-to-user -z builder system:image-builder
oc -n kube-system adm policy add-role-to-group system:image-puller system:serviceaccounts:kube-system
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.4.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

OpenShift 4.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-cluster-role-to-user edit -z default --rolebinding-name kube-monkey-edit
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.3.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc set volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

Formas de contribuir

Consulta Cómo contribuir

Licencia

Este proyecto está licenciado bajo la Licencia Apache v2.0; consulta el archivo LICENSE para obtener más detalles.

kube-monkey

Más Populares