kube-monkey è un'implementazione del Chaos Monkey di Netflix per i cluster Kubernetes. Elimina in modo casuale i pod Kubernetes (k8s) nel cluster, incoraggiando e convalidando lo sviluppo di servizi resilienti ai guasti.

Unisciti a noi su #kube-monkey nello Slack di Kubernetes.

kube-monkey viene eseguito a un'ora preconfigurata (run_hour, di default alle 8 di mattina) nei giorni feriali e genera una pianificazione dei deployment che subiranno una morte casuale di un Pod durante lo stesso giorno. L'intervallo di tempo del giorno in cui può verificarsi la morte casuale del Pod è configurabile e di default è dalle 10 alle 16.

kube-monkey può essere configurato con un elenco di namespace

da inserire in blacklist (qualsiasi deployment all'interno di un namespace in blacklist non verrà toccato)

Per disabilitare la blacklist, fornisci [""] nel parametro di configurazione blacklisted_namespaces.

Adesione al Chaos

kube-monkey funziona con un modello opt-in e pianificherà terminazioni solo per app Kubernetes (k8s) che hanno esplicitamente accettato che i loro pod vengano terminati da kube-monkey.

L'opt-in si effettua impostando le seguenti label su un'app k8s:

kube-monkey/enabled: Impostala su "enabled" per aderire a kube-monkey
kube-monkey/mtbf: Tempo medio tra i guasti, espresso come numero intero e un'unità: d per giorni, h per ore o m per minuti. Ad esempio, se impostata su "3d", l'app k8s può aspettarsi che un Pod venga ucciso circa ogni terzo giorno lavorativo; se impostata su "2h", può aspettarsi di perdere un Pod ogni due ore. Un valore senza unità viene letto come giorni, quindi "3" e "3d" significano la stessa cosa. Il tempo medio tra i guasti più breve è un minuto. Nota che tutte le terminazioni avvengono all'interno della finestra di esecuzione giornaliera (vedi start_hour ed end_hour), quindi un mtbf più breve di un giorno concentra le terminazioni di quel giorno in quella finestra. : Un identificatore univoco per le app k8s. Viene usato per identificare i pod che appartengono a un'app k8s, poiché i Pod ereditano le label dalla loro app k8s. Quindi, se kube-monkey rileva che l'app si è iscritta come vittima, cercherà tutti i pod che hanno la label per determinare quali pod sono candidati all'uccisione. Il consiglio è di impostare questo valore uguale al nome dell'app. : Il comportamento predefinito prevede che kube-monkey uccida solo UN pod della tua app. Puoi sovrascrivere questo comportamento impostando il valore su:

kill-all se vuoi che kube-monkey uccida TUTTI i tuoi pod indipendentemente dallo stato (inclusi i pod non pronti e non in esecuzione). Non richiede kill-value. Usa questa label con attenzione.
fixed se vuoi uccidere un numero specifico di pod in esecuzione con kill-value. Se specifichi un numero eccessivo, ucciderà tutti i pod in esecuzione ed emetterà un avviso.
random-max-percent per specificare una percentuale massima % con kill-value che può essere uccisa. All'ora pianificata, verrà terminata una percentuale casuale uniforme % dei pod in esecuzione.
fixed-percent per specificare una percentuale fissa % con kill-value che può essere uccisa. All'ora pianificata, verrà terminata una percentuale fissa specificata dei pod in esecuzione.

kube-monkey/kill-value: Specifica il valore per la kill-mode

se fixed, fornisci un numero intero di pod da uccidere
se random-max-percent, fornisci un numero da 0 a 100 per specificare la % massima di pod che kube-monkey può uccidere
se fixed-percent, fornisci un numero da 0 a 100 per specificare la % di pod da uccidere

Esempio di Deployment aderente che uccide un pod per attacco

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
        kube-monkey/mtbf: '2'
        kube-monkey/kill-mode: "fixed"
        kube-monkey/kill-value: '1'
[... omitted ...]

Per le versioni più recenti di Kubernetes, potrebbe essere necessario aggiungere le label anche ai metadati dell'app k8s.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
  labels:
    kube-monkey/enabled: enabled
    kube-monkey/identifier: monkey-victim
    kube-monkey/mtbf: '2'
    kube-monkey/kill-mode: "fixed"
    kube-monkey/kill-value: '1'
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
[... omitted ...]

Sovrascrivere l'apiserver

Casi d'uso:

Poiché client-go non supporta esplicitamente il cluster DNS (con un // TODO: switch to using cluster DNS. nel codice), potresti dover sovrascrivere l'apiserver.
Se stai eseguendo un sistema non autenticato, potresti dover forzare l'endpoint http dell'apiserver.

Per sovrascrivere l'apiserver, specifica nel file config.toml

[kubernetes]
host="https://your-apiserver-url.com:apiport"

Come funziona kube-monkey

Orario di pianificazione

La pianificazione avviene una volta al giorno nei giorni feriali: è il momento in cui viene generata una pianificazione delle terminazioni per il giorno corrente. Durante la pianificazione, kube-monkey:

Genera un elenco di app k8s idonee (app k8s che hanno aderito e non sono in blacklist, se specificata, e sono in whitelist, se specificata)
Per ogni app k8s idonea, calcola quanti pod uccidere oggi in base a kube-monkey/mtbf. Un'app viene uccisa 24h/mtbf volte al giorno, quindi un mtbf di un giorno o più dà al massimo una terminazione, mentre uno più breve ne dà diverse
Per ogni terminazione, calcola un orario casuale in cui un pod verrà ucciso

Orario di terminazione

È l'orario generato casualmente durante il giorno in cui un'app k8s vittima avrà un pod ucciso. All'orario di terminazione, kube-monkey:

Verifica se l'app k8s è ancora idonea (non ha rinunciato, non è stata inserita in blacklist o rimossa dalla whitelist dalla pianificazione)
Verifica se l'app k8s ha aggiornato kill-mode e kill-value
In base a kill-mode e kill-value, termina i pod

Immagini Docker

Le immagini Docker per kube-monkey sono disponibili su DockerHub

Compilazione

Clona il repository e compila il container.

go get github.com/asobti/kube-monkey
cd $GOPATH/src/github.com/asobti/kube-monkey
make build
make container

Configurazione

kube-monkey viene configurato tramite variabili d'ambiente o un file toml posizionato in /etc/kube-monkey/config.toml e richiede che la configmap esista prima del deployment di kube-monkey.

Le chiavi di configurazione e le relative descrizioni sono disponibili in config/param/param.go

Esempio di file config.toml

[kubemonkey]
dry_run = true                           # Terminations are only logged
run_hour = 8                             # Run scheduling at 8am on weekdays
start_hour = 10                          # Don't schedule any pod deaths before 10am
end_hour = 16                            # Don't schedule any pod deaths after 4pm
blacklisted_namespaces = ["kube-system"] # Critical apps live here
time_zone = "America/New_York"           # Set tzdata timezone example. Note the field is time_zone not timezone

Esempio di variabili d'ambiente

KUBEMONKEY_DRY_RUN=true
KUBEMONKEY_RUN_HOUR=8
KUBEMONKEY_START_HOUR=10
KUBEMONKEY_END_HOUR=16
KUBEMONKEY_BLACKLISTED_NAMESPACES=kube-system
KUBEMONKEY_TIME_ZONE=America/New_York

Esempio di configurazione per testare kube-monkey abilitando la modalità debug

Nota: continuerà ad attaccare i pod ogni 60 secondi, indipendentemente da ciò che hai configurato per startHour ed endHour.

[debug]
enabled= true
schedule_immediate_kill= true

Notifiche

kube-monkey supporta le notifiche e può notificare un endpoint a tua scelta dopo un attacco. Può essere un webhook Slack o un'API personalizzata.

Esempio di configurazione per inviare notifiche di attacco a un endpoint HTTP

[notifications]
  enabled = true
  reportSchedule = true
  [notifications.attacks]
    endpoint = "http://url1"
    message = "message1"
    headers = ["header1Key:header1Value","header2Key:header2/Value"]

Segnaposto

Il messaggio supporta i seguenti segnaposto:

{$name}: nome della vittima
{$kind}: tipo della vittima
{$namespace}: namespace della vittima
{$timestamp}: orario dell'attacco dall'epoch Unix in millisecondi
{$time}: orario dell'attacco
{$date}: data dell'attacco
{$error}: errore del risultato, se presente
{$kubemonkeyid}: ID di kube-monkey (impostato usando la variabile d'ambiente KUBE_MONKEY_ID, altrimenti vuoto)

  message: '{
            "what": "Kube-monkey(${kubemonkeyid}) attack of {$name} in {$namespace}",
            "who": "{$name}",
            "when": {$timestamp}
           }'

L'header supporta un segnaposto speciale per recuperare il valore di una variabile d'ambiente. È utile quando si chiama un'API con un endpoint protetto. Uno scenario tipico è passare un token API al container di kube-monkey: il token è archiviato in un Secret Kubernetes e lo si vuole passare tramite una variabile d'ambiente.

headers = ["api-key:{$env:API_TOKEN}", "Content-Type:application/json"]

{$env:API_TOKEN} verrà sostituito dal valore della variabile d'ambiente API_TOKEN.

Nota: se la variabile d'ambiente non esiste, la chiamata di notifica NON verrà annullata. Il valore verrà risolto in una stringa vuota e apparirà un avviso nei log.

Deployment

Manualmente

Per prima cosa, distribuisci la configmap kube-monkey-config-map prevista nel namespace in cui intendi eseguire kube-monkey (ad esempio, il namespace kube-system). Assicurati di definire il nome della chiave come config.toml

Ad esempio kubectl create configmap km-config --from-file=config.toml=km-config.toml oppure kubectl apply -f km-config.yaml

Esegui kube-monkey come app k8s all'interno del cluster Kubernetes, in un namespace che abbia i permessi per uccidere Pod in altri namespace (es. kube-system).

Vedi la directory examples/ per esempi di file yaml Kubernetes.

Dovresti essere in grado di vedere i log di debug con kubectl logs -f deployment.apps/kube-monkey --namespace=kube-system; qui deployment.apps/kube-monkey è il deployment k8s per kube-monkey.

Helm Chart

Vedi Come installare kube-monkey con Helm.

Logging

kube-monkey usa glog e supporta tutte le funzionalità da riga di comando di glog. Per specificare un livello v personalizzato o una directory dei log personalizzata sul pod, vedi args: ["-v=5", "-log_dir=/path/to/custom/log"] nel file di deployment di esempio

Livelli glog standardizzati grep -r V$[0-9]$ *

L0: Nessuno

L1: Informazioni di stato di livello più alto ed errori relativi alle terminazioni

L2: Terminazioni riuscite

L3: Informazioni più dettagliate sullo stato della pianificazione

L4: Informazioni dettagliate di debug su pianificazione e configurazione

L5: Problemi irrilevanti risolti automaticamente

Altre risorse: vedi la pagina di logging di k8s che suggerisce le convenzioni della community per la gravità dei log

Istruzioni per farlo funzionare su OpenShift 3.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-role-to-user -z deployer system:deployer
oc -n kube-system adm policy add-role-to-user -z builder system:image-builder
oc -n kube-system adm policy add-role-to-group system:image-puller system:serviceaccounts:kube-system
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.4.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

OpenShift 4.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-cluster-role-to-user edit -z default --rolebinding-name kube-monkey-edit
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.3.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc set volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

Come contribuire

Vedi Come contribuire

Licenza

Questo progetto è concesso in licenza secondo la Apache License v2.0 - vedi il file LICENSE per i dettagli.

kube-monkey

Più Popolari