![6 vermakelijke systeembugs in de werking van Kubernetes [en hun oplossing]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Door de jaren heen dat we Kubernetes in productie hebben gebruikt, hebben we veel interessante verhalen verzameld over hoe bugs in verschillende systeemcomponenten tot onaangename en/of onbegrijpelijke gevolgen hebben geleid die de werking van containers en pods beïnvloeden. In dit artikel hebben we een selectie gemaakt van enkele van de meest voorkomende of interessante. Ook al heb je nooit het geluk om dergelijke situaties tegen te komen, het lezen over zulke korte detectiveverhalen – vooral ‘uit de eerste hand’ – is altijd interessant, nietwaar?
Verhaal 1. Supercronic en Docker hangen vast
Op een van de clusters ontvingen we periodiek een bevroren Docker, die de normale werking van het cluster verstoorde. Tegelijkertijd werd het volgende waargenomen in de Docker-logboeken:
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
…
Wat ons het meest interesseert aan deze fout is de boodschap: pthread_create failed: No space left on device. Snelle studie legde uit dat Docker een proces niet kon afsplitsen, waardoor het regelmatig vastliep.
Bij monitoring komt het volgende beeld overeen met wat er gebeurt:
Een soortgelijke situatie wordt waargenomen op andere knooppunten:
Op dezelfde knooppunten zien we:
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>Het bleek dat dit gedrag een gevolg is van het werken met de pod (een Go-hulpprogramma dat we gebruiken om cron-taken in pods uit te voeren):
_ 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>
…Het probleem is dit: wanneer een taak in supercronic wordt uitgevoerd, wordt het proces daardoor voortgebracht kan niet correct worden beëindigd, veranderen in .
Noot: Om preciezer te zijn: processen worden voortgebracht door cron-taken, maar supercronic is geen init-systeem en kan geen processen 'overnemen' die door zijn kinderen zijn voortgebracht. Wanneer SIGHUP- of SIGTERM-signalen worden gegenereerd, worden deze niet doorgegeven aan de onderliggende processen, waardoor de onderliggende processen niet worden beëindigd en in de zombiestatus blijven. Meer over dit alles leest u bijvoorbeeld in .
Er zijn een aantal manieren om problemen op te lossen:
- Als tijdelijke oplossing: verhoog het aantal PID's in het systeem op een bepaald 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 - Of start taken in supercronic niet rechtstreeks, maar gebruik hetzelfde , die processen correct kan beëindigen en geen zombies kan voortbrengen.
Verhaal 2. “Zombies” bij het verwijderen van een cgroup
Kubelet begon veel CPU te verbruiken:
Niemand zal dit leuk vinden, dus hebben we ons bewapend en begon het probleem aan te pakken. De resultaten van het onderzoek waren als volgt:
- Kubelet besteedt meer dan een derde van zijn CPU-tijd aan het ophalen van geheugengegevens uit alle cgroups:
- In de mailinglijst van de kernelontwikkelaars kun je dit vinden . In het kort komt het punt hierop neer: verschillende tmpfs-bestanden en andere soortgelijke zaken worden niet volledig van het systeem verwijderd bij het verwijderen van een cgroup, de zogenaamde zombie. Vroeg of laat zullen ze uit de paginacache worden verwijderd, maar er is veel geheugen op de server en de kernel ziet het nut er niet van in om tijd te verspillen aan het verwijderen ervan. Daarom blijven ze zich opstapelen. Waarom gebeurt dit eigenlijk? Dit is een server met cron-jobs die voortdurend nieuwe banen creëert, en daarmee ook nieuwe pods. Er worden dus nieuwe cgroups gemaakt voor containers daarin, die snel worden verwijderd.
- Waarom verspilt cAdvisor in kubelet zoveel tijd? Dit is gemakkelijk te zien met de eenvoudigste uitvoering
time cat /sys/fs/cgroup/memory/memory.stat. Als de bewerking op een gezonde machine 0,01 seconde duurt, dan duurt deze op de problematische cron02 1,2 seconde. Het punt is dat cAdvisor, dat gegevens uit sysfs heel langzaam leest, rekening probeert te houden met het geheugen dat wordt gebruikt in zombie-cgroups. - Om zombies met kracht te verwijderen, hebben we geprobeerd caches te wissen zoals aanbevolen in LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - maar de kernel bleek ingewikkelder en crashte de auto.
Wat moeten we doen? Het probleem wordt opgelost (, en voor een beschrijving zie ) het updaten van de Linux-kernel naar versie 4.16.
Geschiedenis 3. Systemd en zijn mount
Nogmaals, de kubelet verbruikt op sommige knooppunten te veel bronnen, maar deze keer verbruikt hij te veel geheugen:
Het bleek dat er een probleem is in systemd dat wordt gebruikt in Ubuntu 16.04, en het treedt op bij het beheren van mounts die zijn gemaakt voor verbinding subPath van ConfigMap's of geheimen. Nadat de pod zijn werk heeft voltooid de systemd-service en de bijbehorende service-mount blijven bestaan in systeem. In de loop van de tijd stapelt zich een groot aantal van hen op. Er zijn zelfs problemen over dit onderwerp:
- ;
- .
...waarvan de laatste verwijst naar de PR in systemd: (probleem in systemd - ).
Het probleem bestaat niet meer in Ubuntu 18.04, maar als u Ubuntu 16.04 wilt blijven gebruiken, vindt u onze oplossing voor dit onderwerp wellicht nuttig.
Daarom hebben we de volgende DaemonSet gemaakt:
---
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... en het gebruikt het volgende 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... en het draait elke 5 minuten met behulp van de eerder genoemde supercronic. Het Dockerfile ziet er als volgt uit:
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"]Verhaal 4. Concurrentievermogen bij het plannen van pods
Er werd opgemerkt dat: als we een pod op een knooppunt hebben geplaatst en het beeld ervan gedurende een zeer lange tijd wordt weggepompt, een andere pod die hetzelfde knooppunt “raakt”, eenvoudigweg begint niet het beeld van de nieuwe pod te trekken. In plaats daarvan wacht het totdat de afbeelding van de vorige pod wordt opgehaald. Als gevolg hiervan zal een pod die al gepland was en waarvan de afbeelding binnen een minuut gedownload had kunnen worden, de status krijgen van containerCreating.
De evenementen zullen er ongeveer zo uitzien:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Het blijkt dat een enkele afbeelding uit een traag register kan de implementatie blokkeren per knooppunt.
Helaas zijn er niet veel manieren om uit de situatie te komen:
- Probeer uw Docker Registry rechtstreeks in het cluster of rechtstreeks met het cluster te gebruiken (bijvoorbeeld GitLab Registry, Nexus, enz.);
- Gebruik hulpprogramma's zoals .
Verhaal 5. Knooppunten blijven hangen vanwege gebrek aan geheugen
Tijdens de werking van verschillende applicaties kwamen we ook een situatie tegen waarin een knooppunt volledig niet meer toegankelijk is: SSH reageert niet, alle monitoring-daemons vallen weg en dan staat er niets (of bijna niets) afwijkends in de logs.
Ik zal het je in afbeeldingen vertellen aan de hand van het voorbeeld van één knooppunt waar MongoDB functioneerde.
Zo ziet bovenop eruit naar ongelukken:
En zo - na ongelukken:
Bij monitoring is er ook een scherpe sprong, waarbij het knooppunt niet langer beschikbaar is:
Uit de schermafbeeldingen blijkt dus duidelijk dat:
- Het RAM-geheugen op de machine is bijna op;
- Er is een scherpe sprong in het RAM-verbruik, waarna de toegang tot de hele machine abrupt wordt uitgeschakeld;
- Er arriveert een grote taak op Mongo, waardoor het DBMS-proces meer geheugen moet gebruiken en actief van schijf moet lezen.
Het blijkt dat als Linux geen vrij geheugen meer heeft (de geheugendruk neemt toe) en er geen swap plaatsvindt naar Wanneer de OOM-killer arriveert, kan er een evenwichtsoefening ontstaan tussen het weggooien van pagina's in de paginacache en het terugschrijven naar schijf. Dit wordt gedaan door kswapd, dat moedig zoveel mogelijk geheugenpagina's vrijmaakt voor latere distributie.
Helaas, met een grote I/O-belasting in combinatie met een kleine hoeveelheid vrij geheugen, kswapd wordt het knelpunt van het hele systeem, omdat ze eraan gebonden zijn alle toewijzingen (paginafouten) van geheugenpagina's in het systeem. Dit kan heel lang doorgaan als de processen geen geheugen meer willen gebruiken, maar zich aan de uiterste rand van de OOM-killer-afgrond bevinden.
De natuurlijke vraag is: waarom komt de OOM-moordenaar zo laat? In zijn huidige versie is de OOM-killer buitengewoon dom: hij zal het proces alleen beëindigen als de poging om een geheugenpagina toe te wijzen mislukt, d.w.z. als de paginafout mislukt. Dit gebeurt pas een hele tijd, omdat kswapd moedig geheugenpagina's vrijmaakt en de paginacache (in feite de hele schijf-I/O in het systeem) terug naar de schijf dumpt. Meer gedetailleerd kunt u lezen met een beschrijving van de stappen die nodig zijn om dergelijke problemen in de kernel te elimineren .
Dit gedrag met Linux-kernel 4.6+.
Verhaal 6. Pods blijven hangen in de status In behandeling
In sommige clusters, waar heel veel pods actief zijn, merkten we dat de meeste ervan heel lang in de staat ‘hangen’. Pending, hoewel de Docker-containers zelf al op de knooppunten draaien en er handmatig mee kan worden gewerkt.
Tegelijkertijd binnen describe er is niets mis:
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 containerNa wat graafwerk gingen we ervan uit dat de kubelet simpelweg geen tijd heeft om alle informatie over de status van de pods en liveness/gereedheidstests naar de API-server te sturen.
En na het bestuderen van hulp vonden we de volgende parameters:
--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)Als gezien, standaardwaarden zijn vrij klein, en in 90% dekken ze alle behoeften... In ons geval was dit echter niet genoeg. Daarom stellen we de volgende waarden in:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... en startte de kubelets opnieuw op, waarna we het volgende beeld zagen in de grafieken van oproepen naar de API-server:
... en ja, alles begon te vliegen!
PS
Voor hun hulp bij het verzamelen van bugs en het voorbereiden van dit artikel, spreek ik mijn diepe dankbaarheid uit aan de talrijke ingenieurs van ons bedrijf, en vooral aan mijn collega van ons R&D-team Andrey Klimentyev ().
PPS
Lees ook op onze blog:
- «.
- Kubernetes tips & tricks-loop:
- «";
- «";
- «";
- «.
Bron: www.habr.com