6 interessante systematische Fehler bei der Nutzung von Kubernetes [und deren Lösung]

Im Laufe der Jahre, in denen wir Kubernetes in der Produktion eingesetzt haben, haben wir viele interessante Geschichten gesammelt, wie Bugs in verschiedenen Systemkomponenten zu unangenehmen und/oder unverständlichen Konsequenzen führten, die die Funktionsweise von Containern und Pods beeinflussten. In diesem Artikel haben wir eine Sammlung einiger der häufigsten oder interessantesten Geschichten zusammengestellt. Selbst wenn Sie nie das Glück haben sollten, mit solchen Situationen konfrontiert zu werden, ist es immer interessant, über solche kurzen Detektive zu lesen – besonders "aus erster Hand", nicht wahr? ..

Geschichte 1. Supercronic und hängender Docker

In einem unserer Cluster hatten wir gelegentlich "hängenden" Docker, was die normale Funktion des Clusters beeinträchtigte. In den Docker-Logs konnten wir Folgendes beobachten:

level=error msg="containerd: start init process" error="exit status 2: "runtime/cgo: pthread_create failed: No space left on device
SIGABRT: abort
PC=0x7f31b811a428 m=0

goroutine 0 [idle]:

goroutine 1 [running]:
runtime.systemstack_switch() /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420026768 sp=0xc420026760
runtime.main() /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200267c0 sp=0xc420026768
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200267c8 sp=0xc4200267c0

goroutine 17 [syscall, locked to thread]:
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1

…

An dieser Fehlermeldung interessiert uns am meisten die Mitteilung: pthread_create failed: No space left on device. Eine flüchtige Untersuchung Dokumentation zeigte, dass Docker den Prozess nicht abzweigen kann, weshalb er gelegentlich "hängengeblieben" ist.

In der Überwachung ergibt sich folgendes Bild:

Eine ähnliche Situation zeigt sich auch auf anderen Knoten:

Auf diesen Knoten sehen wir:

root@kube-node-1 ~ # ps auxfww | grep curl -c
19782
root@kube-node-1 ~ # ps auxfww | grep curl | head
root     16688  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     17398  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     16852  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      9473  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      4664  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     30571  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     24113  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     16475  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      7176  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      1090  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl]

Es stellte sich heraus, dass dieses Verhalten die Folge der Arbeit des Pods mit supercronic (einem Go-Tool, das wir zum Ausführen von Cron-Jobs in Pods verwenden) ist.

 _ docker-containerd-shim 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 /var/run/docker/libcontainerd/833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 docker-runc
|   _ /usr/local/bin/supercronic -json /crontabs/cron
|       _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true
|       |   _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true -no-pidfile
|       _ [newrelic-daemon] 
|       _ [curl] 
|       _ [curl] 
|       _ [curl] 
|       _ [curl] 
…

Das Problem ist folgendes: Wenn die Aufgabe in supercronic gestartet wird, kann der von ihm erzeugte Prozess nicht korrekt beendet werden, wodurch er sich in ein Zombie verwandelt.

Hinweis: Genauer gesagt werden Prozesse von cron-Aufgaben erzeugt, aber supercronic ist kein Init-System und kann die Prozesse, die seine Kinder erzeugt haben, nicht „adoptieren“. Bei Auftreten von SIGHUP- oder SIGTERM-Signalen werden diese nicht an die erzeugten Prozesse weitergegeben, sodass die untergeordneten Prozesse nicht beendet werden und im Zombie-Status verbleiben. Mehr dazu kann man beispielsweise in diesem Artikel nachlesen.

Es gibt ein paar Ansätze zur Problemlösung:

1. Als temporären Workaround — die Anzahl der PIDs im System zu einem bestimmten Zeitpunkt zu erhöhen:

          /proc/sys/kernel/pid_max (since Linux 2.5.34)
                 This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID).  PIDs greater than this  value  are  not  allo‐
                 cated;  thus, the value in this file also acts as a system-wide limit on the total number of processes and threads.  The default value for this file, 32768, results in the
                 same range of PIDs as on earlier kernels

2. Oder die Aufgaben in supercronic nicht direkt, sondern mit Hilfe von tini, das in der Lage ist, Prozesse korrekt zu beenden und keine Zombies zu erzeugen.

Geschichte 2. „Zombies“ beim Löschen der cgroup

Kubelet begann, viel CPU zu verbrauchen:

Das wird niemandem gefallen, also haben wir uns gerüstet perf und uns mit dem Problem beschäftigt. Die Ergebnisse der Untersuchung waren folgende:

• Kubelet verbraucht mehr als ein Drittel der CPU-Zeit für das Abrufen von Speicherdaten aus allen cgroups:

  

• In der Mailingliste der Kernel-Entwickler findet man eine Diskussion über das Problem. Kurz gesagt, der Kern des Problems liegt darin, dass verschiedene tmpfs-Dateien und andere ähnliche Dinge nicht vollständig aus dem System entfernt werden bei der Löschung der cgroup — es bleiben so genannte memcg Zombies.Früher oder später werden sie aus dem Page-Cache gelöscht, doch der Server hat viel Speicher, und das Kern sieht keinen Sinn darin, Zeit mit ihrer Löschung zu verschwenden. Deshalb sammeln sie sich weiter an. Warum passiert das überhaupt? Es handelt sich um einen Server mit Cron-Jobs, der ständig neue Jobs erstellt, und damit auch neue Pods. So werden für die Container neue cgroups erstellt, die bald wieder gelöscht werden.
• Warum benötigt cAdvisor in kubelet so viel Zeit? Das lässt sich leicht mit dem einfachsten Befehl erkennen: time cat /sys/fs/cgroup/memory/memory.stat. Wenn auf einem gesunden System die Operation 0,01 Sekunden dauert, sind es auf dem problematischen cron02 bereits 1,2 Sekunden. Das Problem ist, dass cAdvisor, das sehr langsam Daten aus sysfs liest, versucht, den verwendeten Speicher und auch in Zombie-cgroups zu berücksichtigen.
• Um die Zombies gewaltsam zu entfernen, haben wir versucht, den Cache zu leeren, wie es in LKML empfohlen wird: sync; echo 3 > /proc/sys/vm/drop_caches, — aber das Kernel war komplizierter und hat die Maschine zum Absturz gebracht.

Was ist zu tun? Das Problem wird behoben (Commits, die Beschreibung finden Sie in der Release-Notiz) durch ein Update des Linux-Kernels auf Version 4.16.

Geschichte 3. Systemd und sein Mount

Wieder verbraucht kubelet zu viele Ressourcen auf einigen Knoten, diesmal — bereits Speicher:

Es stellte sich heraus, dass es ein Problem mit systemd in Ubuntu 16.04 gibt, das auftritt, wenn es um die Verwaltung von Mounts geht, die zur Anbindung subPath aus ConfigMaps oder Secrets erstellt werden. Nach dem Abschluss des Pods bleibt der Systemd-Dienst und sein Hilfs-Mount im System. Mit der Zeit sammeln sich davon enorme Mengen an. Zu diesem Thema gibt es sogar Issues:

1. kops #5916;
2. kubernetes #57345.

… auf die im letzten verwiesen wird, auf PR in systemd: #7811 (Issue in systemd — #7798).

Das Problem besteht nicht mehr in Ubuntu 18.04, aber wenn Sie weiterhin Ubuntu 16.04 verwenden möchten, könnte unser Workaround zu diesem Thema hilfreich sein.

Also haben wir den folgenden DaemonSet erstellt:

---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  labels:
    app: systemd-slices-cleaner
  name: systemd-slices-cleaner
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: systemd-slices-cleaner
  template:
    metadata:
      labels:
        app: systemd-slices-cleaner
    spec:
      containers:
      - command:
        - /usr/local/bin/supercronic
        - -json
        - /app/crontab
        Image: private-registry.org/systemd-slices-cleaner/systemd-slices-cleaner:v0.1.0
        imagePullPolicy: Always
        name: systemd-slices-cleaner
        resources: {}
        securityContext:
          privileged: true
        volumeMounts:
        - name: systemd
          mountPath: /run/systemd/private
        - name: docker
          mountPath: /run/docker.sock
        - name: systemd-etc
          mountPath: /etc/systemd
        - name: systemd-run
          mountPath: /run/systemd/system/
        - name: lsb-release
          mountPath: /etc/lsb-release-host
      imagePullSecrets:
      - name: antiopa-registry
      priorityClassName: cluster-low
      tolerations:
      - operator: Exists
      volumes:
      - name: systemd
        hostPath:
          path: /run/systemd/private
      - name: docker
        hostPath:
          path: /run/docker.sock
      - name: systemd-etc
        hostPath:
          path: /etc/systemd
      - name: systemd-run
        hostPath:
          path: /run/systemd/system/
      - name: lsb-release
        hostPath:
          path: /etc/lsb-release

… und darin wird folgendes Skript verwendet:

#!/bin/bash

# we will work only on xenial
hostrelease="/etc/lsb-release-host"
test -f ${hostrelease} && grep xenial ${hostrelease} > /dev/null || exit 0

# sleeping max 30 minutes to dispense load on kube-nodes
sleep $((RANDOM % 1800))

stoppedCount=0
# counting actual subpath units in systemd
countBefore=$(systemctl list-units | grep subpath | grep "run-" | wc -l)
# let's go check each unit
for unit in $(systemctl list-units | grep subpath | grep "run-" | awk '{print $1}'); do
  # finding description file for unit (to find out docker container, who born this unit)
  DropFile=$(systemctl status ${unit} | grep Drop | awk -F': ' '{print $2}')
  # reading uuid for docker container from description file
  DockerContainerId=$(cat ${DropFile}/50-Description.conf | awk '{print $5}' | cut -d/ -f6)
  # checking container status (running or not)
  checkFlag=$(docker ps | grep -c ${DockerContainerId})
  # if container not running, we will stop unit
  if [[ ${checkFlag} -eq 0 ]]; then
    echo "Stopping unit ${unit}"
    # stoping unit in action
    systemctl stop $unit
    # just counter for logs
    ((stoppedCount++))
    # logging current progress
    echo "Stopped ${stoppedCount} systemd units out of ${countBefore}"
  fi
done

… und es wird alle 5 Minuten mit dem bereits erwähnten supercronic gestartet. Seine Dockerfile sieht folgendermaßen aus:

FROM ubuntu:16.04
COPY rootfs /
WORKDIR /app
RUN apt-get update && 
    apt-get upgrade -y && 
    apt-get install -y gnupg curl apt-transport-https software-properties-common wget
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" && 
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && 
    apt-get update && 
    apt-get install -y docker-ce=17.03.0*
RUN wget https://github.com/aptible/supercronic/releases/download/v0.1.6/supercronic-linux-amd64 -O 
    /usr/local/bin/supercronic && chmod +x /usr/local/bin/supercronic
ENTRYPOINT ["/bin/bash", "-c", " /usr/local/bin/supercronic -json /app/crontab"]

Geschichte 4. Konkurrenz bei der Pod-Planung

Es wurde festgestellt, dass: Wenn wir einen Pod auf einen Knoten platzieren und dessen Image sehr lange heruntergeladen wird, dann wird ein anderer Pod, der "auf" denselben Knoten kommt, einfach nicht beginnen, das Image des neuen Pods herunterzuladen.Stattdessen wartet er, bis das Image des vorherigen Pods heruntergeladen ist. Infolgedessen wird der Pod, der bereits geplant war und dessen Image in nur einer Minute heruntergeladen werden könnte, für längere Zeit im Status containerCreating.

Die Ereignisse werden ungefähr folgendes zeigen:

Normal  Pulling    8m    kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal  pulling image "registry.example.com/infra/openvpn/openvpn:master"

Es stellt sich heraus, dass ein einziges Image aus einem langsamen Register kann die Bereitstellung auf den Knoten blockieren.

Leider gibt es nicht viele Lösungen für dieses Problem:

1. Versuchen Sie, Ihr Docker-Registry direkt im Cluster oder direkt mit dem Cluster zu verwenden (zum Beispiel GitLab-Registry, Nexus usw.);
2. Nutzen Sie Utilities wie kraken.

Geschichte 5. Knoten hängen bei Speichermangel

Im Laufe der Nutzung verschiedener Anwendungen hatten wir auch die Situation, dass ein Knoten vollständig unzugänglich wurde: keine SSH-Antwort, alle Überwachungsdienste fallen aus, und in den Logs gibt es dann nichts (oder fast nichts) Anomalisches.

Ich werde anhand von Bildern an einem Beispiel eines Knotens erzählen, auf dem MongoDB funktionierte.

So sieht atop aus bis Unfälle:

Und so — nach Unfälle:

In der Überwachung zeigt sich auch ein plötzlicher Anstieg, bei dem der Knoten unzugänglich wird:

Somit zeigt sich aus den Screenshots, dass:

1. Der Arbeitsspeicher der Maschine geht zur Neige;
2. Es gibt einen plötzlichen Anstieg des Arbeitsspeicherverbrauchs, wonach der Zugriff auf die gesamte Maschine abrupt abgeschaltet wird;
3. An Mongo wird eine große Aufgabe gestellt, die den DBMS-Prozess dazu zwingt, mehr Speicher zu verwenden und aktiv von der Festplatte zu lesen.

Es stellt sich heraus, dass, wenn unter Linux der freie Speicher ausgeht (memory pressure eintritt) und kein Swap vorhanden ist, bis das Eintreffen des OOM-Killers zu einem Gleichgewicht zwischen dem Einkapseln von Seiten in den Page Cache und dem Zurückschreiben auf die Festplatte führen kann. Damit beschäftigt sich kswapd, das mutig so viele Seiten wie möglich für die spätere Zuteilung freigibt.

Leider wird bei hoher Eingabe/Ausgabe-Last zusammen mit wenig freiem Speicher kswapd zum Flaschenhals des gesamten Systems, weil sich daran Ressourcen) abgeschlossen ist, lösen wir Seitenfehler (page faults) im System festmachen. Das kann sehr lange dauern, wenn Prozesse nicht bereit sind, mehr Speicher zu verwenden, und am Rand des OOM-Killer-Abgrundes verharren.

Die Frage ist berechtigt: Warum kommt der OOM-Killer so spät? In seiner aktuellen Iteration ist der OOM-Killer extrem dumm: Er beendet den Prozess erst, wenn der Versuch, eine Seite Speicher zuzuweisen, fehlschlägt, d.h. wenn der Seitenfehler mit einem Fehler endet. Das geschieht lange nicht, weil kswapd mutig Speicherseiten freigibt, indem es den Page Cache (sie ist im Grunde alle Disk I/O im System) wieder auf die Festplatte zurückschreibt. Detaillierte Informationen mit einer Beschreibung der Schritte, die erforderlich sind, um solche Probleme im Kernel zu beheben, finden Sie hier.

Dieses Verhalten sollte sich verbessern mit dem Kernel Linux 4.6+.

Geschichte 6. Pods hängen im Status Pending

In einigen Clustern, in denen wirklich viele Pods betrieben werden, haben wir begonnen zu bemerken, dass ein Großteil von ihnen sehr lange im Status Pending, obwohl die Docker-Container bereits auf den Knoten gestartet sind und man manuell mit ihnen arbeiten kann.

Dabei ist in describe nichts Schlechtes:

  Type    Reason                  Age                From                     Message
  ----    ------                  ----               ----                     -------
  Normal  Scheduled               1m                 default-scheduler        Erfolgreich sphinx-0 auf ss-dev-kub07 zugewiesen
  Normal  SuccessfulAttachVolume  1m                 attachdetach-controller  AttachVolume.Attach war erfolgreich für Volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp war erfolgreich für Volume "sphinx-config"
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp war erfolgreich für Volume "default-token-fzcsf"
  Normal  SuccessfulMountVolume   49s (x2 über 51s)  kubelet, ss-dev-kub07    MountVolume.SetUp war erfolgreich für Volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Container-Image "registry.example.com/infrа/sphinx-exporter/sphinx-indexer:v1" bereits auf der Maschine vorhanden
  Normal  Created                 43s                kubelet, ss-dev-kub07    Container erstellt
  Normal  Started                 43s                kubelet, ss-dev-kub07    Container gestartet
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Container-Image "registry.example.com/infrа/sphinx/sphinx:v1" bereits auf der Maschine vorhanden
  Normal  Created                 42s                kubelet, ss-dev-kub07    Container erstellt
  Normal  Started                 42s                kubelet, ss-dev-kub07    Container gestartet

Nachdem wir recherchiert haben, haben wir die Vermutung geäußert, dass kubelet einfach nicht schnell genug ist, um dem API-Server alle Informationen über den Status der Pods, liveness/readiness-Probe, zu senden.

Und nachdem wir die Hilfe untersucht haben, fanden wir die folgenden Parameter:

--kube-api-qps - QPS, die beim Sprechen mit dem Kubernetes-Api-Server verwendet werden soll (Standard 5)
--kube-api-burst - Burst, den man beim Sprechen mit dem Kubernetes-Api-Server verwenden kann (Standard 10)
--event-qps - Wenn > 0, die Erstellung von Ereignissen pro Sekunde auf diesen Wert begrenzen. Wenn 0, unbegrenzt. (Standard 5)
--event-burst - Maximale Größe von bursty Ereignisaufzeichnungen, ermöglicht vorübergehend, dass Ereignisaufzeichnungen auf diese Zahl ansteigen, während sie weiterhin event-qps nicht überschreiten. Nur verwendet, wenn --event-qps > 0 (Standard 10)
--registry-qps - Wenn > 0, die QPS beim Registrieren auf diesen Wert begrenzen.
--registry-burst - Maximale Größe der burstigen Downloads, ermöglicht vorübergehend, dass Downloads auf diese Zahl ansteigen, während sie weiterhin registry-qps nicht überschreiten. Nur verwendet, wenn --registry-qps > 0 (Standard 10)

Wie man sieht, sind die Standardwerte recht niedrig, und in 90 % der Fälle decken sie alle Bedürfnisse ab… Allerdings war das in unserem Fall nicht genug. Daher haben wir die folgenden Werte festgelegt:

--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40

… und haben die Kubelets neu gestartet, nach dem wir folgende Grafik der API-Server-Anfragen gesehen haben:

… und ja, alles begann zu fliegen!

P.S.

Ich möchte den zahlreichen Ingenieuren unseres Unternehmens, insbesondere meinem Kollegen aus unserem R&D-Team, Andrej Klimentjew, für die Unterstützung bei der Fehlersammlung und der Vorbereitung des Artikels herzlich danken.zuzzas).

P.P.S.

Lesen Sie auch in unserem Blog:

• «Das kubectl-debug-Plugin zur Fehlersuche in Kubernetes-Pods».
• Kubernetes-Tipps & Tricks:
  • «Migration von in dem Cluster laufenden Ressourcen zu Helm 2»;
  • «Über die Bereitstellung von Knoten und die Lasten auf Webanwendungen»;
  • «Zugriff auf Entwicklungsumgebungen»;
  • «Beschleunigung des Bootstraps großer Datenbanken».

Quelle: habr.com