kube-monkey ist eine Implementierung von Netflix' Chaos Monkey für Kubernetes-Cluster. Es löscht zufällig Kubernetes-Pods (k8s) im Cluster und fördert und validiert dadurch die Entwicklung ausfallsicherer Dienste.

Besuchen Sie uns unter #kube-monkey im Kubernetes-Slack.

kube-monkey läuft an Wochentagen zu einer vorkonfigurierten Stunde (run_hour, standardmäßig 8 Uhr) und erstellt einen Zeitplan für Deployments, die im Laufe desselben Tages einen zufälligen Pod-Tod erleiden. Der Zeitbereich während des Tages, in dem der zufällige Pod-Tod auftreten kann, ist konfigurierbar und standardmäßig auf 10 bis 16 Uhr festgelegt.

kube-monkey kann mit einer Liste von Namespaces konfiguriert werden,

die auf die Blacklist gesetzt werden sollen (Deployments innerhalb eines geblacklisteten Namespaces werden nicht angefasst).

Um die Blacklist zu deaktivieren, geben Sie [""] im Konfigurationsparameter blacklisted_namespaces an.

Opt-in zum Chaos

kube-monkey arbeitet nach einem Opt-in-Modell und plant Terminierungen nur für Kubernetes-Applikationen (k8s), die ausdrücklich zugestimmt haben, dass ihre Pods von kube-monkey terminiert werden.

Das Opt-in erfolgt durch Setzen der folgenden Labels auf einer k8s-App:

kube-monkey/enabled: Setzen Sie es auf "enabled", um kube-monkey zu aktivieren.
kube-monkey/mtbf: Mittlere Ausfallzeit (Mean Time Between Failures) als ganze Zahl mit einer Einheit: d für Tage, h für Stunden oder m für Minuten. Wenn zum Beispiel "3d" gesetzt ist, kann die k8s-App damit rechnen, dass ungefähr jeden dritten Werktag ein Pod terminiert wird; bei "2h" kann sie damit rechnen, alle zwei Stunden einen Pod zu verlieren. Ein Wert ohne Einheit wird als Tage interpretiert, daher bedeuten "3" und "3d" dasselbe. Die kürzeste mittlere Ausfallzeit beträgt eine Minute. Beachten Sie, dass alle Terminierungen innerhalb des täglichen Ausführungsfensters stattfinden (siehe start_hour und end_hour); eine kürzere mtbf als ein Tag bündelt daher die Terminierungen des Tages in dieses Fenster. : Eine eindeutige Kennung für die k8s-Apps. Sie wird verwendet, um die Pods zu identifizieren, die zu einer k8s-App gehören, da Pods die Labels ihrer k8s-App erben. Wenn kube-monkey also erkennt, dass die App sich als Opfer angemeldet hat, sucht kube-monkey nach allen Pods mit dem Label , um zu bestimmen, welche Pods Kandidaten für die Terminierung sind. Es wird empfohlen, diesen Wert auf denselben Namen wie den der App zu setzen. : Standardmäßig terminiert kube-monkey nur EINEN Pod Ihrer App. Sie können dieses Verhalten überschreiben, indem Sie den Wert setzen auf:

kill-all, wenn kube-monkey ALLE Ihre Pods unabhängig vom Status terminieren soll (einschließlich nicht bereiter und nicht laufender Pods). kill-value ist nicht erforderlich. Verwenden Sie dieses Label mit Vorsicht.
fixed, wenn Sie mit kill-value eine bestimmte Anzahl laufender Pods terminieren möchten. Wenn Sie zu viele angeben, werden alle laufenden Pods terminiert und eine Warnung ausgegeben.
random-max-percent, um mit kill-value einen maximalen %-Anteil anzugeben, der terminiert werden kann. Zum geplanten Zeitpunkt wird ein gleichverteilt zufällig festgelegter %-Anteil der laufenden Pods terminiert.
fixed-percent, um mit kill-value einen festen %-Anteil anzugeben, der terminiert werden kann. Zum geplanten Zeitpunkt wird ein festgelegter fester %-Anteil der laufenden Pods terminiert.

kube-monkey/kill-value: Wert für den kill-mode angeben:

Bei fixed eine ganze Zahl der zu terminierenden Pods angeben.
Bei random-max-percent eine Zahl von 0-100 angeben, um den maximalen %-Anteil an Pods festzulegen, den kube-monkey terminieren kann.
Bei fixed-percent eine Zahl von 0-100 angeben, um den %-Anteil der zu terminierenden Pods festzulegen.

Beispiel für ein Opt-in-Deployment, das einen Pod pro Durchgang terminiert

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

Bei neueren Versionen von Kubernetes müssen Sie die Labels möglicherweise auch zu den Metadaten der k8s-App hinzufügen.

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

Überschreiben des API-Servers

Anwendungsfälle:

Da client-go Cluster-DNS nicht explizit unterstützt – mit einem // TODO: switch to using cluster DNS.-Hinweis im Code –, müssen Sie den API-Server möglicherweise überschreiben.
Wenn Sie ein nicht authentifiziertes System betreiben, müssen Sie möglicherweise den HTTP-API-Server-Endpunkt erzwingen.

Zum Überschreiben des API-Servers in der config.toml-Datei angeben:

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

So funktioniert kube-monkey

Planungszeitpunkt

Die Planung findet einmal täglich an Wochentagen statt – dabei wird ein Zeitplan für die Terminierungen des aktuellen Tages erstellt. Während der Planung wird kube-monkey:

Eine Liste der berechtigten k8s-Apps erstellen (k8s-Apps, die sich angemeldet haben und nicht auf der Blacklist stehen, falls angegeben, sowie auf der Whitelist stehen, falls angegeben).
Für jede berechtigte k8s-App berechnen, wie viele Pods heute anhand von kube-monkey/mtbf terminiert werden sollen. Eine App wird 24h/mtbf Mal pro Tag terminiert; ein mtbf von einem Tag oder mehr ergibt höchstens eine Terminierung, ein kürzerer mehrere.
Für jede Terminierung einen zufälligen Zeitpunkt berechnen, zu dem ein Pod terminiert wird.

Terminierungszeitpunkt

Dies ist die zufällig erzeugte Uhrzeit während des Tages, zu der eine Opfer-k8s-App einen Pod verlieren wird. Zum Terminierungszeitpunkt wird kube-monkey:

Prüfen, ob die k8s-App weiterhin berechtigt ist (sie hat sich seit der Planung nicht abgemeldet, wurde nicht auf die Blacklist gesetzt oder von der Whitelist entfernt).
Prüfen, ob die k8s-App kill-mode und kill-value aktualisiert hat.
Abhängig von kill-mode und kill-value Pods terminieren.

Docker-Images

Docker-Images für kube-monkey finden Sie auf DockerHub.

Erstellen

Klonen Sie das Repository und erstellen Sie den Container.

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

Konfiguration

kube-monkey wird über Umgebungsvariablen oder eine TOML-Datei unter /etc/kube-monkey/config.toml konfiguriert und erwartet, dass die ConfigMap vor der kube-monkey-Bereitstellung existiert.

Konfigurationsschlüssel und -beschreibungen finden Sie in config/param/param.go.

Beispiel einer config.toml-Datei

[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

Beispiel für Umgebungsvariablen

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

Beispielkonfiguration zum Testen der Funktion von kube-monkey durch Aktivieren des Debug-Modus

Hinweis: Dadurch werden weiterhin alle 60 Sekunden Pods angegriffen, unabhängig davon, was Sie für startHour und endHour konfiguriert haben.

[debug]
enabled= true
schedule_immediate_kill= true

Benachrichtigungen

Kube-monkey unterstützt Benachrichtigungen und kann nach einem Angriff einen Endpoint Ihrer Wahl benachrichtigen. Dies kann ein Slack-Webhook oder eine eigene API sein.

Beispielkonfiguration zum Senden von Angriffsbenachrichtigungen an einen HTTP-Endpoint

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

Platzhalter

Die Nachricht unterstützt die folgenden Platzhalter:

{$name}: Name des Opfers
{$kind}: Art des Opfers
{$namespace}: Namespace des Opfers
{$timestamp}: Zeitpunkt des Angriffs ab Unix-Epoche in Millisekunden
{$time}: Uhrzeit des Angriffs
{$date}: Datum des Angriffs
{$error}: Fehler des Ergebnisses, falls vorhanden
{$kubemonkeyid}: kube-monkey-ID (gesetzt über die Umgebungsvariable KUBE_MONKEY_ID, andernfalls leer)

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

Der Header unterstützt einen speziellen Platzhalter, um den Wert einer Umgebungsvariablen abzurufen. Dies ist nützlich, wenn Sie eine API mit einem geschützten Endpoint aufrufen. Ein typisches Szenario ist die Übergabe eines API-Tokens an den Kube-monkey-Container; dieses Token wird in einem Kubernetes-Secret gespeichert und Sie möchten es über eine Umgebungsvariable übergeben.

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

{$env:API_TOKEN} wird durch den Wert der Umgebungsvariable API_TOKEN ersetzt.

Hinweis: Wenn die Umgebungsvariable nicht existiert, wird der Benachrichtigungsaufruf NICHT abgebrochen. Der Wert wird zu einer leeren Zeichenkette aufgelöst, und eine Warnung erscheint in den Logs.

Bereitstellung

Manuell

Stellen Sie zuerst die erwartete ConfigMap kube-monkey-config-map in dem Namespace bereit, in dem Sie kube-monkey ausführen möchten (z. B. im Namespace kube-system). Stellen Sie sicher, dass der Schlüsselname als config.toml definiert ist.

Zum Beispiel kubectl create configmap km-config --from-file=config.toml=km-config.toml oder kubectl apply -f km-config.yaml

Führen Sie kube-monkey als k8s-App im Kubernetes-Cluster aus, und zwar in einem Namespace, der die Berechtigung hat, Pods in anderen Namespaces zu terminieren (z. B. kube-system).

Beispielhafte Kubernetes-YAML-Dateien finden Sie im Verzeichnis examples/.

Sie sollten Debug-Logs mit kubectl logs -f deployment.apps/kube-monkey --namespace=kube-system sehen können; deployment.apps/kube-monkey ist hierbei das k8s-Deployment für kube-monkey.

Helm Chart

Siehe So installieren Sie kube-monkey mit Helm.

Logging

kube-monkey verwendet glog und unterstützt alle Kommandozeilenfunktionen von glog. Um einen benutzerdefinierten v-Level oder ein benutzerdefiniertes Log-Verzeichnis auf dem Pod anzugeben, siehe args: ["-v=5", "-log_dir=/path/to/custom/log"] in der Beispiel-Deployment-Datei.

Standardisierte glog-Level grep -r V$[0-9]$ *

L0: Keine

L1: Aktuelle Statusinformationen auf höchster Ebene und Fehler bei Terminierungen

L2: Erfolgreiche Terminierungen

L3: Detailliertere Statusinformationen zum Zeitplan

L4: Ausführliche Debug-Informationen zu Zeitplan und Konfiguration

L5: Automatisch aufgelöste, unbedeutende Probleme

Weitere Ressourcen: Siehe die k8s-Logging-Seite, die Community-Konventionen für den Schweregrad von Logs vorschlägt.

Anleitung für die Einrichtung auf 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

Möglichkeiten zur Mitarbeit

Siehe So können Sie beitragen.

Lizenz

Dieses Projekt ist unter der Apache-Lizenz v2.0 lizenziert – Einzelheiten finden Sie in der Datei LICENSE.

kube-monkey

Beliebteste