
Termina periódicamente pods aleatorios de Kubernetes para probar cómo se comportan los sistemas ante fallos arbitrarios de pods, con soporte de filtros por namespace, etiquetas, anotaciones y programación para experimentos de caos controlados.
chaoskube mata periódicamente pods aleatorios en tu clúster de Kubernetes.

Prueba cómo se comporta tu sistema ante fallos arbitrarios de pods.
Al ejecutarlo, matará un pod en cualquier namespace cada 10 minutos por defecto.
$ chaoskube
INFO[0000] starting up dryRun=true interval=10m0s version=v0.21.0
INFO[0000] connecting to cluster master="https://kube.you.me" serverVersion=v1.10.5+coreos.0
INFO[0000] setting pod filter annotations= labels= minimumAge=0s namespaces=
INFO[0000] setting quiet times daysOfYear="[]" timesOfDay="[]" weekdays="[]"
INFO[0000] setting timezone location=UTC name=UTC offset=0
INFO[0001] terminating pod name=kube-dns-v20-6ikos namespace=kube-system
INFO[0601] terminating pod name=nginx-701339712-u4fr3 namespace=chaoskube
INFO[1201] terminating pod name=kube-proxy-gke-earthcoin-pool-3-5ee87f80-n72s namespace=kube-system
INFO[1802] terminating pod name=nginx-701339712-bfh2y namespace=chaoskube
INFO[2402] terminating pod name=heapster-v1.2.0-1107848163-bhtcw namespace=kube-system
INFO[3003] terminating pod name=l7-default-backend-v1.0-o2hc9 namespace=kube-system
INFO[3603] terminating pod name=heapster-v1.2.0-1107848163-jlfcd namespace=kube-system
INFO[4203] terminating pod name=nginx-701339712-bfh2y namespace=chaoskube
INFO[4804] terminating pod name=nginx-701339712-51nt8 namespace=chaoskube
...
chaoskube permite filtrar los pods objetivo por namespaces, labels, annotations y edad, así como excluir ciertos días de la semana, horas del día y días del año del caos.
Puedes instalar chaoskube con Helm. Sigue la Guía de inicio rápido de Helm y luego instala el chart de chaoskube.
$ helm repo add chaoskube https://linki.github.io/chaoskube/
$ helm install chaoskube chaoskube/chaoskube --atomic --namespace=chaoskube --create-namespace
Consulta chaoskube en kubeapps.com para aprender cómo configurarlo y encontrar otros charts de Helm útiles.
Consulta el manifest de ejemplo. Asegúrate de otorgar a chaoskube los permisos apropiados utilizando el ClusterRole proporcionado.
Por defecto, chaoskube será amigable y no matará nada. Cuando hayas validado tu clúster objetivo, puedes desactivar el modo dry-run pasando la flag --no-dry-run. También puedes especificar un intervalo más agresivo y otras flags soportadas para tu despliegue.
Si te estás ejecutando en un clúster de Kubernetes y quieres apuntar al mismo clúster, esto es todo lo que necesitas hacer.
Si quieres apuntar a un clúster diferente o ejecutarlo localmente, especifica tu clúster mediante la flag --master o proporciona un kubeconfig válido mediante la flag --kubeconfig. Por defecto, usa la ruta estándar de tu kubeconfig en tu directorio personal. Eso significa que se apuntará al contexto que esté actualmente activo allí.
Si quieres aumentar o disminuir la cantidad de caos, cambia el intervalo entre muertes con la flag --interval. Alternativamente, puedes aumentar el número de réplicas de tu despliegue de chaoskube.
Recuerda que chaoskube por defecto mata cualquier pod en todos tus namespaces, incluidos los pods del sistema y él mismo.
chaoskube proporciona un endpoint HTTP simple que se puede usar para comprobar que está ejecutándose. Esto se puede utilizar para sondas de liveness y readiness de Kubernetes. Por defecto, escucha en el puerto 8080. Para deshabilitarlo, pasa --metrics-address="" a chaoskube.
Sin embargo, puedes limitar el espacio de búsqueda de chaoskube proporcionando selectores de labels, annotations y namespaces, patrones de inclusión/exclusión de nombres de pods, así como una configuración de edad mínima.
$ chaoskube --labels 'app=mate,chaos,stage!=production'
...
INFO[0000] setting pod filter labels="app=mate,chaos,stage!=production"
Esto selecciona todos los pods que tengan la label app establecida a mate, la label chaos establecida a cualquier valor y la label stage no establecida a production o no establecida.
También puedes filtrar los pods objetivo mediante un selector de namespaces.
$ chaoskube --namespaces 'default,testing,staging'
...
INFO[0000] setting pod filter namespaces="default,staging,testing"
Esto filtrará los pods en los tres namespaces default, staging y testing.
Los namespaces también se pueden filtrar mediante un selector de labels de namespace.
$ chaoskube --namespace-labels='!integration'
...
INFO[0000] setting pod filter namespaceLabels="!integration"
Esto excluirá todos los pods de namespaces con la label integration.
Puedes filtrar los pods objetivo mediante un selector de tipo de OwnerReference.
$ chaoskube --kinds '!DaemonSet,!StatefulSet'
...
INFO[0000] setting pod filter kinds="!DaemonSet,!StatefulSet"
Esto excluirá cualquier pod de DaemonSet y StatefulSet.
$ chaoskube --kinds 'DaemonSet'
...
INFO[0000] setting pod filter kinds="DaemonSet"
Esto solo incluirá cualquier pod de DaemonSet.
Ten en cuenta: cualquier filtro de include excluirá automáticamente todos los pods sin OwnerReference definida.
Puedes filtrar los pods por nombre:
$ chaoskube --included-pod-names 'foo|bar' --excluded-pod-names 'prod'
...
INFO[0000] setting pod filter excludedPodNames=prod includedPodNames="foo|bar"
Esto hará que solo se ataquen los pods cuyo nombre contenga 'foo' o 'bar' y no contenga 'prod'.
También puedes excluir namespaces y combinarlos con los selectores de labels y annotations.
$ chaoskube \
--labels 'app=mate,chaos,stage!=production' \
--annotations '!scheduler.alpha.kubernetes.io/critical-pod' \
--namespaces '!kube-system,!production'
...
INFO[0000] setting pod filter annotations="!scheduler.alpha.kubernetes.io/critical-pod" labels="app=mate,chaos,stage!=production" namespaces="!kube-system,!production"
Esto limita aún más el espacio de búsqueda del selector de labels anterior, excluyendo también cualquier pod en los namespaces kube-system y production, además de ignorar todos los pods marcados como críticos.
El selector de annotations también se puede utilizar para ejecutar chaoskube como un addon del clúster y permitir que los pods opten por ser terminados como mejor te parezca. Por ejemplo, podrías ejecutar chaoskube así:
$ chaoskube --annotations 'chaos.alpha.kubernetes.io/enabled=true' --debug
...
INFO[0000] setting pod filter annotations="chaos.alpha.kubernetes.io/enabled=true"
DEBU[0000] found candidates count=0
DEBU[0000] no victim found