Chaos in Kubenetes

Kubernetes maakt gebruik van deployments waarmee pods (daar waar de containers in zitten) herstart kunnen worden als zij vastlopen, teveel computer resources gebruiken, of een updated versie krijgen, enz. Dat is de kracht van K8S!

Maar kan elke applicatie er wel tegen om opnieuw ge-deployed te worden? Wat als er niets aan de hand is en de applicatie pas na lange tijd gaat herstarten? Bij NetFlix dachten de engineers in 2011 dat er een applicatie moest komen die applicaties willekeurig, expres, gaat herstarten, en ze noemden dit ‘Chaos Monkey‘.

kubernetes-kube-monkey

Een afgeleide van ‘Chaos Monkey’, speciaal voor Kubernetes, is ‘Kube Monkey‘. Het idee achter ‘Kube Monkey’ is dat iedere pod willekeurig herstart moet kunnen worden zonder dat dit merkbare gevolgen heeft in een productie-omgeving.

Installatie

De installatie van Kube Monkey is eenvoudig met behulp van een deployment en een configmap. De waardes die gebruikt worden in de configmap zijn alsvolgt:

  • dryRun: true – dit zorgt ervoor dat er geen pods worden herstart, wel een regel in de log voor naslag van de werking
  • runHour: 8 – KubeMonkey start scheduling restarts vanaf dit uur
  • startHour: 10 – wacht tot dit uur met de eerste herstart
  • endHour: 16 – stop met herstarten na dit uur
  • blacklistedNamespace: kube-system – exclude deze namespaces voor herstarts
  • whitelistedNamespaces: default – herstart pods in deze namespaces ( leeg is alles)
  • timeZone: Ameria/New_York : standaard tijdzone, wijzig naar Europe/Amsterdam
  • debug_enabled: false – indien op true wordt de debug modus actief
  • schedule_immediate_kill: false – indien op true wordt niet gewacht op de tijd-instelling

De ConfigMap maken we met behulp van een manifest genaamd km-configmap.yml:

---
apiVersion: v1
data:
  config.toml: |
    [kubemonkey]
    dry_run = true 
    run_hour = 8 
    start_hour = 10
    end_hour = 16
    blacklisted_namespaces = ["kube-system"] 
    whitelisted_namespaces = [""] 
    time_zone = "Europe/Amsterdam"
    [debug]
    enabled= true
    schedule_immediate_kill= true
kind: ConfigMap
metadata:
  name: km-config
  namespace: kube-system

De deployment voor ‘Kube Monkey’ in km-deploy.yml ziet er alsvolgt uit:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-monkey
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-monkey
  template:
    metadata:
      labels:
        app: kube-monkey
    spec:
      serviceAccount: deployment-controller
      containers:
        - name: kube-monkey
          command:
            - "/kube-monkey"
          args: ["-v=5", "-log_dir=/var/log/kube-monkey"]
          image: nokkie/kube-monkey:v0.3.1
          volumeMounts:
            - name: config-volume
              mountPath: "/etc/kube-monkey"
      volumes:
        - name: config-volume
          configMap:
            name: km-config

Eenmaal ingesteld, kan de deployment uitgevoerd worden.

$ kubectl apply -f km-configmap.yml
$ kubectl apply -f km-deploy.yml

Nadat de pod ready is kan de log bekeken worden en aangezien we immediate beginnen met pods killen, zal de log dat weergeven met:

********** Today's schedule **********
k8 Api Kind   Kind Name  Termination Time
-----------   ---------  ----------------
v1.Deployment php-apache 06/23/2020 20:08:04 +0200 CEST
v1.Deployment wordpress  06/23/2020 20:08:14 +0200 CEST
********** End of schedule **********

Indien nu de optie debug uitgezet wordt en dry_run op false zal vanaf 08:00 de scheduler actief zijn.

1 kubemonkey.go:24] Status Update: Generating next schedule at 2020-06-24 08:00:00 +0200 CEST

Welke pods zijn kandidaat om herstart te worden?

Een pod dient een aantal labels te hebben om kandidaat te zijn voor Kube-Monkey. Voor de deployment gelden daarvoor de volgende labels:

labels:
  kube-monkey/enabled: enabled
  kube-monkey/identifier: monkey-victim
  kube-monkey/kill-mode: fixed
  kube-monkey/kill-value: "1"
  kube-monkey/mtbf: "2"

Voor de containers gelden de volgende labels:

labels:
  kube-monkey/enabled: enabled
  kube-monkey/identifier: monkey-victim

De ‘identifier‘ zoekt de containers met deze waarde. Indien gevonden dan is dit een kandidaat voor herstart.

Om niet telkens dezelfde pods te herstarten is en een ‘Mean Time Between Failure‘, (mtbf) het aantal dagen dat tussen de herstarts van pods moet zitten in deze deployment.

De ‘kill-value‘ geeft aan hoeveel pods er in deze deployment herstart moeten gaan worden. De ‘kill-mode‘ geeft aan of het een vaste waarde moet zijn of een percentage.

Kube Monkey is een tool om de doelstelling van Kubernetes te onderschrijven, namelijk het opnieuw instellen van pods met hun containers, ‘on the fly‘, wanneer Kubernetes vaststeld dat dit nodig is. Indien de applicaties daarop gemaakt zijn, is met deze tool wellicht mede aan te tonen dat de omgeving ‘productierijp‘ is!