Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/litmuschaos/chaos-operator
Sicurezza dell'Infrastruttura CloudSicurezza CloudDevSecOpsIngegneria del Caos
GitHublitmuschaos/chaos-operator

chaos-operator

Operatore Kubernetes per iniettare esperimenti di chaos nei carichi di lavoro cloud-native, automatizzando i test di resilienza e l'hardening dei carichi di lavoro tramite CRD dichiarative.

Vedi Repository
1571061 mese faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Litmus chaos-operator per l'iniezione di esperimenti di chaos su Kubernetes

Slack Channel GitHub Workflow Docker Pulls GitHub issues Twitter Follow Codacy Badge Go Report Card CII Best Practices FOSSA Status codecov YouTube Channel

Il Litmus chaos operator è utilizzato dagli sviluppatori di applicazioni Kubernetes e dagli SRE per iniettare chaos nelle applicazioni e nell'infrastruttura Kubernetes in modo controllato. Il suo obiettivo è rendere semplice il processo di validazione e hardening dei carichi di lavoro applicativi su Kubernetes automatizzando l'esecuzione di esperimenti di chaos. Un esempio di flusso di lavoro per l'iniezione di chaos potrebbe essere semplice come:

  • Installare i componenti dell'infrastruttura Litmus (RBAC, CRDs), l'Operator e i bundle di risorse personalizzate degli esperimenti tramite il manifest dell'operatore
  • Annotare l'applicazione in test (AUT), abilitandola per il chaos
  • Creare una risorsa personalizzata ChaosEngine collegata all'AUT, che descrive l'esperimento da eseguire

I vantaggi offerti dal Chaos Operator includono:

  • Specifica standardizzata degli esperimenti di chaos
  • Bundle di chaos categorizzati per applicazioni stateless/stateful/fornitore-specifiche
  • Resilienza delle esecuzioni di test
  • Capacità di eseguire il chaos come servizio in background basato su annotazioni

Cos'è un chaos operator e come è costruito?

Il Chaos Operator è un Kubernetes Operator, che non sono altro che controller personalizzati con accesso diretto all'API di Kubernetes in grado di gestire il ciclo di vita di determinate risorse o applicazioni, cercando sempre di garantire che la risorsa sia nello "stato desiderato". La logica che garantisce questo viene comunemente chiamata funzione "reconcile".

Il Chaos Operator è costruito utilizzando il popolare framework Operator-SDK, che fornisce supporto di bootstrap per nuovi progetti operator, consentendo ai team di concentrarsi sulla logica di business/operativa.

Il Litmus Chaos Operator aiuta a riconciliare lo stato del ChaosEngine, una risorsa personalizzata che contiene l'intento di chaos specificato da uno sviluppatore/ingegnere devops nei confronti di un particolare deployment Kubernetes stateless/stateful. L'operator esegue azioni specifiche in seguito alle operazioni CRUD sul ChaosEngine, la sua risorsa primaria. L'operator definisce anche una risorsa secondaria (il pod engine runner), che viene creato e gestito da esso per implementare le funzioni di reconcile.

Cos'è un chaos engine?

Il ChaosEngine è lo schema principale che definisce il flusso di lavoro di chaos per una data applicazione. Attualmente, definisce quanto segue:

  • Informazioni sull'applicazione (namespace, etichette, kind) delle applicazioni primarie (AUT) e ausiliarie (dipendenti)
  • ServiceAccount utilizzato per l'esecuzione dell'esperimento
  • Flag per attivare/disattivare i controlli delle annotazioni di chaos sulle applicazioni
  • Esperimento di chaos da eseguire sull'applicazione
  • Attributi degli esperimenti (sovrascrive le impostazioni predefinite specificate nelle CR degli esperimenti)
  • Flag per conservare/pulire le risorse di chaos dopo l'esecuzione dell'esperimento

Il ChaosEngine è indicato come proprietario della risorsa secondaria (di reconcile) con la deletePropagation di Kubernetes che garantisce che anche queste vengano rimosse all'eliminazione della CR ChaosEngine.

Ecco un esempio di ChaosEngineSpec per riferimento: https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine

Cos'è un litmus chaos chart e come posso usarlo?

I Litmus Chaos Charts vengono utilizzati per installare "Chaos Experiment Bundles" e sono categorizzati in base alla natura degli esperimenti (chaos Kubernetes generale, chaos specifico del fornitore/produttore - come OpenEBS o chaos specifico dell'applicazione, ad esempio NuoDB). Sono costituiti da risorse personalizzate che contengono parametri di chaos(test) di basso livello interrogati dall'operator per eseguire gli esperimenti. I fields di spec.definition e i corrispondenti values vengono utilizzati per costruire l'artefatto di esecuzione finale che esegue l'esperimento di chaos (tipicamente, il litmusbook, che è una risorsa job K8s). Definisce inoltre i permessi necessari per eseguire l'esperimento.

Ecco un esempio di ChaosEngineSpec per riferimento:

root@kitploit:~
apiVersion: litmuschaos.io/v1alpha1
description:
  message: |
    Deletes a pod belonging to a deployment/statefulset/daemonset
kind: ChaosExperiment
metadata:
  name: pod-delete
  labels:
    name: pod-delete
    app.kubernetes.io/part-of: litmus
    app.kubernetes.io/component: chaosexperiment
    app.kubernetes.io/version: latest
spec:
  definition:
    scope: Namespaced
    permissions:
      - apiGroups:
          - ""
          - "apps"
          - "batch"
          - "litmuschaos.io"
        resources:
          - "deployments"
          - "jobs"
          - "pods"
          - "configmaps"
          - "chaosengines"
          - "chaosexperiments"
          - "chaosresults"
        verbs:
          - "create"
          - "list"
          - "get"
          - "patch"
          - "update"
          - "delete"
    image: "litmuschaos/go-runner:latest"
    imagePullPolicy: Always
    args:
    - -c
    - ./experiments -name pod-delete
    command:
    - /bin/bash
    env:

    - name: TOTAL_CHAOS_DURATION
      value: '15'

    # Period to wait before/after injection of chaos in sec
    - name: RAMP_TIME
      value: ''

    - name: FORCE
      value: 'true'

    - name: CHAOS_INTERVAL
      value: '5'

    ## percentage of total pods to target
    - name: PODS_AFFECTED_PERC
      value: ''

    - name: LIB
      value: 'litmus'    

    - name: TARGET_PODS
      value: ''

    ## it defines the sequence of chaos execution for multiple target pods
    ## supported values: serial, parallel
    - name: SEQUENCE
      value: 'parallel'
    labels:
      name: pod-delete
      app.kubernetes.io/part-of: litmus
      app.kubernetes.io/component: experiment-job
      app.kubernetes.io/version: latest

Come iniziare?

Consulta la documentazione LitmusChaos litmus docs

Come posso contribuire?

Puoi contribuire segnalando problemi, migliorando la documentazione, contribuendo al framework principale e agli strumenti, ecc.

Vai alla Guida ai contributi

Licenza

FOSSA Status

Scarica lo strumento