Chaos Engineering Con Litmus: Un Progetto Incubato da CNCF

Dichiarazione del problema: Garantire la resilienza di una piattaforma di e-commerce basata su microservizi.

La resilienza del sistema si pone come requisito chiave per le piattaforme di e-commerce durante le operazioni di scalabilità per mantenere i servizi operativi e offrire un’eccellenza delle prestazioni agli utenti. Abbiamo sviluppato una piattaforma architetturale basata su microservizi che incontra fallimenti sporadici del sistema quando si trova di fronte a eventi di traffico intenso. I problemi con la disponibilità dei servizi degradati insieme all’impatto sulle entrate si verificano principalmente a causa dei crash dei pod di Kubernetes insieme all’esaurimento delle risorse e alle interruzioni di rete che si verificano durante le stagioni di acquisto di picco.

L’organizzazione prevede di utilizzare il progetto Litmus incubato da CNCF per condurre valutazioni e miglioramenti della resilienza della piattaforma. I punti deboli del nostro sistema diventano più chiari quando conduci test di fallimento simulati utilizzando Litmus, che ci consente di attivare situazioni di fallimento del mondo reale come eventi di terminazione del pod e ritardi di rete, e limiti di utilizzo delle risorse. Gli esperimenti ci consentono di convalidare i sistemi di automazione della scalabilità mentre testiamo le procedure di ripristino di emergenza e massimizziamo le impostazioni di Kubernetes verso la totale affidabilità del sistema.

Il sistema crea una solida base per resistere alle situazioni di fallimento e distribuire in modo sicuro i periodi di traffico intenso senza deteriorare la qualità dell’esperienza dell’utente. L’ingegneria del caos applicata in modo proattivo alla nostra infrastruttura consente una migliore riduzione del rischio e un aumento dell’osservabilità, che ci consente di sviluppare metodi di ripristino automatizzati che migliorano la resilienza dell’e-commerce della nostra piattaforma in ogni condizione operativa.

Configura l’ambiente sperimentale del caos

Installa LitmusChaos nel tuo cluster Kubernetes:

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

helm repo update

helm install litmus litmuschaos/litmus

Verifica dell’installazione:

kubectl get pods -n litmus

Nota: Assicurati che il tuo cluster sia pronto per gli esperimenti di caos.

Definire l’Esperimento di Caos

Creare un file YAML di ChaosExperiment per simulare uno scenario di eliminazione del Pod.

Esempio (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

Installare ChaosOperator e Configurare l’Account del Servizio

Implementare ChaosOperator per gestire gli esperimenti:

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

Nota: Creare un ServiceAccount per concedere le autorizzazioni necessarie.

Iniettare Caos nell’Applicazione Obiettivo

Etichettare lo spazio dei nomi dell’applicazione per il caos:

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

Implementare un ChaosEngine per avviare l’esperimento:

Esempio (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

Applicare il ChaosEngine:

kubectl apply -f chaosengine.yaml

Monitorare l’Esperimento

Visualizzare il progresso:

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

Controllare lo stato dei pod del caos:

kubectl get pods -n <target-namespace>

Analizzare i Risultati

Dopo l’esperimento, controllare i log e le metriche per determinare se l’applicazione si è ripresa automaticamente o ha fallito sotto stress.

Ecco alcune metriche da monitorare:

• Tempo di risposta dell’applicazione
• Tassi di errore durante e dopo l’esperimento
• Tempo impiegato per il ripristino dei pod

Soluzione

Causa radice identificata: Durante il traffico intenso, i pod sono falliti a causa di un numero insufficiente di repliche nel deployment e limiti di risorse non corretti.

Fix applicati:

• Aumentato il numero di repliche nel deployment per gestire un traffico più elevato
• Configurato correttamente le richieste e i limiti delle risorse per CPU e memoria nella specifica del pod
• Implementato un Autoscaler Orizzontale dei Pod (HPA) per gestire dinamicamente picchi di traffico

Conclusione

Utilizzando LitmusChaos per simulare guasti ai pod, abbiamo individuato le principali debolezze nella distribuzione di Kubernetes della piattaforma di e-commerce. L’esperimento del caos ha dimostrato che la resilienza può essere significativamente migliorata con aggiustamenti di ridimensionamento e allocazione delle risorse. L’ingegneria del caos ha permesso un rafforzamento proattivo del sistema, portando a una maggiore disponibilità e soddisfazione del cliente.