6 huvitavat süsteemi tõrget Kubernetes'e kasutamise käigus [ja nende lahendamine]

Aastate jooksul, mil me oleme Kubernetes't tootmises kasutanud, on meil kogunenud palju huvitavaid lugusid, kuidas erinevate süsteemikomponentide vead on toonud kaasa ebameeldivaid ja/või arusaamatuid tagajärgi konteinerite ja pod'ide töös. Selles artiklis oleme välja valinud mõned kõige sagedamad või huvitavamad neist. Isegi kui te kunagi ei satuks selliste olukordadega kokku, on selliste lühikeste detektiivlugude lugemine - eriti «esmakäeliselt» - alati huvitav, eks ole?...

Lugu 1. Supercronic ja kinni jäänud Docker

Ühel meie klastritest said me aeg-ajalt «kinni jäänud» Dockerit, mis takistas klastrite normaalset toimimist. Samal ajal oli Docker'i logides järgmine teade

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

…

Selles veas huvitab meid enim sõnum: pthread_create failed: No space left on device. Kiire ülevaade dokumentatsioonis selgitas, et Docker ei suuda protsessi forkida, mistõttu see aeg-ajalt "hangub".

Jälgitavale vastab järgmine pilt:

Sarnast olukorda täheldatakse ka teistel sõlmedel:

Näeme samadel sõlmedel:

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]

Selgus, et selline käitumine on pod'i töö tagajärg, supercronic (Go utiliit, mida kasutame cron-ülesannete käivitamiseks pod'ides):

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

Probleem on järgmine: kui ülesanne käivitub supercronic'is, siis sellele järgnev protsess ei saa korrektselt lõpetada, muutudes zombiks.

Märkus: Täpsemalt öeldes, protsessid tekivad cron-ülesannetest, kuid supercronic ei ole init-süsteem ja ei saa „kasvatada” protsesse, mille ta on sünnitanud. Kui ilmnevad SIGHUP või SIGTERM signaalid, ei edastata neid loodud protsessidele, mistõttu allprotsessid ei lõpeta tegevust ja jäävad zombistaatusesse. Selle kohta saab rohkem lugeda näiteks sellest artiklist.

Probleemide lahendamiseks on paar võimalust:

1. Ajutise lahendusena — suurendada süsteemi PID'ide arvu korraga:

          /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. Või käivitada ülesanded supercronicis mitte otse, vaid sama tini, mis suudab protsesse õigesti lõpetada ja ei tekita zombie'id.

Lugu 2. «Zombid» cgroup'i eemaldamisel

Kubelet hakkas kasutama suurt hulka CPU-d:

Sellest ei saa keegi vaimustuda, seega varustasime end perf ja hakkasime probleemi uurima. Uurimise tulemused olid järgmised:

• Kubelet kulutab üle kolmandiku protsessoriajast, et tõmmata mäluandmeid kõigist cgroup'idest:

  

• Kernal arendajate postitusse saab leida probleemi arutelu. Ütlemata lühidalt, seisneb asi selles, et erinevad tmpfs-failid ja teised sarnased asjad ei kustutata süsteemist täielikult cgroup'i eemaldamisel — jäävad ellu nn memcg zombid. Varakult või hiljem nad siiski kustutatakse page cache'ist, kuid serveris on palju mälu ja tuuma ei näe vajadust nende kustutamiseks aega raisata. Seetõttu nad jätkavad kogunemist. Miks see üldse juhtub? See on server cron-töödega, mis pidevalt loob uusi tööülesandeid ja nendega – uusi pod'e. Nii luuakse konteineritele uusi cgroup'e, mis peagi kustutatakse.
• Miks cAdvisor kubelet'is kulutab nii palju aega? Seda on kerge näha järgmise lihtsa käsu täitmisega time cat /sys/fs/cgroup/memory/memory.stat. Kui terves masinas võtab operatsioon 0,01 sekundit, siis probleemses cron02-s – 1,2 sekundit. Kõik on selles, et cAdvisor loeb andmeid sysf'st väga aeglaselt ja püüab arvesse võtta kasutatud mälu zombie cgroup'ides.
• Et sunniviisiliselt eemaldada zombi, proovisime puhastada vahemälu, nagu soovitati LKML-is: sync; echo 3 > /proc/sys/vm/drop_caches, – kuid kernel osutus keerulisemaks ja hangestas masina.

Mida siis teha? Probleem lahendatakse (kommitt, ning kirjeldust vaata väljaande teates) uuendades Linuxi tuuma versioonile 4.16.

Lugu 3. Systemd ja selle mount

Jällegi kubelet tarbib liiga palju ressursse mõnel sõlmel, kuid seekord – juba mälu:

Tuvastati, et Ubuntu 16.04-s kasutatavas systemd-s on probleem, mis ilmneb mount’ide haldamisel, mis luuakse ConfigMap’ide või secret’ite ühendamiseks. subPath Pärast pod’i lõpetamist jääb systemd teenus ja selle teenuse mount süsteemi. Aja jooksul koguneb neid tohutult palju. Selle kohta on isegi küsimusi:

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

… viidates viimases PR-le systemd-s: #7811 (issue systemd-s — #7798).

Probleemi ei ole enam Ubuntu 18.04-s, kuid kui soovite jätkuvalt kasutada Ubuntu 16.04, võib meie töö ümber selle olla teile kasulik.

Nii et koostasime järgmise DaemonSeti:

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

… ja seda kasutatakse sellise skripti jaoks:

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

… ja seda käivitatakse iga 5 minuti järel juba varem mainitud supercronic abil. Selle Dockerfile näeb välja järgmiselt:

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

Lugu 4. Konkurents pod’ide planeerimisel

On märgatud, et: kui meil on node’is pod ja selle pilt allalaadimine kestab väga kaua, siis teine pod, mis sattus samale node’ile, lihtsalt ei alusta uue pod’i pilti allalaadimist. Selle asemel ootab ta, kuni eelmise pod’i pilt on allalaaditud. Tulemuseks on see, et pod, mis on juba planeeritud ja mille pilt saaks alla laadida vaid minutiga, jääb pikaks ajaks staatusesse containerCreating.

Event’ides on enam-vähem järgmist:

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

Selgub, et ainus halb pilt aeglasest registrist võib blokeerida juurutuse node’ile.

Kahjuks ei ole olukorrast väljapääse palju:

1. Püüdke kasutada oma Docker Registry otse klastris või otse koos klastriga (näiteks GitLab Registry, Nexus jne);
2. Kasutage selliseid utiliite nagu kraken.

Lugu 5. Sõlmede seiskumine mälupuudusel

Erinevate rakenduste kasutamise ajal oleme samuti kogenud olukordi, kus sõlm ei ole enam kergesti ligipääsetav: SSH ei vasta, kõik jälgimise deemonid kukuvad välja ja logides ei ole seejuures midagi (või peaaegu mitte midagi) anomaalset.

Taas jutustan piltide näitel ühest sõlmest, kus töötas MongoDB.

Nii näeb atop välja kuni õnnetused:

Ja nii — pärast õnnetused:

Jälgimises on samuti näha järsk tõus, mille käigus sõlm lõpetab ligipääsu:

Nii et ekraanipiltidest on näha, et:

1. Mälu masinas on peaaegu lõppemas;
2. Tõuseb järsk mälu tarbimise tõus, pärast mida katkeb juurdepääs kogu masinale;
3. Mongo'de saab suur ülesanne, mis sunnib andmebaasi protsessi kasutama rohkem mälu ja aktiivselt lugema kettalt.

Selgub, et kui Linuxis lõpeb vaba mälu (tekib memory pressure) ja swap'i ei ole, siis kuni OOM killer'i saabumisel võib leida tasakaalu lehtede juhuslikus hoidmisel vahemälus ja nende tagasi kirjutamisel kettale. Sellega tegeleb kswapd, kes piiritletult vabastab võimalikult palju mälu lehti edasiseks jaotamiseks.

Kahjuks, kui sisend/väljund on suure koormuse all koos väikese vaba mäluhulga, muutub kswapd kogu süsteemi kitsaskohaks, kuna sellele toetuvad kõik mälu lehtede jaotused (page faults) süsteemis. See võib kesta väga kaua, kui protsessid ei soovi enam mälu kasutada ja jäävad OOM-killer'i äärele.

On loomulik küsimus: miks OOM killer tuleb nii hilja? Oma praeguses iteratsioonis on OOM killer äärmiselt rumal: ta lõpetab protsessi ainult siis, kui mälu lehe jaotamine ebaõnnestub, st kui page fault lõppeb veaga. Seda ei juhtu piisavalt kaua, kuna kswapd piiritletult vabastab mälu lehti, kirjutades page cache (sisuliselt kogu süsteemi ketta I/O) tagasi kettale. Täiendavat teavet koos sammudega, mis on vajalikud sarnaste probleemide lahendamiseks kernelis, leiate siit.

See käitumine peab paranema Linux 4.6+ tuumaga.

Ajalugu 6. Pod'id ripuvad ooteolekus

Mõnedes klastrites, kus töötab tõeliselt palju pod'e, oleme hakanud tähele panema, et suur osa neist jääb pikaks ajaks "ripakile" Ootel, kuigi Docker-konteinerid on juba sõlmedes käivitatud ja nendega saab käsitsi töötada.

Samas, describe sellest pole midagi halba:

  Tüüp    Põhjendus               Vanus               From                     Sõnum
  ----    ------                  ----               ----                     -------
  Tavaline  Planeeritud            1m                 default-scheduler        Sphinx-0 on edukalt määratud ss-dev-kub07-le
  Tavaline  Mahutamine edukalt     1m                 attachdetach-controller  AttachVolume.Attach õnnestus mahuti "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" jaoks
  Tavaline  Mahutamine edukalt     1m                 kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "sphinx-config" jaoks
  Tavaline  Mahutamine edukalt     1m                 kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "default-token-fzcsf" jaoks
  Tavaline  Mahutamine edukalt     49s (x2 51s jooksul) kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" jaoks
  Tavaline  Tõmmatud               43s                kubelet, ss-dev-kub07    Mahuti pilt "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" on masinas juba olemas
  Tavaline  Loome                  43s                kubelet, ss-dev-kub07    Loome konteineri
  Tavaline  Alustas               43s                kubelet, ss-dev-kub07    Alustas konteinerit
  Tavaline  Tõmmatud               43s                kubelet, ss-dev-kub07    Mahuti pilt "registry.example.com/infra/sphinx/sphinx:v1" on masinas juba olemas
  Tavaline  Loome                  42s                kubelet, ss-dev-kub07    Loome konteineri
  Tavaline  Alustas               42s                kubelet, ss-dev-kub07    Alustas konteinerit

Uurides jõudsime järeldusele, et kubelet lihtsalt ei jõua edastada API-serverile kogu teavet pod’ide, elujõudluse/readiness-proovide kohta.

Ja uurides abimaterjale, leidsime järgmised parameetrid:

--kube-api-qps - QPS, mida kasutatakse Kubernetes apiserveriga suhtlemiseks (vaikimisi 5)
--kube-api-burst - Burst, mida kasutatakse Kubernetes apiserveriga suhtlemiseks (vaikimisi 10) 
--event-qps - Kui > 0, piira sündmuste loomist sekundis sellele väärtusele. Kui 0, on piirang puudub. (vaikimisi 5)
--event-burst - Maksimaalne suurus äkiliste sündmuste rekordite jaoks, mis ajutiselt lubab sündmuste rekorditel ulatuda sellesse numbrisse, ületamata siiski event-qps-i. Kasutatakse ainult siis, kui --event-qps > 0 (vaikimisi 10) 
--registry-qps - Kui > 0, piira registri tõmbamise QPS sellele väärtusele.
--registry-burst - Maksimaalne suurus äkiliste tõmbamiste jaoks, mis ajutiselt lubab tõmbamisi ulatuda sellesse numbrisse, ületamata siiski registry-qps-i. Kasutatakse ainult siis, kui --registry-qps > 0 (vaikimisi 10)

Nagu näha, vaikimisi väärtused - üsna väikesed, ja 90% neist katab kõik vajadused… Siiski, meie puhul osutus see liiga väikeseks. Seetõttu seadsime järgmised väärtused:

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

… ja taaskäivitame kubelet’id, pärast mida nägime API-serveri kõnede graafikutel järgmist pilti:

… ja jah, kõik hakkas toimima!

P.S.

Aitäh kõigile ettevõtte inseneridele vigade kogumise ja artikli ettevalmistamise eest, eriti meie R&D meeskonna kolleegile Andreile Klimentjevile (zuzzas).

P.P.S.

Lugege ka meie blogist:

• «kubectl-debug plugina abil Kuberneteses pod'ide tõrkeotsimiseks».
• Kubernetesi näpunäidete ja nippe tsükkel:
  • «Klastrites töötavate ressursside üleviimine Helm 2 haldusse»;
  • «Sõlmede eraldamine ja koormused veebirakendusele»;
  • «Ju access dev-platvormidele»;
  • «Suure andmebaasi bootstrap'i kiirendamine».

Allikas: habr.com