Pruebe errores de pod arbitrarios en Kubernetes con kube-monkey

He cubierto más herramientas de ingeniería del caos en esta serie. El primer artículo de esta serie explicaba qué es la ingeniería del caos; el segundo demostró cómo obtener el estado estacionario del sistema para poder compararlo con un estado de caos; el tercero mostró cómo usar Litmus para probar fallas y experimentos arbitrarios en su clúster de Kubernetes; y el cuarto artículo entró en Chaos Mesh, un orquestador de caos de código abierto con una interfaz de usuario web.

En este quinto artículo, quiero hablar sobre la falla arbitraria del pod. Kube-mono ofrece una manera fácil de estresar sus sistemas mediante la programación de módulos de terminación aleatorios en su clúster. El objetivo es fomentar y validar el desarrollo de servicios resistentes a fallas. Como en los procedimientos anteriores, usaré Pop!_OS 20.04, Helm 3, Minikube 1.14.2 y Kubernetes 1.19.

Índice

    Configurar Minikube

    Si aún no lo has hecho, instalar Minikube de cualquier manera que tenga sentido para su entorno. Si tiene suficientes recursos, le recomiendo darle a su máquina virtual un poco más que la memoria y la potencia de la CPU predeterminadas:

    $ minikube config set memory 8192
    ❗  These changes will take effect upon a minikube delete and then a minikube start
    $ minikube config set cpus 6
    ❗  These changes will take effect upon a minikube delete and then a minikube start

    Luego inicie y verifique el estado de su sistema:

    $ minikube start
    ?  minikube v1.14.2 on Debian bullseye/sid
    ?  minikube 1.19.0 is available! Download it: https://github.com/kubernetes/minikube/releases/tag/v1.19.0
    ?  To disable this notice, run: 'minikube config set WantUpdateNotification false'

    ✨  Using the docker driver based on user configuration
    ?  Starting control plane node minikube in cluster minikube
    ?  Creating docker container (CPUs=6, Memory=8192MB) ...
    ?  Preparing Kubernetes v1.19.0 on Docker 19.03.8 ...
    ?  Verifying Kubernetes components...
    ?  Enabled addons: Almacenamiento-provisioner, default-storageclass
    ?  Done! kubectl is now configured to use "minikube" by default
    $ minikube status
    minikube
    type: Control Plane
    host: Running
    kubelet: Running
    apiserver: Running
    kubeconfig: Configured

    Preconfiguración con distribuciones

    Comience agregando algunas distribuciones pequeñas para causar estragos. Estas distribuciones necesitarán algunas etiquetas especiales, por lo que debe crear un nuevo gráfico de Helm. Las siguientes etiquetas ayudarán a kube-monkey a determinar qué matar si la aplicación decide causar estragos y comprender qué detalles hay detrás del caos:

    • kube-monkey / habilitado: Esta configuración te permite iniciar el caos.
    • kube-monkey / mtbf: indica el tiempo promedio entre fallas (en días). Por ejemplo, si se establece en 3, la aplicación Kubernetes (K8s) espera que se elimine un pod aproximadamente cada tercer día de la semana.
    • kube-monkey / identificador: este es un identificador único para las aplicaciones K8s; en este ejemplo, será "nginx".
    • mono kube / modo matar: El comportamiento predeterminado de kube-monkey es matar solo un pod en el clúster, pero puede cambiarlo para agregar más:
      • matar a todos: Mata a cada pod, sin importar lo que esté pasando con un pod.
      • reparado: Elige el número de cápsulas que quieres matar
      • porcentaje fijo: Mata un porcentaje fijo de pods (por ejemplo, 50%)
    • mono kube / valor de muerte: aquí es donde puede especificar un valor para el modo de muerte
      • reparado: El número de cápsulas para matar.
      • porcentaje aleatorio máximo: El número máximo entre 0 y 100 que kube-monkey puede matar
      • porcentaje fijo: El porcentaje, de 0 a 100 por ciento, de vainas para matar

    Ahora que tiene esta información básica, puede comenzar a crear un gráfico de Helm básico.

    Llamé a este gráfico de Helm nginx. Solo mostraré los cambios en las etiquetas de distribución del gráfico de Helm a continuación. Necesita editar el archivo YAML de distribución, es decir nginx/templates en este ejemplo:

    $ /chaos/kube-monkey/helm/nginx/templates$ ls -la
    total 40
    drwxr-xr-x 3 jess jess 4096 May 15 14:46 .
    drwxr-xr-x 4 jess jess 4096 May 15 14:46 ..
    -rw-r--r-- 1 jess jess 1826 May 15 14:46 deployment.yaml
    -rw-r--r-- 1 jess jess 1762 May 15 14:46 _helpers.tpl
    -rw-r--r-- 1 jess jess  910 May 15 14:46 hpa.yaml
    -rw-r--r-- 1 jess jess 1048 May 15 14:46 ingress.yaml
    -rw-r--r-- 1 jess jess 1735 May 15 14:46 NOTES.txt
    -rw-r--r-- 1 jess jess  316 May 15 14:46 serviceaccount.yaml
    -rw-r--r-- 1 jess jess  355 May 15 14:46 service.yaml
    drwxr-xr-x 2 jess jess 4096 May 15 14:46 tests

    En tus deployment.yaml archivo, busque esta sección:

     template:
        metadata
    :
         {{- with .Values.podAnnotations }}
          annotations
    :
           {{- toYaml . | nindent 8 }}
          {{- end }}
          labels
    :
           {{- include "nginx.selectorLabels" . | nindent 8 }}

    Y haz estos cambios:

     template:
        metadata
    :
         {{- with .Values.podAnnotations }}
          annotations
    :
           {{- toYaml . | nindent 8 }}
          {{- end }}
          labels
    :
           {{- include "nginx.selectorLabels" . | nindent 8 }}
            kube-monkey/enabled
    : enabled
            kube-monkey/identifier
    : monkey-victim
            kube-monkey/mtbf
    : '2'
            kube-monkey/kill-mode
    : "fixed"
            kube-monkey/kill-value
    : '1'

    Retrocede un directorio y encuentra el archivo. values Archivo:

    $ /chaos/kube-monkey/helm/nginx/templates$ cd ../
    $ /chaos/kube-monkey/helm/nginx$ ls
    charts  Chart.yaml  templates  values.yaml

    Necesita cambiar una línea en el archivo de valores, desde:

    replicaCount: 1

    a:

    replicaCount: 8

    Esto te dará ocho pods diferentes para probar el caos.

    Regrese a otro directorio e instale el nuevo gráfico de Helm:

    $ /chaos/kube-monkey/helm/nginx$ cd ../
    $ /chaos/kube-monkey/helm$ helm install nginxtest nginx
    NAME: nginxtest
    LAST DEPLOYED: Sat May 15 14:53:47 2021
    NAMESPACE: default
    STATUS: deployed
    REVISION: 1
    NOTES:
    1. Get the application URL by running these commands:
      export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginxtest" -o jsonpath="{.items[0].metadata.name}")
      export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.Contenedores[0].ports[0].containerPort}")
      echo "Visit http://127.0.0.1:8080 to use your application"
      kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

    Luego revise las etiquetas en sus pods de Nginx:

    $ /chaos/kube-monkey/helm$ kubectl get pods -n default
    NAME                                 READY   STATUS    RESTARTS   AGE
    nginxtest-8f967857-88zv7             1/1     Running   0          80s
    nginxtest-8f967857-8qb95             1/1     Running   0          80s
    nginxtest-8f967857-dlng7             1/1     Running   0          80s
    nginxtest-8f967857-h7mmc             1/1     Running   0          80s
    nginxtest-8f967857-pdzpq             1/1     Running   0          80s
    nginxtest-8f967857-rdpnb             1/1     Running   0          80s
    nginxtest-8f967857-rqv2w             1/1     Running   0          80s
    nginxtest-8f967857-tr2cn             1/1     Running   0          80s

    Elija el primer pod para describir y confirme que las etiquetas están en su lugar:

    $ /chaos/kube-monkey/helm$ kubectl describe pod nginxtest-8f967857-88zv7 -n default
    Name:         nginxtest-8f967857-88zv7
    Namespace:    default
    Priority:     0
    Node:         minikube/192.168.49.2
    Start Time:   Sat, 15 May 2021 15:11:37 -0400
    Labels:       app.kubernetes.io/instance=nginxtest
                  app.kubernetes.io/name=nginx
                  kube-monkey/enabled=enabled
                  kube-monkey/identifier=monkey-victim
                  kube-monkey/kill-mode=fixed
                  kube-monkey/kill-value=1
                  kube-monkey/mtbf=2
                  pod-template-hash=8f967857

    Configurar e instalar kube-monkey

    Para instalar kube-monkey usando Helm, primero debe ejecutar git clone on el repositorio kube-monkey:

    $ /chaos$ git clone https://github.com/asobti/kube-monkey
    Cloning into 'kube-monkey'...
    remote: Enumerating objects: 14641, done.
    remote: Counting objects: 100% (47/47), done.
    remote: Compressing objects: 100% (36/36), done.
    remote: Total 14641 (delta 18), reused 22 (delta 8), pack-reused 14594
    Receiving objects: 100% (14641/14641), 30.56 MiB | 39.31 MiB/s, done.
    Resolving deltas: 100% (6502/6502), done.

    Cambiar a kube-monkey/helm directorio:

    $ /chaos$ cd kube-monkey/helm/
    $ /chaos/kube-monkey/helm$

    Luego vaya a la carta de Helm y encuentre el values.yaml Archivo:

    $ /chaos/kube-monkey/helm$ cd kubemonkey/
    $ /chaos/kube-monkey/helm/kubemonkey$ ls
    Chart.yaml  README.md  templates  values.yaml

    A continuación, solo mostraré secciones del values.yaml archivo que necesita editar. Deshabilitan el modo de funcionamiento en seco cambiándolo en la sección de configuración en false, luego agregue el espacio de nombres predeterminado a la lista blanca para que pueda terminar los pods que ha implementado. Tienes que mantener el blacklistedNamespaces valor o causará daños severos a su sistema.

    Cambia esto:

    config:
      dryRun
    : true  
      runHour
    : 8
      startHour
    : 10
      endHour
    : 16
      blacklistedNamespaces
    :
       - kube-system
      whitelistedNamespaces
    : []

    A esto:

    config:
      dryRun: false  
      runHour: 8
      startHour: 10
      endHour: 16
      blacklistedNamespaces:
        - kube-system
      whitelistedNamespaces:  ["default"]

    En la sección de depuración, establezca enabled Y schedule_immediate_kill a true. Esto mostrará las vainas muertas.

    Cambia esto:

     debug:
       enabled
    : false
       schedule_immediate_kill
    : false

    A esto:

     debug:
       enabled
    : true
       schedule_immediate_kill
    : true

    hacer un helm install:

    $ /chaos/kube-monkey/helm$ helm install chaos kubemonkey
    NAME: chaos
    LAST DEPLOYED: Sat May 15 13:51:59 2021
    NAMESPACE: default
    STATUS: deployed
    REVISION: 1
    TEST SUITE: None
    NOTES:
    1. Wait until the application is rolled out:
      kubectl -n default rollout status deployment chaos-kube-monkey
    2. Check the logs:
      kubectl logs -f deployment.apps/chaos-kube-monkey -n default

    Verifique los registros de kube-monkey y verifique que los pods se hayan cerrado:

     $ /chaos/kube-monkey/helm$ kubectl logs -f deployment.apps/chaos-kube-monkey -n default

            ********** Today's schedule **********
            k8 Api Kind     Kind Name               Termination Time
            -----------     ---------               ----------------
            v1.Deployment   nginxtest               05/15/2021 15:15:22 -0400 EDT
            ********** End of schedule **********
    I0515 19:15:22.343202       1 kubemonkey.go:70] Termination successfully executed for v1.Deployment nginxtest
    I0515 19:15:22.343216       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.
    I0515 19:15:22.343220       1 kubemonkey.go:76] Status Update: All terminations done.
    I0515 19:15:22.343278       1 kubemonkey.go:19] Debug mode detected!
    I0515 19:15:22.343283       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 sec

    También puedes usar K9 y ver morir las vainas.

    ¡Felicidades! Ahora tiene una prueba de caos ejecutándose con fallas arbitrarias. Siempre que quieras, puedes modificar tus aplicaciones para probarlas un determinado día de la semana ya una hora del día.

    Pensamientos finales

    Si bien kube-monkey es una gran herramienta de ingeniería del caos, requiere configuraciones pesadas. Por lo tanto, no es la mejor herramienta inicial de ingeniería del caos para alguien nuevo en Kubernetes. Otro inconveniente es que debe modificar el gráfico Helm de su aplicación para realizar la prueba de caos.

    Esta herramienta estaría mejor ubicada en un entorno de prueba para observar cómo las aplicaciones responden regularmente a errores arbitrarios. Esto le brinda una forma a largo plazo de rastrear estados inestables utilizando herramientas de monitoreo de clústeres. También señala que puede utilizar para restaurar sus aplicaciones internas en producción.

    Artículos de interés

    Subir