Ingeniería del Caos Con Litmus: Un Proyecto Incubado por CNCF

Declaración del problema: Asegurar la resiliencia de una plataforma de comercio electrónico basada en microservicios.

La resiliencia del sistema se presenta como el requisito clave para las plataformas de comercio electrónico durante las operaciones de escalado para mantener los servicios operativos y ofrecer excelencia de rendimiento a los usuarios. Hemos desarrollado una plataforma de arquitectura de microservicios que experimenta fallas esporádicas del sistema cuando se enfrenta a eventos de tráfico intenso. Los problemas con la disponibilidad de servicios degradada junto con el impacto en los ingresos ocurren principalmente debido a los fallos de los pods de Kubernetes junto con la agotamiento de recursos y las interrupciones de red que ocurren durante las temporadas de compras pico.

La organización planea utilizar el proyecto incubado por CNCF, Litmus, para llevar a cabo evaluaciones y mejoras de resiliencia de la plataforma. Nuestros puntos débiles del sistema se hacen más claros cuando realizamos pruebas de fallas simuladas usando Litmus, lo que nos permite desencadenar situaciones de falla del mundo real como eventos de terminación de pods y retrasos de red, y límites de uso de recursos. Los experimentos nos permiten validar los sistemas de automatización de escalabilidad mientras probamos procedimientos de recuperación de desastres y maximizamos la configuración de Kubernetes hacia la confiabilidad total del sistema.

El sistema crea una base sólida para resistir situaciones de falla y distribuir períodos de tráfico ocupados de manera segura sin deteriorar la calidad de la experiencia del usuario. La ingeniería del caos aplicada de manera proactiva a nuestra infraestructura permite una mejor reducción de riesgos y una mayor observabilidad, lo que nos permite desarrollar métodos de recuperación automatizados que mejoran la resiliencia del comercio electrónico de nuestra plataforma ante cualquier condición operativa.

Configurar el Entorno del Experimento de Caos

Instalar LitmusChaos en su clúster de Kubernetes:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

Verificar instalación:

kubectl get pods -n litmus

Nota: Asegúrate de que tu clúster esté listo para experimentos de caos.

Definir el Experimento de Caos

Crea un archivo YAML de ChaosExperiment para simular un escenario de eliminación de Pod.

Ejemplo (pod-delete.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

Instalar ChaosOperator y configurar la Cuenta de Servicio

Desplegar ChaosOperator para gestionar experimentos:

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

Nota: Crea una ServiceAccount para otorgar los permisos necesarios.

Inyectar Caos en la Aplicación Objetivo

Etiquetar el espacio de nombres de la aplicación para el caos:

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

Desplegar un ChaosEngine para activar el experimento:

Ejemplo (chaosengine.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

Aplicar el ChaosEngine:

kubectl apply -f chaosengine.yaml

Monitorear el Experimento

Ver el progreso:

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

Verificar el estado de los pods de caos:

kubectl get pods -n <target-namespace>

Analizar los Resultados

Después del experimento, revisa los registros y métricas para determinar si la aplicación se recuperó automáticamente o falló bajo estrés.

Aquí hay algunas métricas a monitorear:

• Tiempo de respuesta de la aplicación
• Tasas de error durante y después del experimento
• Tiempo tomado para que los pods se recuperen

Solución

Causa raíz identificada: Durante el alto tráfico, los pods fallaron debido a un número insuficiente de réplicas en el despliegue y límites de recursos inapropiados.

Correcciones aplicadas:

• Aumentó el número de réplicas en el despliegue para manejar un mayor tráfico.
• Configuró solicitudes y límites adecuados de recursos para CPU y memoria en la especificación del pod
• Implementó un Autoscaler de Pod Horizontal (HPA) para manejar picos de tráfico de forma dinámica

Conclusión

Al utilizar LitmusChaos para simular fallas en el pod, identificamos debilidades clave en la implementación de Kubernetes de la plataforma de comercio electrónico. El experimento de caos demostró que la resistencia puede mejorarse significativamente con ajustes de escalado y asignación de recursos. La ingeniería del caos permitió un fortalecimiento proactivo del sistema, lo que resultó en una mejor disponibilidad y satisfacción del cliente.