![6 fermaaklike systeembugs yn 'e wurking fan Kubernetes [en har oplossing]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Yn 'e rin fan' e jierren fan it brûken fan Kubernetes yn 'e produksje hawwe wy in protte nijsgjirrige ferhalen sammele oer hoe't bugs yn ferskate systeemkomponinten liede ta onaangename en / of ûnbegryplike gefolgen dy't de wurking fan konteners en pods beynfloedzje. Yn dit artikel hawwe wy in seleksje makke fan guon fan 'e meast foarkommende as nijsgjirrige. Sels as jo noait gelok hawwe om sokke situaasjes tsjin te kommen, is it lêzen oer sokke koarte detektiveferhalen - benammen "earste hân" - altyd nijsgjirrich, is it net?
Ferhaal 1. Supercronic en Docker hingje
Op ien fan 'e klusters krigen wy periodyk in beferzen Docker, dy't ynterfere mei it normale funksjonearjen fan it kluster. Tagelyk waard it folgjende waarnommen yn 'e Docker-logs:
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 ús it meast ynteressearret oan dizze flater is it berjocht: pthread_create failed: No space left on device. Quick Study ferklearre dat Docker gjin proses koe forke, dat is wêrom it periodyk beferzen.
By tafersjoch komt it folgjende byld oerien mei wat der bart:
In fergelykbere situaasje wurdt waarnommen op oare knopen:
Op deselde knopen sjogge wy:
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>It die bliken dat dit gedrach is in gefolch fan de pod wurkjen mei (in Go-hulpprogramma dat wy brûke om cron-taken yn pods út te fieren):
_ 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>
…It probleem is dit: as in taak wurdt útfierd yn supercronic, ûntstiet it proses dêrtroch kin net korrekt beëinigje, oerset yn .
remark: Om krekter te wêzen, prosessen wurde spawn troch cron-taken, mar supercronic is gjin init-systeem en kin net "adoptearje" prosessen dy't har bern hawwe. As SIGHUP- of SIGTERM-sinjalen wurde ferhege, wurde se net trochjûn oan 'e bernprosessen, wat resulteart yn' e bernprosessen net beëinigje en bliuwe yn zombiestatus. Jo kinne mear lêze oer dit alles, bygelyks, yn .
D'r binne in pear manieren om problemen op te lossen:
- As tydlike oplossing - fergrutsje it oantal PID's yn it systeem op in inkeld punt yn 'e tiid:
/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 launch taken yn supercronic net direkt, mar mei help fan itselde , dy't yn steat is om prosessen korrekt te beëinigjen en zombies net te spawnen.
Ferhaal 2. "Zombies" by it wiskjen fan in cgroup
Kubelet begon in protte CPU te konsumearjen:
Nimmen sil dit leuk fine, dus wy wapene ússels en begûn te gean mei it probleem. De resultaten fan it ûndersyk wiene as folget:
- Kubelet besteget mear as in tredde fan syn CPU-tiid oan it lûken fan ûnthâldgegevens fan alle cgroups:
- Yn 'e mailinglist fan kernelûntwikkelders kinne jo fine . Koartsein komt it punt hjirop del: ferskate tmpfs-bestannen en oare ferlykbere dingen wurde net folslein fan it systeem fuortsmiten by it wiskjen fan in cgroup, de saneamde zombie. Ier of letter sille se wiske wurde fan 'e side-cache, mar d'r is in soad ûnthâld op' e tsjinner en de kearn sjocht it punt net om tiid te fergriemen op it wiskjen. Dêrom bliuwe se opstapelen. Wêrom bart dit sels? Dit is in tsjinner mei cron banen dy't hieltyd skept nije banen, en mei harren nije pods. Sa wurde nije cgroups makke foar konteners dêryn, dy't gau wiske wurde.
- Wêrom fergriemt cAdvisor yn kubelet safolle tiid? Dit is maklik te sjen mei de ienfâldichste útfiering
time cat /sys/fs/cgroup/memory/memory.stat. As op in sûne masine de operaasje duorret 0,01 sekonden, dan op 'e problematyske cron02 duorret it 1,2 sekonden. It ding is dat cAdvisor, dy't gegevens fan sysfs heul stadich lêst, besiket rekken te hâlden mei it ûnthâld dat brûkt wurdt yn zombie cgroups. - Om zombies krêftich te ferwiderjen, hawwe wy besocht caches te wiskjen lykas oanrikkemandearre yn LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - mar de kearn bleek yngewikkelder te wêzen en botste mei de auto.
Wat te dwaan? It probleem wurdt repareare (, en foar in beskriuwing sjoch ) it bywurkjen fan de Linux kernel nei ferzje 4.16.
Skiednis 3. Systemd en syn berch
Nochris verbruikt de kubelet tefolle boarnen op guon knopen, mar dizze kear konsumearret it tefolle ûnthâld:
It die bliken dat d'r in probleem is yn systemd brûkt yn Ubuntu 16.04, en it komt foar by it behearen fan mounts dy't makke binne foar ferbining subPath fan ConfigMap's of geheimen. Nei't de pod syn wurk foltôge hat de systemd tsjinst en syn tsjinst mount bliuwe yn systeem. Yn 'e rin fan' e tiid sammele in grut oantal fan harren. D'r binne sels problemen oer dit ûnderwerp:
- ;
- .
...de lêste ferwiist nei de PR yn systemd: (probleem yn systemd - ).
It probleem bestiet net mear yn Ubuntu 18.04, mar as jo wolle trochgean mei it brûken fan Ubuntu 16.04, kinne jo ús oplossing oer dit ûnderwerp nuttich fine.
Dat wy makken de folgjende 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... en it brûkt it folgjende 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... en it rint elke 5 minuten mei de earder neamde supercronic. It Dockerfile sjocht der sa út:
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"]Ferhaal 4. Konkurrinsjefermogen by it plannen fan pods
It waard opmurken dat: as wy in pod hawwe pleatst op in knooppunt en syn byld wurdt útpompt foar in heul lange tiid, dan sil in oare pod dy't deselde knoop "treffe" gewoan begjint net te lûken it byld fan de nije pod. Ynstee dêrfan wachtet it oant it byld fan 'e foarige pod wurdt lutsen. As resultaat sil in pod dy't al pland wie en wêrfan de ôfbylding yn mar in minút ynladen wurde koe, einigje yn 'e status fan containerCreating.
De eveneminten sille der sa útsjen:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"It bliuwt dat in inkele ôfbylding fan in trage register kin ynset blokkearje per knooppunt.
Spitigernôch binne d'r net folle manieren út 'e situaasje:
- Besykje jo Docker Registry direkt te brûken yn it kluster of direkt mei it kluster (bygelyks GitLab Registry, Nexus, ensfh.);
- Brûk nutsbedriuwen lykas .
Ferhaal 5. Knooppunten hingje troch gebrek oan ûnthâld
Tidens de eksploitaasje fan ferskate applikaasjes, wy tsjinkaam ek in situaasje dêr't in knooppunt folslein ophâldt te wêzen tagonklik: SSH reagearret net, alle tafersjoch daemon falle ôf, en dan is der neat (of hast neat) abnormale yn de logs.
Ik sil jo yn ôfbyldings fertelle mei it foarbyld fan ien knooppunt wêr't MongoDB funksjonearre.
Dit is hoe't boppe op sjocht до ûngelokken:
En sa - после ûngelokken:
By it tafersjoch is d'r ek in skerpe sprong, wêrby't it knooppunt ophâldt beskikber te wêzen:
Sa is út 'e skermôfbyldings dúdlik dat:
- De RAM op 'e masine is tichtby de ein;
- Der is in skerpe sprong yn RAM-konsumpsje, wêrnei't tagong ta de hiele masine abrupt útskeakele is;
- In grutte taak komt op Mongo, dy't it DBMS-proses twingt om mear ûnthâld te brûken en aktyf te lêzen fan skiif.
It docht bliken dat as Linux gjin frije ûnthâld rint (ûnthâlddruk set yn) en d'r is gjin swap, dan до As de OOM-moardner oankomt, kin der in lykwichtsaksje ûntstean tusken it smiten fan siden yn de side-cache en it weromskriuwen fan se op skiif. Dit wurdt dien troch kswapd, dy't moedich safolle mooglik ûnthâldsiden frijmakket foar folgjende distribúsje.
Spitigernôch, mei in grutte I / O-lading kombinearre mei in lyts bedrach fan fergees ûnthâld, kswapd wurdt de flessehals fan it hiele systeem, om't se der oan bûn binne allegear allocations (side flaters) fan ûnthâld siden yn it systeem. Dit kin hiel lang trochgean as de prosessen gjin ûnthâld mear brûke wolle, mar oan de râne fan de OOM-killer ôfgrûn fêstlizze.
De natuerlike fraach is: wêrom komt de OOM-moardner sa let? Yn syn hjoeddeistige iteraasje is de OOM-moardner ekstreem dom: it sil it proses allinich deadzje as it besykjen om in ûnthâldside te allocearjen mislearret, d.w.s. as de side flater mislearret. Dit bart net foar in hiel lange tiid, om't kswapd moedich ûnthâldsiden befrijt, en de side-cache (de heule skiif I/O yn it systeem, trouwens) werom nei skiif dumpt. Yn mear detail, mei in beskriuwing fan 'e stappen dy't nedich binne om sokke problemen yn' e kernel te eliminearjen, kinne jo lêze .
Dit gedrach mei Linux kernel 4.6+.
Ferhaal 6. Pods komme fêst yn Pending state
Yn guon klusters, wêryn't d'r echt in protte pods wurkje, begon wy te merken dat de measten fan har in heul lange tiid yn 'e steat "hingje" Pending, hoewol de Docker-konteners sels al op 'e knopen rinne en kinne mei de hân wurke wurde.
Boppedat, yn describe der is neat 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 containerNei wat graven hawwe wy de oanname makke dat de kubelet gewoan gjin tiid hat om alle ynformaasje oer de steat fan 'e pods en tests foar liveness / reewilligens nei de API-tsjinner te stjoeren.
En nei it studearjen fan help, fûnen wy de folgjende 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)Lykas sjoen, standertwearden binne frij lyts, en yn 90% dekke se alle behoeften ... Yn ús gefal wie dit lykwols net genôch. Dêrom sette wy de folgjende wearden yn:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... en de kubelets opnij starte, wêrnei't wy de folgjende ôfbylding seagen yn 'e grafiken fan oproppen nei de API-tsjinner:
... en ja, alles begûn te fleanen!
PS
Foar har help by it sammeljen fan bugs en it tarieden fan dit artikel, uterje ik myn djippe tankberens oan 'e ferskate yngenieurs fan ús bedriuw, en foaral oan myn kollega fan ús R&D-team Andrey Klimentyev ().
PPS
Lês ek op ús blog:
- «".
- Kubernetes tips & tricks loop:
- «";
- «";
- «";
- «".
Boarne: www.habr.com