![6 underhållande systembuggar i driften av Kubernetes [och deras lösning]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Under åren vi har använt Kubernetes i produktionen har vi samlat på oss många intressanta historier om hur buggar i olika systemkomponenter ledde till obehagliga och/eller obegripliga konsekvenser som påverkar driften av behållare och baljor. I den här artikeln har vi gjort ett urval av några av de vanligaste eller mest intressanta. Även om du aldrig har turen att stöta på sådana situationer, är det alltid intressant att läsa om sådana korta deckare - speciellt "första hand" - eller hur?
Story 1. Supercronic och Docker hängande
På ett av klustren fick vi med jämna mellanrum en frusen Docker, som störde klustrets normala funktion. Samtidigt observerades följande i Docker-loggarna:
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
…
Det som intresserar oss mest med det här felet är meddelandet: pthread_create failed: No space left on device. Snabbstudie förklarade att Docker inte kunde splittra en process, varför den periodvis frös.
Vid övervakning motsvarar följande bild vad som händer:
En liknande situation observeras på andra noder:
Vid samma noder ser vi:
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] <defunct>
root 17398 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 16852 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 9473 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 4664 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 30571 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 24113 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 16475 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 7176 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 1090 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>Det visade sig att detta beteende är en konsekvens av att podden arbetar med (ett Go-verktyg som vi använder för att köra cron-jobb i pods):
_ 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] <defunct>
| _ [curl] <defunct>
| _ [curl] <defunct>
| _ [curl] <defunct>
…Problemet är detta: när en uppgift körs i supercronic, skapades processen av den kan inte avslutas korrekt, förvandlas till .
Notera: För att vara mer exakt, processer skapas av cron-uppgifter, men supercronic är inte ett init-system och kan inte "adoptera" processer som dess barn skapade. När SIGHUP- eller SIGTERM-signaler höjs, skickas de inte vidare till underordnade processer, vilket resulterar i att underordnade processer inte avslutas och förblir i zombiestatus. Allt detta kan du läsa mer om till exempel i .
Det finns ett par sätt att lösa problem:
- Som en tillfällig lösning – öka antalet PID:er i systemet vid en enda tidpunkt:
/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 - Eller starta uppgifter i supercronic inte direkt, utan med samma , som kan avsluta processer korrekt och inte skapa zombies.
Berättelse 2. "Zombies" när du tar bort en c-grupp
Kubelet började förbruka mycket CPU:
Ingen kommer att gilla detta, så vi beväpnade oss och började ta itu med problemet. Resultatet av undersökningen var följande:
- Kubelet spenderar mer än en tredjedel av sin CPU-tid på att hämta minnesdata från alla cgroups:
- I kärnutvecklarnas e-postlista kan du hitta . I korthet kommer poängen ner till detta: olika tmpfs-filer och andra liknande saker tas inte bort helt från systemet vid borttagning av en c-grupp, den sk zombie. Förr eller senare kommer de att raderas från sidcachen, men det finns mycket minne på servern och kärnan ser inte poängen med att slösa tid på att radera dem. Det är därför de fortsätter att hopa sig. Varför händer detta ens? Det här är en server med cron-jobb som hela tiden skapar nya jobb, och med dem nya poddar. Således skapas nya cgroups för behållare i dem, som snart raderas.
- Varför slösar cAdvisor i kubelet så mycket tid? Detta är lätt att se med det enklaste utförandet
time cat /sys/fs/cgroup/memory/memory.stat. Om operationen på en frisk maskin tar 0,01 sekunder, tar den på den problematiska cron02 1,2 sekunder. Saken är den att cAdvisor, som läser data från sysfs väldigt långsamt, försöker ta hänsyn till minnet som används i zombie cgroups. - För att tvångsmässigt ta bort zombies försökte vi rensa cacheminne som rekommenderas i LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - men kärnan visade sig vara mer komplicerad och kraschade bilen.
Vad ska man göra? Problemet håller på att fixas (, och för en beskrivning se ) uppdaterar Linux-kärnan till version 4.16.
Historik 3. Systemd och dess montering
Återigen, kubelet förbrukar för många resurser på vissa noder, men den här gången förbrukar den för mycket minne:
Det visade sig att det finns ett problem i systemd som används i Ubuntu 16.04, och det uppstår när man hanterar monteringar som är skapade för anslutning subPath från ConfigMaps eller hemligheter. Efter att podden har avslutat sitt arbete systemd-tjänsten och dess servicemontering finns kvar i systemet. Med tiden ackumuleras ett stort antal av dem. Det finns till och med frågor om detta ämne:
- ;
- .
...den sista avser PR i systemd: (problem i systemd - ).
Problemet finns inte längre i Ubuntu 18.04, men om du vill fortsätta använda Ubuntu 16.04 kan du hitta vår lösning på det här ämnet användbar.
Så vi gjorde följande 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... och den använder följande skript:
#!/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... och den körs var 5:e minut med den tidigare nämnda supercronic. Dess Dockerfile ser ut så här:
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"]Berättelse 4. Konkurrenskraft vid schemaläggning av poddar
Det märktes att: om vi har en pod placerad på en nod och dess bild pumpas ut under mycket lång tid, så kommer en annan pod som "träffar" samma nod helt enkelt börjar inte dra bilden av den nya podden. Istället väntar den tills bilden av den föregående podden dras. Som ett resultat kommer en pod som redan var schemalagd och vars bild kunde ha laddats ner på bara en minut hamna i statusen containerCreating.
Händelserna kommer att se ut ungefär så här:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Det visar sig att en enda bild från ett långsamt register kan blockera distributionen per nod.
Tyvärr finns det inte många vägar ut ur situationen:
- Försök att använda ditt Docker Registry direkt i klustret eller direkt med klustret (till exempel GitLab Registry, Nexus, etc.);
- Använd verktyg som t.ex .
Berättelse 5. Noder hänger på grund av brist på minne
Under driften av olika applikationer stötte vi också på en situation där en nod helt upphör att vara tillgänglig: SSH svarar inte, alla övervakningsdemoner faller av och sedan finns det ingenting (eller nästan ingenting) avvikande i loggarna.
Jag ska berätta i bilder med exemplet på en nod där MongoDB fungerade.
Så här ser det ut på toppen до olyckor:
Och så här - efter olyckor:
Vid övervakning finns det också ett skarpt hopp, där noden upphör att vara tillgänglig:
Från skärmdumparna är det alltså tydligt att:
- RAM-minnet på maskinen är nära slutet;
- Det finns ett kraftigt hopp i RAM-förbrukningen, varefter åtkomst till hela maskinen plötsligt inaktiveras;
- En stor uppgift kommer till Mongo, vilket tvingar DBMS-processen att använda mer minne och aktivt läsa från disk.
Det visar sig att om Linux får slut på ledigt minne (minnestrycket sätter in) och det inte finns något utbyte, då до När OOM-mördaren anländer kan en balansgång uppstå mellan att slänga sidor i sidcachen och att skriva tillbaka dem till disken. Detta görs av kswapd, som modigt frigör så många minnessidor som möjligt för efterföljande distribution.
Tyvärr, med en stor I/O-belastning tillsammans med en liten mängd ledigt minne, kswapd blir flaskhalsen i hela systemet, eftersom de är bundna till det alla tilldelningar (sidfel) av minnessidor i systemet. Detta kan pågå under mycket lång tid om processerna inte vill använda minnet längre, utan är fixerade vid yttersta kanten av OOM-dödarens avgrund.
Den naturliga frågan är: varför kommer OOM-mördaren så sent? I sin nuvarande iteration är OOM-mördaren extremt dum: den dödar processen endast när försöket att allokera en minnessida misslyckas, d.v.s. om sidfelet misslyckas. Detta händer inte på ganska länge, eftersom kswapd modigt frigör minnessidor och dumpar sidcachen (hela diskens I/O i systemet, faktiskt) tillbaka till disken. Mer detaljerat, med en beskrivning av de steg som krävs för att eliminera sådana problem i kärnan, kan du läsa .
Detta beteende med Linux-kärna 4.6+.
Berättelse 6. Poddar fastnar i väntande läge
I vissa kluster, där det verkligen finns många baljor som verkar, började vi märka att de flesta av dem "hänger" väldigt länge i staten Pending, även om själva Docker-behållarna redan körs på noderna och kan arbetas med manuellt.
Samtidigt, i describe Det är inget fel:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 1m default-scheduler Successfully assigned sphinx-0 to ss-dev-kub07
Normal SuccessfulAttachVolume 1m attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "sphinx-config"
Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "default-token-fzcsf"
Normal SuccessfulMountVolume 49s (x2 over 51s) kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" already present on machine
Normal Created 43s kubelet, ss-dev-kub07 Created container
Normal Started 43s kubelet, ss-dev-kub07 Started container
Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx/sphinx:v1" already present on machine
Normal Created 42s kubelet, ss-dev-kub07 Created container
Normal Started 42s kubelet, ss-dev-kub07 Started containerEfter lite grävande gjorde vi antagandet att kubelet helt enkelt inte har tid att skicka all information om tillståndet för poddarna och liveness/readiness-tester till API-servern.
Och efter att ha studerat hjälp hittade vi följande parametrar:
--kube-api-qps - QPS to use while talking with kubernetes apiserver (default 5)
--kube-api-burst - Burst to use while talking with kubernetes apiserver (default 10)
--event-qps - If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
--event-burst - Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10)
--registry-qps - If > 0, limit registry pull QPS to this value.
--registry-burst - Maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)Som sett, standardvärdena är ganska små, och till 90 % täcker de alla behov... Men i vårt fall räckte inte detta. Därför ställer vi in följande värden:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... och startade om kubelets, varefter vi såg följande bild i graferna för anrop till API-servern:
... och ja, allt började flyga!
PS
För deras hjälp med att samla in buggar och förbereda den här artikeln uttrycker jag min djupa tacksamhet till de många ingenjörerna i vårt företag, och särskilt till min kollega från vårt FoU-team Andrey Klimentyev ().
PPS
Läs även på vår blogg:
- «".
- Kubernetes tips & tricks loop:
- «";
- «";
- «";
- «".
Källa: will.com