6 huvitavat süsteemiviga Kubernetes'i kasutamise ajal [ja nende lahendamine]

Kubernetes'i tootmises kasutamise aastate jooksul on meil kogunenud palju huvitavaid lugusid, kuidas erinevate süsteemi komponentide vead on põhjustanud ebameeldivaid ja/või arusaamatuid tagajärgi, mis mõjutavad konteinerite ja pod'ide tööd. Selles artiklis oleme koostanud valiku mõnedest kõige sagedamatest või huvitavamatest neist. Isegi kui te ei pruugi kunagi sattuda sellistesse olukordadesse, on alati huvitav lugeda sellistest lühikesest detektiivides — eriti „esimesest käest“, eks?..

Lugu 1. Supercronic ja külmunud Docker

Ühes meie klastris saime perioodiliselt „külmunud“ Docker, mis häiris klastrite normaalset toimimist. Samas olid Docker'i logides järgmised kirjed

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 kõige rohkem sõnum: pthread_create failed: No space left on device. Kiire ülevaade dokumentatsioon näitas, et Docker ei saa protsessi forkida, mistõttu see aeg-ajalt „külmus”.

Jälgimisel, mis toimus, vastas selline pilt:

Sarnast olukorda täheldati ka teistes sõlmedes:

Nendel samadel sõlmedel näeme:

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, 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 supercronicis, siis protsess, mille see edasi annab, ei suuda õigesti lõpetada, muutudes zombiks.

Märkus: Täpsemalt öeldes, protsessid genereeritakse cron-ülesannetest, kuid supercronic ei ole init-süsteem ja ei suuda "seda lapsendavaid" protsesse, mille tema lastega toimub. Signaalide SIGHUP või SIGTERM korral ei edastata neid edasi genereeritud protsessidele, mille tõttu tütarprotsessid ei lõpetata, jäädes zombistaatusele. Täiendavateks lugemiseks võib näiteks lugeda sellest artiklist.

Sorriteen on mõningaid probleemide lahendamise viise:

1. Ajutise lahendusena - suurendage süsteemis samal ajal PIDde arvu:

          /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 ülesandeid supercronicis mitte otse, vaid sama abil, tini, mis suudab õigesti lõpetada protsesse ja ei genereeri zombisid.

Lugu 2. "Zombid" cgroupi eemaldamisel

Kubelet hakkas tarbima suures koguses CPU-d:

See ei meeldi kellelegi, seega relvasime end perf ja hakkasime probleemiga tegelema. Uurimise tulemused olid järgmised:

• Kubelet kulutab rohkem kui kolmandiku CPU ajast mäluandmete kogumisele kõikidest cgroupidest:

  

• Tuletisede arendajate postil võib leida probleemi arutelu. Lühidalt, sisu seisneb selles, et erinevad tmpfs-failid ja muud sarnased asjad ei eemaldu täielikult süsteemist cgroupi eemaldamisel - jäävad nn memcg zombiks. Aega või hiljem nad siiski kustutatakse page cache'ist, kuid serveris on palju mälu ja tuum ei näe mõtet nende kustutamiseks aega raisata. Seetõttu nad jätkuvalt kuhjuvad. Miks see üldse juhtub? See on server cron-töödega, mis pidevalt loob uusi tööülesandeid ja nendega uusi pod'e. Seega luuakse nende konteinerite jaoks uued cgroup'id, mis varsti kustutatakse.
• Miks cAdvisor kubeleti juures kulutab nii palju aega? Seda on lihtne näha kõige lihtsama teostuse abil time cat /sys/fs/cgroup/memory/memory.stat. Kui tervel masinal see operatsioon kestab 0,01 sekundit, siis probleemse cron02 peal 1,2 sekundit. Asi on selles, et cAdvisor, kes loeb sysfs'ist andmeid väga aeglaselt, proovib arvestada kasutatud mälu ja zombide cgroup'e.
• Kuna me püüdsime zombisid sunniviisiliselt kustutada, siis proovisime puhastada cache'e, nagu soovitati LKML'is: sync; echo 3 > /proc/sys/vm/drop_caches, — aga tuum osutus keerulisemaks ning masin hangus.

Mida siis teha? Probleem lahendatakse (komiteed, ja kirjelduse leiate väljaande teatest) Linuxi tuuma versiooni 4.16 uuendamisega.

Lugu 3. Systemd ja selle mount

Taaskord tarbib kubelet liiga palju ressursse mõnedes sõlmedes, aga seekord juba mälu:

Selgus, et probleem on systemd's, mis on kasutusel Ubuntu 16.04-s, ja see tekib mount'ide haldamisel, mis luuakse ConfigMap'ide või salajaste jaoks. Pärast pod'i lõpetamist , said edasiarendust — uue välja jääb systemd teenus ja selle teenusmount süsteemi. Aja jooksul neid koguneb tohutult. Selle teema kohta on isegi probleeme: kops #5916

1. kubernetes #57345;
2. … viimasest, kus viidatakse PR-ile systemd's:.

(issue systemd's — #7811 Probleem ei esine enam Ubuntu 18.04-s, aga kui soovite endiselt kasutada Ubuntu 16.04, siis võib meie lahendus selle teema jaoks teile ära kuluda. #7798).

Nii et me tegime järgmise DaemonSet'i:

Nii, me oleme loonud järgmise DaemonSet'i:

---
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 kasutatakse sellist skripti:

#!/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 see käivitatakse iga 5 minuti järel juba mainitud supercronic'i abil. Selle Dockerfile näeb välja järgmine:

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. Üheaegsus pod'ide planeerimisel

On märgatud, et: kui meil on nodis paigutatud pod ja selle pildi alla laadimine võtab kaua aega, siis teine pod, mis "satub" samale node'ile, lihtsalt ei alusta uue pod'i kuvatamise tõmbamisega.Selle asemel ootab ta, kuni eelmine pod'i pilt on tõmmatud. Tulemuseks on pod, mis on juba planeeritud ja mille pilt oleks võinud alla laadida vaid minutiga, jääb pikaks ajaks staatusele containerCreating.

Sündmustes on umbes järgmine:

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 ainult üks pilt aeglasest registrist võib blokeerida juurutamise node'ile.

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

1. Püüdke kasutada oma Docker registrit otse klastris või otse klassi (näiteks GitLab Registry, Nexus jne);
2. Kasutage selliseid tööriistu nagu kraken.

Lugu 5. Sõlmede hangumine mälu puuduse tõttu

Erinevate rakenduste kasutamise ajal oleme samuti kogenud olukordi, kus sõlm lakkab täielikult olemast kättesaadav: ei vasta SSH, kõik jälgimisdemonid pingutavad ja logides ei ole midagi (või peaaegu midagi) ebatavalist.

Näitan piltidel ühe sõlme näiteks, kus töötas MongoDB.

Nii näeb atop välja kuni katastroofid:

Ja nii — pärast katastroofid:

Jälgimises on samuti nähtav terav tõus, mille käigus sõlm lakab olemast kättesaadav:

Seega, ekraanipiltidest on näha, et:

1. Mälu masinas on peaaegu otsas;
2. Täheldatakse järsku mälutarbimise kasvu, mille järel juurdepääs kogu masinale katkeb;
3. Mongo'le tuleb suur ülesanne, mis paneb andmebaasi protsessi kasutama rohkem mälu ja aktiivselt lugema kettalt.

Selgub, et kui Linuxis lõpeb vaba mälu (tekib mälurõhk) ja s-wappi pole, siis kuni OOM killer'i saabumise hetk võib tähendada tasakaalu lehitsemise vahel lehtede paigutamise page cache'i ja nende kirjutamise tagasi kettale. Sellega tegeleb kswapd, kes julgeb vabastada võimalikult palju mälu lehti edasiseks jaotamiseks.

Kahjuks, kui sisend/väljund koormus on suur koos väikese vaba mäluhulgaga, kasvab kswapd kogu süsteemi pudelikaelaks, kuna sellele sõltuvad 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 ning jäävad OOM killer'i äärele.

Küsimus on loomulik: miks OOM killer tuleb nii hilja? Praeguses iteratsioonis on OOM killer äärmiselt rumal: ta lõpetab protsessi ainult siis, kui ebaõnnestub mälulehe jaotamise katse, st kui page fault läheb läbi veaga. Seda ei juhtu piisavalt kaua, kuna kswapd julgeb vabastada mälulehti, kustutades page cache'i (kogu ketta I/O süsteemis, põhimõtteliselt) tagasi kettale. Täiendavalt, koos sammudega, mis on vajalikud sarnaste probleemide lahendamiseks tuumas, saate lugeda siin.

See käitumine peaks paranema Linuxi 4.6+ tuumaga.

Ajalugu 6. Pod’id jäävad seisundisse Pending

Mõnedes klastrites, kus töötab tõeliselt palju pod’e, oleme hakanud märkama, et suur osa neist jääb väga kauaks "ripakile" seisu Pending, kuigi samal ajal on Docker-konteinerid juba sõlmedes käivitatud ja nendega saab käsitsi töötada.

Samas on describe pole midagi halba:

  Type    Reason                  Age                From                     Message
  ----    ------                  ----               ----                     -------
  Normal  Scheduled               1m                 default-scheduler        Edukalt määratud sphinx-0 ss-dev-kub07-le
  Normal  SuccessfulAttachVolume  1m                 attachdetach-controller  AttachVolume.Attach õnnestus mahuti "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" jaoks
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "sphinx-config" jaoks
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "default-token-fzcsf" jaoks
  Normal  SuccessfulMountVolume   49s (x2 over 51s)  kubelet, ss-dev-kub07    MountVolume.SetUp õnnestus mahuti "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" jaoks
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Konteineri pilt "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" on juba masinas olemas
  Normal  Created                 43s                kubelet, ss-dev-kub07    Kontainer loodud
  Normal  Started                 43s                kubelet, ss-dev-kub07    Kontainer käivitatud
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Konteineri pilt "registry.example.com/infra/sphinx/sphinx:v1" on juba masinas olemas
  Normal  Created                 42s                kubelet, ss-dev-kub07    Kontainer loodud
  Normal  Started                 42s                kubelet, ss-dev-kub07    Kontainer käivitatud

Uurides asja, tegime järelduse, et kubelet ei suuda lihtsalt API-serverile kõiki pod’ide olekuandmeid piisavalt kiiresti edastada, liveness/readiness-testide kohta.

Ja uurides abi, leidsime järgmised parameetrid:

--kube-api-qps - QPS, mida kasutada kubernetes apiserveriga suhtlemisel (vaikimisi 5)
--kube-api-burst  - Burst, mida kasutada kubernetes apiserveriga suhtlemisel (vaikimisi 10)
--event-qps - Kui > 0, piirata ürituste loomise sagedust sekundis sellele väärtusele. Kui 0, piiramatu. (vaikimisi 5)
--event-burst - Maksimaalne suurus purunevate ürituste jaoks, lubab ajutiselt ürituste rekordite puruneda sellele numbrile, ületamata siiski event-qps-i. Kasutatakse ainult juhul, kui --event-qps > 0 (vaikimisi 10)
--registry-qps - Kui > 0, piirata registri pull-i QPS-iga sellele väärtusele.
--registry-burst - Maksimaalne suurus purunevate tõmbamiste jaoks, lubab ajutiselt tõmbamisi puruneda sellele numbrile, ületamata siiski registry-qps-i. Kasutatakse ainult juhul, kui --registry-qps > 0 (vaikimisi 10)

Nagu näha, vaikimisi väärtused on üsna väikesed, ja 90% juhtudest katab see kõik vajadused... Kuid meie puhul osutus sellest väheks. Seetõttu seadsime sellised väärtused:

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

… ja käivitasime kubelet’id uuesti, pärast mida nägime API-serveri mahtuvuse graafikutel järgmist pilti:

… ja jah, kõik hakkas lendama!

P.S.

Suur tänu meie ettevõtte paljudele inseneridele, eriti minu kolleegile R&D meeskonnast Andreile Klimentjevile, abi eest vigade kogumisel ja artikli ettevalmistamisel.zuzzas).

P.P.S.

Lugege ka meie blogist:

• «Kubernetesi pod'ide tõrkeotsimiseks mõeldud kubectl-debug plugin».
• Kubernetesi näpunäited ja nipid:
  • «Helmi 2 haldamisse üleminevate rippude tõlkimine»;
  • «Uhkete sõlmede ja koormuste jaotus veebirakendusele»;
  • «Juurdepääs dev-keskkondadele»;
  • «Kiirendame suurte andmebaaside bootstrap'i».

Allikas: habr.com