6 bug-uri sistemice interesante în exploatarea Kubernetes [și soluțiile lor]

De-a lungul anilor de utilizare a Kubernetes în producție, am adunat multe povești interesante despre cum bug-urile din diferite componente sistemice au dus la consecințe neplăcute și/sau neclare, afectând funcționarea containerelor și a pod-urilor. În acest articol, am realizat o selecție a unora dintre cele mai frecvente sau interesante dintre ele. Chiar dacă nu veți avea vreodată ghinionul de a vă confrunta cu astfel de situații, citirea unor astfel de mici investigații — și mai ales, „din prima mână” — este întotdeauna captivantă, nu-i așa?

Povestea 1. Supercronic și Docker blocat

Pe unul dintre clustere, am avut periodic un Docker „blocat”, ceea ce afecta funcționarea normală a clusterului. În logurile Docker apare următoarea eroare:

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

…

Ceea ce ne interesează cel mai mult în această eroare este mesajul: pthread_create failed: No space left on device. O examinare rapidă documentation a explicat că Docker nu poate fork-ui un proces, ceea ce a dus periodic la „blocarea” acestuia.

Monitorizarea a arătat următoarea imagine:

O situație similară se observă și pe alte noduri:

Pe aceleași noduri vedem:

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]

S-a constatat că acest comportament este o consecință a funcționării pod-ului cu supercronic (un utilitar în Go pe care îl folosim pentru a rula sarcini cron în pod-uri):

 _ 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] 
…

Problema este următoarea: atunci când sarcina este lansată în supercronic, procesul generat de acesta, nu se poate încheia corect, transformându-se în zombi.

Notă: Mai precis, procesele sunt generate de sarcinile cron, însă supercronic nu este un sistem init și nu poate „adopta” procesele pe care le-a generat. În cazul semnalelor SIGHUP sau SIGTERM, acestea nu sunt transmise proceselor generate, rezultând că procesele fiice nu se încheie, rămânând în statut de zombi. Mai multe informații despre acest subiect pot fi citite, de exemplu, în un astfel de articol.

Există câteva modalități de a rezolva problemele:

1. Ca o soluție temporară — creșterea numărului de PID-uri în sistem într-un singur moment:

          /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. Sau să efectuezi lansarea sarcinilor în supercronic nu direct, ci cu ajutorul aceluiași tini, care poate încheia corect procesele și nu generează zombi.

Povestea 2. „Zombii” la ștergerea cgroup

Kubelet a început să consume o cantitate mare de CPU:

Acest lucru nu va fi plăcut nimănui, așa că ne-am înarmat perf și am început să ne ocupăm de problemă. Rezultatele investigației au fost următoarele:

• Kubelet cheltuiește mai mult de o treime din timpul procesorului pe extragerea datelor despre memorie din toate cgroup-urile:

  

• În lista de corespondență a dezvoltatorilor nucleului se poate găsi discuția problemei. În scurt, esența se reduce la faptul că diferite fișiere tmpfs și alte lucruri similare nu sunt complet șterse din sistem atunci când se șterg cgroup-urile — rămân așa-numitele memcg zombi. În cele din urmă, acestea vor fi șterse din page cache, totuși există multă memorie pe server și nucleul nu vede sensul de a pierde timp pentru a le șterge. De aceea, acestea continuă să se acumuleze. De ce se întâmplă acest lucru? Este un server cu sarcini cron care creează în mod constant noi joburi, iar împreună cu ele — noi poduri. Astfel, pentru containere se creează noi cgroup-uri, care sunt șterse în curând.
• De ce cAdvisor în kubelet consumă atât de mult timp? Este ușor de văzut printr-o execuție simplă. time cat /sys/fs/cgroup/memory/memory.stat. Dacă pe o mașină sănătoasă operația durează 0,01 secunde, pe proasta cron02 — 1,2 secunde. Totul se datorează faptului că cAdvisor, care citește foarte lent datele din sysfs, încearcă să țină cont de memoria utilizată și de cgroup-urile zombificate.
• Pentru a forța ștergerea zombiilor, am încercat să curățăm cache-urile, așa cum era recomandat în LKML: sync; echo 3 > /proc/sys/vm/drop_caches, — dar nucleul s-a dovedit a fi mai complicat și a blocat mașina.

Ce să facem? Problema se corectează (commit, iar descrierea se găsește în notificarea de lansare) actualizând nucleul Linux la versiunea 4.16.

Povestea 3. Systemd și mount-ul său

Din nou kubelet consumă prea multe resurse pe unele noduri, dar de data aceasta — deja memorie:

S-a dovedit că există o problemă în systemd, utilizat în Ubuntu 16.04, și apare atunci când se gestionează mount-urile care sunt create pentru conectarea subPath din ConfigMap-uri sau secrete. După ce pod-ul și-a terminat executarea, serviciul systemd și mount-ul său auxiliar rămân în sistem. De-a lungul timpului, se acumulează o cantitate enormă. Pe această temă există chiar și probleme:

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

… în ultima dintre care se face referire la PR în systemd: #7811 (problema în systemd — #7798).

Problema nu mai există în Ubuntu 18.04, dar dacă doriți să continuați să utilizați Ubuntu 16.04, s-ar putea să vă fie utilă soluția noastră de workaround pe această temă.

Așadar, am creat următorul DaemonSet:

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

… și acesta folosește următorul script:

#!/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

… și se lansează la fiecare 5 minute folosind supercronic menționat anterior. Fișierul său Docker arată așa:

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

Povestea 4. Concurența în programarea pod-urilor

S-a observat că: dacă un pod este plasat pe un nod și imaginea sa este descărcată foarte lent, atunci un alt pod care a „aterizat” pe același nod pur și simplu nu începe să descarce imaginea noului pod.În schimb, el așteaptă ca imaginea precedentului pod să se descarce. Ca urmare, pod-ul care a fost deja planificat și imaginea căruia ar fi putut fi descărcată în doar un minut va rămâne într-o stare de containerCreating.

În evenimente, va apărea aproximativ următoarea situație:

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

Deci, rezultă că o singură imagine dintr-un registry lent poate bloca deploy-ul pe nod.

Din păcate, soluțiile nu sunt prea multe:

1. Încercați să utilizați propriul Docker Registry direct în cluster sau direct cu clusterul (de exemplu, GitLab Registry, Nexus etc.);
2. Folosiți utilitare precum kraken.

Povestea 5. Înghețarea nodurilor din cauza lipsei de memorie

De-a lungul utilizării diferitelor aplicații, am întâlnit și situații în care nodul devine complet inaccesibil: nu răspunde la SSH, toate demonii de monitorizare se deconectează, iar în jurnale nu există (sau aproape niciun) mesaj anormal.

Voi ilustra cu imagini exemplul unui nod în care a funcționat MongoDB.

Iată cum arată atop la accidente:

Și așa arată — după accidente:

În monitorizare, de asemenea, se observă o creștere bruscă, în care nodul devine inaccesibil:

Astfel, din capturile de ecran se poate observa că:

1. Memoria RAM a mașinii este aproape de limită;
2. Se observă o creștere bruscă a consumului de memorie RAM, după care accesul la întreaga mașină se deconectează brusc;
3. Pe Mongo ajunge o sarcină mare, care determină procesul SGBD să folosească mai multă memorie și să citească activ de pe disc.

Se dovedește că, dacă în Linux se termină memoria liberă (apare presiunea de memorie) și nu există swap, atunci la venirea OOM killer-ului poate duce la un echilibru între introducerea paginilor în cache-ul de pagină și readucerea lor pe disc. Aceasta este gestionată de kswapd, care eliberează cu curaj cât mai multe pagini de memorie pentru o distribuire ulterioară.

Din păcate, în condiții de mare încărcare a sistemului I/O, împreună cu un nivel mic de memorie liberă, kswapd devine gâtul de sticlă al întregului sistem, deoarece pe el se bazează tot alocările (page faults) paginilor de memorie din sistem. Acest lucru poate dura foarte mult dacă procesele nu vor dori să folosească mai multă memorie și se vor bloca la marginea prăpastiei OOM-killer.

Este o întrebare legitimă: de ce OOM killer vine atât de târziu? În iterația sa actuală, OOM killer este extrem de prost: el va distruge un proces doar atunci când o încercare de alocare a unei pagini de memorie eșuează, adică dacă page fault-ul trece cu o eroare. Acest lucru nu se întâmplă de mult timp, deoarece kswapd eliberează cu curaj paginile de memorie, resetând cache-ul paginilor (toată I/O-ul pe disc din sistem, de fapt) înapoi pe disc. Mai multe detalii, cu pașii necesari pentru a rezolva probleme similare în kernel, pot fi citite aici.

Această comportare ar trebui să se îmbunătățească începând cu kernelul Linux 4.6+.

Istoria 6. Pod’urile rămân în stare Pending

În unele clustere, în care funcționează un număr cu adevărat mare de pod-uri, am început să observăm că majoritatea lor rămân foarte mult timp în stare Pending, deși containerele Docker sunt deja pornite pe noduri și pot fi gestionate manual.

Însă în describe nu este nimic rău:

  Tip    Motiv                  Vârstă                Din                       Mesaj
  ----    ------                  ----                ----                       -------
  Normal  Programat              1m                 default-scheduler        A fost alocat cu succes sphinx-0 pe ss-dev-kub07
  Normal  Atașare volum reușită   1m                 attachdetach-controller  AtașareVolume.Attach a reușit pentru volum "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Montare volum reușită   1m                 kubelet, ss-dev-kub07    MontareVolume.SetUp a reușit pentru volum "sphinx-config"
  Normal  Montare volum reușită   1m                 kubelet, ss-dev-kub07    MontareVolume.SetUp a reușit pentru volum "default-token-fzcsf"
  Normal  Montare volum reușită   49s (x2 pe parcurs de 51s)  kubelet, ss-dev-kub07    MontareVolume.SetUp a reușit pentru volum "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Traseu                  43s                kubelet, ss-dev-kub07    Imaginea containerului "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" este deja prezentă pe mașină
  Normal  Creat                  43s                kubelet, ss-dev-kub07    A fost creat containerul
  Normal  Pornit                 43s                kubelet, ss-dev-kub07    Containerul a fost pornit
  Normal  Traseu                  43s                kubelet, ss-dev-kub07    Imaginea containerului "registry.example.com/infra/sphinx/sphinx:v1" este deja prezentă pe mașină
  Normal  Creat                  42s                kubelet, ss-dev-kub07    A fost creat containerul
  Normal  Pornit                 42s                kubelet, ss-dev-kub07    Containerul a fost pornit

După ce am investigat, am formulat ipoteza că kubelet pur și simplu nu reușește să trimită serverului API toate informațiile despre starea pod-urilor, probele de liveness/readiness.

Și, după ce am studiat ajutorul, am găsit următoarele parametrii:

--kube-api-qps - QPS utilizat în comunicarea cu serverul API Kubernetes (implicit 5)
--kube-api-burst  - Răbufnire utilizată în comunicarea cu serverul API Kubernetes (implicit 10) 
--event-qps - Dacă > 0, limitează crearea de evenimente pe secundă la această valoare. Dacă 0, nelimitat. (implicit 5)
--event-burst - Dimensiunea maximă a înregistrărilor de evenimente efervescente, permite temporar înregistrările de evenimente să ajungă la acest număr, fără a depăși event-qps. Se folosește doar dacă --event-qps > 0 (implicit 10) 
--registry-qps - Dacă > 0, limitează QPS-ul de extragere din registru la această valoare.
--registry-burst - Dimensiunea maximă a extragerilor efervescente, permite temporar extragerile să ajungă la acest număr, fără a depăși registry-qps. Se folosește doar dacă --registry-qps > 0 (implicit 10)

As you can see, valorile implicite sunt destul de mici, și în 90 % din cazuri acoperă toate nevoile… Totuși, în cazul nostru s-a dovedit a fi insuficient. Așa că am setat următoarele valori:

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

… și am repornit kubelet-urile, după care am văzut următoarea imagine pe graficele de acces la serverul API:

… și da, totul a început să funcționeze perfect!

P.S.

Doresc să îmi exprim recunoștința față de numeroșii ingineri ai companiei noastre pentru ajutorul acordat în colectarea bug-urilor și pregătirea articolului, în special colegului meu din echipa noastră R&D, Andrei Klimentiev (zuzzas).

P.P.S.

Citiți și în blogul nostru:

• «Pluginul kubectl-debug pentru debugging în pod-urile Kubernetes».
• Ciclul de sfaturi și trucuri Kubernetes:
  • «Migrarea resurselor funcționale în cluster sub gestionarea Helm 2»;
  • «Despre noduri dedicate și despre încărcările aplicației web»;
  • «Acces la medii dev»;
  • «Accelerăm bootstrapping-ul bazelor de date mari».

Sursa: habr.com