kube-monkey est une implémentation du Chaos Monkey de Netflix pour les clusters Kubernetes. Il supprime aléatoirement des pods Kubernetes (k8s) dans le cluster, encourageant et validant le développement de services résistants aux pannes.

Rejoignez-nous sur #kube-monkey sur le Slack Kubernetes.

kube-monkey s'exécute à une heure préconfigurée (run_hour, 8 h par défaut) en semaine, et construit un planning des déploiements qui subiront la mort aléatoire d'un pod au cours de la même journée. La plage horaire de la journée pendant laquelle la mort aléatoire d'un pod peut survenir est configurable et est par défaut de 10 h à 16 h.

kube-monkey peut être configuré avec une liste de namespaces

à mettre sur liste noire (tout déploiement dans un namespace mis sur liste noire ne sera pas touché)

Pour désactiver la liste noire, fournissez [""] dans le paramètre de configuration blacklisted_namespaces.

Adhésion au chaos (Opt-In)

kube-monkey fonctionne sur un modèle d'adhésion volontaire et ne planifiera des terminaisons que pour les applications Kubernetes (k8s) qui ont explicitement accepté que leurs pods soient terminés par kube-monkey.

L'adhésion se fait en définissant les labels suivants sur une application k8s :

kube-monkey/enabled : définissez "enabled" pour adhérer à kube-monkey
kube-monkey/mtbf : temps moyen entre pannes (Mean Time Between Failures), sous la forme d'un nombre entier et d'une unité : d pour les jours, h pour les heures ou m pour les minutes. Par exemple, s'il est défini sur "3d", l'application k8s peut s'attendre à ce qu'un pod soit tué environ un jour ouvré sur trois, et s'il est défini sur "2h", elle peut s'attendre à perdre un pod toutes les deux heures. Une valeur sans unité est lue comme des jours, donc "3" et "3d" signifient la même chose. Le temps moyen entre pannes le plus court est d'une minute. Notez que toutes les terminaisons se produisent dans la fenêtre d'exécution quotidienne (voir start_hour et end_hour), donc un mtbf plus court qu'une journée concentre les terminaisons de ce jour dans cette fenêtre. : un identifiant unique pour les applications k8s. Il est utilisé pour identifier les pods qui appartiennent à une application k8s, car les pods héritent des labels de leur application k8s. Ainsi, si kube-monkey détecte que l'application s'est inscrite comme victime, kube-monkey recherchera tous les pods ayant le label pour déterminer quels pods sont candidats à la suppression. Il est recommandé de définir cette valeur comme étant identique au nom de l'application. : le comportement par défaut est que kube-monkey ne tue qu'UN SEUL pod de votre application. Vous pouvez remplacer ce comportement en définissant la valeur sur :

kill-all si vous voulez que kube-monkey tue TOUS vos pods, quel que soit leur statut (y compris les pods non prêts et non en cours d'exécution). Ne nécessite pas kill-value. Utilisez ce label avec précaution.
fixed si vous voulez tuer un nombre précis de pods en cours d'exécution avec kill-value. Si vous surestimez, il tuera tous les pods en cours d'exécution et émettra un avertissement.
random-max-percent pour spécifier un % maximum avec kill-value pouvant être tué. À l'heure planifiée, un % aléatoire uniforme spécifié des pods en cours d'exécution sera terminé.
fixed-percent pour spécifier un % fixe avec kill-value pouvant être tué. À l'heure planifiée, un % spécifié des pods en cours d'exécution sera terminé.

kube-monkey/kill-value : spécifiez la valeur pour kill-mode

si fixed, fournissez un entier correspondant au nombre de pods à tuer
si random-max-percent, fournissez un nombre de 0 à 100 pour spécifier le % maximum de pods que kube-monkey peut tuer
si fixed-percent, fournissez un nombre de 0 à 100 pour spécifier le % de pods à tuer

Exemple de déploiement adhérent tuant un pod par purge

---
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 ...]

Pour les versions plus récentes de Kubernetes, vous devrez peut-être également ajouter les labels aux métadonnées de l'application 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 ...]

Remplacer l'apiserver

Cas d'utilisation :

Étant donné que client-go ne prend pas en charge le cluster dns explicitement avec une note // TODO: switch to using cluster DNS. dans le code, vous devrez peut-être remplacer l'apiserver.
Si vous exécutez un système non authentifié, vous devrez peut-être forcer le point de terminaison http de l'apiserver.

Pour remplacer l'apiserver, spécifiez dans le fichier config.toml

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

Comment fonctionne kube-monkey

Heure de planification

La planification a lieu une fois par jour en semaine - c'est à ce moment qu'est généré le planning des terminaisons pour le jour en cours. Pendant la planification, kube-monkey :

Génère une liste des applications k8s éligibles (les applications k8s qui ont adhéré et ne sont pas sur liste noire, si spécifié, et sont sur liste blanche, si spécifié)
Pour chaque application k8s éligible, calcule combien de pods tuer aujourd'hui à partir de kube-monkey/mtbf. Une application est tuée 24 h/mtbf fois par jour, donc un mtbf d'un jour ou plus donne au plus une terminaison et un mtbf plus court en donne plusieurs
Pour chaque terminaison, calcule une heure aléatoire à laquelle un pod sera tué

Heure de terminaison

C'est l'heure générée aléatoirement dans la journée à laquelle une application k8s victime aura un pod tué. À l'heure de terminaison, kube-monkey :

Vérifie si l'application k8s est toujours éligible (n'a pas renoncé, n'a pas été mise sur liste noire ou retirée de la liste blanche depuis la planification)
Vérifie si l'application k8s a mis à jour kill-mode et kill-value
Selon kill-mode et kill-value, exécute les pods

Images Docker

Les images Docker pour kube-monkey sont disponibles sur DockerHub

Construction

Clonez le dépôt et construisez le conteneur.

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

Configuration

kube-monkey est configuré par des variables d'environnement ou un fichier toml placé dans /etc/kube-monkey/config.toml et attend que la configmap existe avant le déploiement de kube-monkey.

Les clés de configuration et leurs descriptions se trouvent dans config/param/param.go

Exemple de fichier 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

Exemple de variables d'environnement

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

Exemple de configuration pour tester le fonctionnement de kube-monkey en activant le mode debug

Remarque : cela continuera d'attaquer les pods toutes les 60 s, indépendamment de ce que vous avez configuré pour startHour et endHour.

[debug]
enabled= true
schedule_immediate_kill= true

Notifications

Kube-monkey prend en charge les notifications et peut notifier un point de terminaison de votre choix après une attaque. Il peut s'agir d'un webhook Slack ou d'une API personnalisée.

Exemple de configuration pour publier des notifications d'attaque vers un point de terminaison HTTP

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

Espaces réservés (placeholders)

Le message prend en charge les espaces réservés suivants :

{$name} : nom de la victime
{$kind} : type de la victime
{$namespace} : namespace de la victime
{$timestamp} : heure de l'attaque depuis l'époque Unix en millisecondes
{$time} : heure de l'attaque
{$date} : date de l'attaque
{$error} : erreur du résultat, le cas échéant
{$kubemonkeyid} : identifiant kube-monkey (défini via la variable d'environnement KUBE_MONKEY_ID, vide sinon)

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

L'en-tête prend en charge un espace réservé spécial pour récupérer la valeur d'une variable d'environnement. Cela est utile lors de l'appel d'une API avec un point de terminaison protégé. Un scénario typique consiste à passer un jeton API au conteneur Kube-monkey ; ce jeton est stocké dans un secret Kubernetes et vous souhaitez le transmettre via une variable d'environnement.

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

{$env:API_TOKEN} sera remplacé par la valeur de la variable d'environnement API_TOKEN.

Remarque : si la variable d'environnement n'existe pas, l'appel de notification ne sera PAS annulé. La valeur sera résolue en une chaîne vide et un avertissement apparaîtra dans les journaux.

Déploiement

Manuel

Tout d'abord, déployez la configmap kube-monkey-config-map attendue dans le namespace où vous prévoyez d'exécuter kube-monkey (par exemple, le namespace kube-system). Assurez-vous de définir le nom de clé comme config.toml

Par exemple kubectl create configmap km-config --from-file=config.toml=km-config.toml ou kubectl apply -f km-config.yaml

Exécutez kube-monkey comme une application k8s dans le cluster Kubernetes, dans un namespace disposant des autorisations pour tuer des pods dans d'autres namespaces (par ex. kube-system).

Consultez le répertoire examples/ pour des exemples de fichiers yaml Kubernetes.

Vous devriez pouvoir voir les journaux de debug avec kubectl logs -f deployment.apps/kube-monkey --namespace=kube-system ; ici deployment.apps/kube-monkey est le déploiement k8s pour kube-monkey.

Chart Helm

Voir Comment installer kube-monkey avec Helm.

Journalisation (Logging)

kube-monkey utilise glog et prend en charge toutes les fonctionnalités en ligne de commande de glog. Pour spécifier un niveau v personnalisé ou un répertoire de journaux personnalisé sur le pod, consultez args: ["-v=5", "-log_dir=/path/to/custom/log"] dans le fichier d'exemple de déploiement

Niveaux glog standardisés grep -r V$[0-9]$ *

L0 : aucun

L1 : niveau le plus élevé, informations sur le statut actuel et erreurs liées aux terminaisons

L2 : terminaisons réussies

L3 : informations plus détaillées sur le statut du planning

L4 : débogage verbeux du planning et des informations de configuration

L5 : problèmes sans conséquence résolus automatiquement

Plus de ressources : consultez la page de journalisation k8s suggérant les conventions communautaires pour la sévérité de la journalisation

Instructions pour faire fonctionner cela sur 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

Comment contribuer

Consultez Comment contribuer

Licence

Ce projet est sous licence Apache License v2.0 - voir le fichier LICENSE pour plus de détails.

kube-monkey

Populaires