![6 bugs tas-sistema divertenti fl-operat ta' Kubernetes [u s-soluzzjoni tagħhom]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Matul is-snin ta 'użu ta' Kubernetes fil-produzzjoni, akkumulajna ħafna stejjer interessanti ta 'kif bugs f'diversi komponenti tas-sistema wasslu għal konsegwenzi spjaċevoli u/jew inkomprensibbli li jaffettwaw l-operat ta' kontenituri u imżiewed. F'dan l-artikolu għamilna għażla ta 'wħud mill-aktar komuni jew interessanti. Anke jekk qatt ma tkun xortik tajba biżżejjed li tiltaqa' ma' sitwazzjonijiet bħal dawn, il-qari dwar stejjer qosra ta' ditektifs bħal dawn - speċjalment "l-ewwel" - huwa dejjem interessanti, hux?...
Storja 1. Supercronic u Docker mdendlin
Fuq wieħed mill-clusters, irċevejna perjodikament Docker iffriżat, li interferiet mal-funzjonament normali tal-cluster. Fl-istess ħin, dan li ġej ġie osservat fir-reġistru Docker:
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
…
L-iktar li jinteressana dwar dan l-iżball huwa l-messaġġ: pthread_create failed: No space left on device. Studju malajr spjega li Docker ma setax jagħmel proċess, u huwa għalhekk li ffriżat perjodikament.
Fil-monitoraġġ, l-istampa li ġejja tikkorrispondi għal dak li qed jiġri:
Sitwazzjoni simili hija osservata fuq nodi oħra:
Fl-istess nodi naraw:
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>Irriżulta li din l-imġieba hija konsegwenza tal-powd li jaħdem magħhom (utilità Go li nużaw biex inħaddmu impjiegi cron fil-miżwed):
_ 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>
…Il-problema hija din: meta kompitu jitmexxa f'supercronic, il-proċess nissel minnha ma tistax tittermina b'mod korrett, tidwir fi .
Innota: Biex inkun aktar preċiż, il-proċessi jitnisslu minn kompiti cron, iżda supercronic mhix sistema init u ma tistax "jadotta" proċessi li wliedha biedu. Meta s-sinjali SIGHUP jew SIGTERM jitqajmu, ma jiġux mgħoddija lill-proċessi tat-tfal, u dan jirriżulta fil-proċessi tat-tfal ma jispiċċawx u jibqgħu fi status ta 'zombie. Tista’ taqra aktar dwar dan kollu, pereżempju, fi .
Hemm ftit modi kif issolvi l-problemi:
- Bħala soluzzjoni temporanja - żid in-numru ta 'PIDs fis-sistema f'punt wieħed fiż-żmien:
/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 - Jew tniedi kompiti fil supercronic mhux direttament, iżda bl-użu l-istess , li huwa kapaċi jtemm il-proċessi b'mod korrett u ma jbid zombies.
Storja 2. "Zombies" meta tħassar cgroup
Kubelet beda jikkonsma ħafna CPU:
Ħadd mhu se jħobb dan, allura armajna ruħna u bdew jittrattaw il-problema. Ir-riżultati tal-investigazzjoni kienu kif ġej:
- Kubelet iqatta 'aktar minn terz tal-ħin tas-CPU tiegħu jiġbed data tal-memorja mill-cgroups kollha:
- Fil-lista tal-posta tal-iżviluppaturi tal-qalba tista' ssib . Fil-qosor, il-punt jasal għal dan: diversi fajls tmpfs u affarijiet simili oħra ma jitneħħewx kompletament mis-sistema meta tħassar cgroup, l-hekk imsejjaħ Zombie. Illum jew għada dawn se jitħassru mill-cache tal-paġna, iżda hemm ħafna memorja fuq is-server u l-kernel ma jarax il-punt li jaħli l-ħin biex iħassarhom. Għalhekk jibqgħu jinġabru. Għaliex qed jiġri dan? Dan huwa server b'impjiegi cron li kontinwament joħloq impjiegi ġodda, u magħhom imżiewed ġodda. Għalhekk, jinħolqu cgroups ġodda għal kontenituri fihom, li dalwaqt jitħassru.
- Għaliex cAdvisor f'kubelet jaħli daqshekk ħin? Dan huwa faċli biex tara bl-eżekuzzjoni sempliċi
time cat /sys/fs/cgroup/memory/memory.stat. Jekk fuq magna b'saħħitha l-operazzjoni tieħu 0,01 sekondi, allura fuq il-cron02 problematiku tieħu 1,2 sekondi. Il-ħaġa hija li cAdvisor, li jaqra data mis-sysfs bil-mod ħafna, jipprova jqis il-memorja użata f'cgroups zombie. - Biex inneħħu l-zombies bil-qawwa, ippruvajna nneħħi l-caches kif rakkomandat f'LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - iżda l-qalba rriżulta li kienet aktar ikkumplikata u ħabtet il-karozza.
X'tagħmel? Il-problema qed tiġi rranġata (, u għal deskrizzjoni ara ) jaġġorna l-kernel tal-Linux għall-verżjoni 4.16.
Storja 3. Systemd u l-muntatura tiegħu
Għal darb'oħra, il-kubelet qed jikkonsma wisq riżorsi fuq xi nodi, iżda din id-darba qed jikkonsma wisq memorja:
Irriżulta li hemm problema fis-systemd użata f'Ubuntu 16.04, u sseħħ meta timmaniġġja muntaturi li huma maħluqa għall-konnessjoni subPath minn ConfigMaps jew sigrieti. Wara li l-pod ikun lesta x-xogħol tiegħu is-servizz systemd u l-muntatura tas-servizz tiegħu jibqgħu fis-sistema. Maż-żmien, numru kbir minnhom jakkumulaw. Hemm ukoll kwistjonijiet dwar dan is-suġġett:
- ;
- .
...l-aħħar minnhom jirreferi għall-PR fis-systemd: (ħarġa fis-systemd - ).
Il-problema m'għadhiex teżisti f'Ubuntu 18.04, imma jekk trid tkompli tuża Ubuntu 16.04, tista 'ssib il-soluzzjoni tagħna dwar dan is-suġġett utli.
Allura għamilna d-DaemonSet li ġej:
---
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... u juża l-iskrittura li ġejja:
#!/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... u taħdem kull 5 minuti bl-użu tas-supercronic imsemmi qabel. Dockerfile tiegħu jidher bħal dan:
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"]Storja 4. Kompetittività meta skedar imżiewed
Ġie nnutat li: jekk ikollna pod imqiegħed fuq node u l-immaġni tiegħu tiġi ppumpjata għal żmien twil ħafna, allura pod ieħor li "jolqot" l-istess nodu sempliċement se ma tibda tiġbed l-immaġni tal-powd il-ġdid. Minflok, tistenna sakemm tinġibed l-immaġini tal-powd preċedenti. B’riżultat ta’ dan, pod li kien diġà skedat u li l-immaġni tiegħu setgħet titniżżel f’minuta biss se jispiċċa fl-istatus ta’ containerCreating.
L-avvenimenti se jidhru xi ħaġa bħal din:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Jirriżulta li immaġini waħda minn reġistru bil-mod jista 'jimblokka l-iskjerament għal kull node.
Sfortunatament, m'hemmx ħafna modi biex toħroġ mis-sitwazzjoni:
- Ipprova uża r-Reġistru Docker tiegħek direttament fil-cluster jew direttament mal-cluster (per eżempju, GitLab Reġistru, Nexus, eċċ.);
- Uża utilitajiet bħal .
Storja 5. Nodes hang minħabba nuqqas ta 'memorja
Waqt it-tħaddim ta 'diversi applikazzjonijiet, iltqajna wkoll ma' sitwazzjoni fejn node ma jibqax kompletament aċċessibbli: SSH ma jirrispondix, id-daemons ta 'monitoraġġ kollha jaqgħu, u allura m'hemm xejn (jew kważi xejn) anomali fir-zkuk.
Jien ngħidlek fl-istampi billi tuża l-eżempju ta 'node wieħed fejn ħadmet MongoDB.
Dan huwa dak li jidher atop li inċidenti:
U bħal dan - wara inċidenti:
Fil-monitoraġġ, hemm ukoll qabża qawwija, li fiha n-nodu ma jibqax disponibbli:
Għalhekk, mill-screenshots jidher ċar li:
- Ir-RAM fuq il-magna hija qrib it-tmiem;
- Hemm qabża qawwija fil-konsum ta 'RAM, wara li l-aċċess għall-magna kollha huwa diżattivat f'daqqa;
- Jasal kompitu kbir fuq Mongo, li jġiegħel lill-proċess tad-DBMS juża aktar memorja u jaqra b'mod attiv mid-disk.
Jirriżulta li jekk il-Linux jispiċċa mingħajr memorja (il-pressjoni tal-memorja tidħol) u ma jkunx hemm tpartit, allura li Meta jasal il-qattiel OOM, jista 'jseħħ att ta' bilanċ bejn li titfa' paġni fil-cache tal-paġna u tiktebhom lura fuq id-diska. Dan isir minn kswapd, li b'kuraġġ jillibera kemm jista 'jkun paġni tal-memorja għal distribuzzjoni sussegwenti.
Sfortunatament, b'tagħbija I/O kbira flimkien ma 'ammont żgħir ta' memorja ħielsa, kswapd isir il-konġestjoni tas-sistema kollha, għax huma marbuta magħha kollha allokazzjonijiet (ħsarat fil-paġna) tal-paġni tal-memorja fis-sistema. Dan jista 'jdum għal żmien twil ħafna jekk il-proċessi ma jridux jużaw il-memorja aktar, iżda huma ffissati fit-tarf stess tal-abbiss OOM-qattiel.
Il-mistoqsija naturali hija: għaliex il-qattiel OOM jasal daqshekk tard? Fl-iterazzjoni attwali tiegħu, il-qattiel OOM huwa estremament stupid: se joqtol il-proċess biss meta t-tentattiv biex tiġi allokata paġna tal-memorja jfalli, i.e. jekk it-tort tal-paġna jonqos. Dan ma jseħħx għal żmien pjuttost twil, minħabba li kswapd b'kuraġġ jillibera l-paġni tal-memorja, u jwarrab il-cache tal-paġna (l-I/O tad-disk kollu fis-sistema, fil-fatt) lura fid-disk. F'aktar dettall, b'deskrizzjoni tal-passi meħtieġa biex jiġu eliminati problemi bħal dawn fil-qalba, tista 'taqra .
Din l-imġieba bil-qalba tal-Linux 4.6+.
Storja 6. Il-miżwed jeħlu fi stat Pendenti
F'xi raggruppamenti, li fihom verament ħafna imżiewed joperaw, bdejna ninnutaw li ħafna minnhom "hang" għal żmien twil ħafna fl-istat Pending, għalkemm il-kontenituri Docker infushom diġà qed jaħdmu fuq in-nodi u jistgħu jinħadmu manwalment.
Barra minn hekk, fi describe m'hemm xejn ħażin:
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 containerWara xi tħaffir, għamilna l-assunzjoni li l-kubelet sempliċement m'għandux ħin biex jibgħat l-informazzjoni kollha dwar l-istat tal-miżwed u t-testijiet tal-ħajja/prontezza lis-server tal-API.
U wara studjaw l-għajnuna, sibna l-parametri li ġejjin:
--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)Kif jidher, valuri default huma pjuttost żgħar, u f'90% ikopru l-bżonnijiet kollha... Madankollu, fil-każ tagħna dan ma kienx biżżejjed. Għalhekk, aħna nissettjaw il-valuri li ġejjin:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... u reġgħet bdiet il-kubelets, u wara rajna l-istampa li ġejja fil-graffs tas-sejħiet lis-server tal-API:
... u iva, kollox beda jtir!
PS
Għall-għajnuna tagħhom fil-ġbir ta 'bugs u t-tħejjija ta' dan l-artikolu, nesprimi l-gratitudni profonda tiegħi lill-bosta inġiniera tal-kumpanija tagħna, u speċjalment lill-kollega tiegħi mit-tim tagħna ta 'R&D Andrey Klimentyev ().
PPS
Aqra wkoll fuq il-blog tagħna:
- «".
- Kubernetes tips & tricks loop:
- «»;
- «»;
- «»;
- «".
Sors: www.habr.com