![6 sistema akats entretenigarri Kubernetes-en funtzionamenduan [eta haien konponbidea]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Kubernetes ekoizpenean erabilitako urteetan zehar, istorio interesgarri asko pilatu ditugu sistemaren osagai ezberdinetako akatsek ontzien eta ontzien funtzionamenduan eragiten zuten ondorio desatsegin edo/edo ulertezinak. Artikulu honetan ohikoen edo interesgarrienetako batzuen aukeraketa bat egin dugu. Halako egoerak topatzeko zortea izan ez arren, halako detektibe istorio laburrei buruz irakurtzea -bereziki "lehen eskukoa"- beti da interesgarria, ezta?...
1. istorioa. Supercronic eta Docker zintzilik
Klusterren batean, aldizka, izoztutako Docker bat jaso genuen, eta horrek klusterren funtzionamendu normala oztopatzen zuen. Aldi berean, honako hau ikusi zen Docker erregistroetan:
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
β¦
Errore honi buruz gehien interesatzen zaiguna mezua da: pthread_create failed: No space left on device. Azterketa azkarra azaldu zuen Docker-ek ezin zuela prozesu bat bideratu, eta horregatik izoztu egiten zen aldian behin.
Jarraipenean, hurrengo irudia bat dator gertatzen ari denari:
Beste nodo batzuetan antzeko egoera ikusten da:
Nodo berdinetan ikusiko dugu:
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>Agertu zen portaera hau podarekin lan egitearen ondorioa dela (Podetan cron lanak exekutatzeko erabiltzen dugun Go utilitatea):
_ 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>
β¦Arazoa hau da: zeregin bat superkronikoan exekutatzen denean, prozesua sortzen da ezin da behar bezala amaitu, bihurtuz .
Kontuan izan: Zehatzago esateko, prozesuak cron zereginen bidez sortzen dira, baina superkronikoa ez da hasierako sistema bat eta ezin ditu bere seme-alabek sortu zituzten prozesuak "hartu". SIGHUP edo SIGTERM seinaleak pizten direnean, ez dira haur-prozesuetara pasatzen, eta ondorioz, haur-prozesuak ez dira amaitzen eta zonbi egoeran geratzen dira. Honi guztiari buruz gehiago irakur dezakezu, adibidez, atalean .
Arazoak konpontzeko modu pare bat daude:
- Aldi baterako konponbide gisa - handitu sistemako PID-kopurua une bakarrean:
/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 - Edo abiarazi zereginak superkronikoan ez zuzenean, baina bera erabiliz , prozesuak behar bezala amaitzeko eta zonbiak sortzeko gai dena.
2. istorioa. βZombiesβ cgroup bat ezabatzean
Kubelet CPU asko kontsumitzen hasi zen:
Inori ez zaio hau gustatuko, beraz armatu ginen eta arazoari aurre egiten hasi zen. Ikerketaren emaitzak hauek izan ziren:
- Kubelet-ek CPU denboraren herena baino gehiago gastatzen du cgroup guztietatik memoria datuak ateratzen:
- Kernel-en garatzaileen posta-zerrendan aurki dezakezu . Laburbilduz, hauxe da kontua: hainbat tmpfs fitxategi eta antzeko beste gauza batzuk ez dira sistematik guztiz kentzen cgroup bat ezabatzean, deitzen dena zonbi. Lehenago edo beranduago orrialdeko cachetik ezabatuko dira, baina zerbitzarian memoria asko dago eta nukleoak ez du ezabatzean denbora galtzeko zentzurik ikusten. Horregatik pilatzen jarraitzen dute. Zergatik gertatzen da hau ere? Etengabe lanpostu berriak sortzen dituen cron-lanak dituen zerbitzari bat da, eta haiekin batera pod berriak. Horrela, cgroups berriak sortzen dira haietako edukiontzietarako, eta laster ezabatzen dira.
- Zergatik galtzen du hainbeste denbora kubeletako cAdvisor-ek? Hau erraz ikusten da exekuzio errazenarekin
time cat /sys/fs/cgroup/memory/memory.stat. Makina osasuntsu batean eragiketak 0,01 segundo irauten badu, orduan problematikoan cron02 1,2 segundo behar ditu. Gauza da cAdvisor, sysf-en datuak oso astiro irakurtzen dituena, zonbi cgroups-etan erabiltzen den memoria kontuan hartzen saiatzen dela. - Zombiak indarrez kentzeko, cacheak garbitzen saiatu gara LKML-n gomendatzen den moduan:
sync; echo 3 > /proc/sys/vm/drop_caches, - baina nukleoa konplikatuagoa izan zen eta autoa erori zen.
Zer egin? Arazoa konpontzen ari da (, eta deskribapen baterako ikus ) Linux nukleoa 4.16 bertsiora eguneratuz.
Historia 3. Systemd eta bere muntaia
Berriz ere, kubeletak baliabide gehiegi kontsumitzen ditu nodo batzuetan, baina oraingoan memoria gehiegi kontsumitzen du:
Agertu zen Ubuntu 16.04-n erabiltzen den systemd-n arazo bat dagoela eta konexiorako sortzen diren muntaketak kudeatzen direnean gertatzen da. subPath ConfigMaps edo sekretuetatik. Podak bere lana amaitu ondoren systemd zerbitzua eta bere zerbitzu-muntaia geratzen dira sisteman. Denborarekin, horietako kopuru handi bat pilatzen da. Gai honi buruzko gaiak ere badaude:
- ;
- .
...horietako azkena systemd-ko PR-ari egiten dio erreferentzia: (arazoa systemd-en - ).
Arazoa jada ez dago Ubuntu 18.04-n, baina Ubuntu 16.04 erabiltzen jarraitu nahi baduzu, baliteke gai honi buruzko gure konponbidea erabilgarria izatea.
Beraz, hurrengo DaemonSet egin dugu:
---
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... eta script hau erabiltzen du:
#!/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... eta 5 minuturo exekutatzen da lehen aipatutako superkronikoa erabiliz. Bere Dockerfile itxura hau du:
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"]4. ipuina. Lehiakortasuna lekak programatzerakoan
Ohartu zen: nodo batean leka bat jarrita badugu eta bere irudia denbora luzez ponpatzen bada, orduan nodo bera "kolpatzen" duen beste pod bat besterik ez da egingo. ez da leka berriaren irudia ateratzen hasten. Horren ordez, aurreko podaren irudia atera arte itxarongo du. Ondorioz, dagoeneko programatuta zegoen eta bere irudia minutu bakarrean deskargatu zitekeen pod bat egoeran amaituko da. containerCreating.
Ekitaldiek itxura hau izango dute:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Izarrekin bihurtzen da Erregistro motel bateko irudi bakar batek inplementazioa blokeatu dezake nodo bakoitzeko.
Zoritxarrez, ez dago egoeratik ateratzeko modu asko:
- Saiatu zure Docker Erregistroa zuzenean klusterrean edo zuzenean klusterrean erabiltzen (adibidez, GitLab Erregistroa, Nexus, etab.);
- Erabili utilitateak, esaterako .
5. istorioa. Nodoak zintzilikatzen dira memoria faltagatik
Hainbat aplikazioren funtzionamenduan zehar, nodo batek guztiz eskuragarria izateari uzten dion egoera bat ere topatu dugu: SSH-k ez du erantzuten, monitorizazio deabru guztiak erortzen dira eta orduan ez dago ezer (edo ia ezer) anomaliarik erregistroetan.
Irudietan esango dizut MongoDB funtzionatzen zuen nodo baten adibidea erabiliz.
Hau da goiko itxura to istripuak:
Eta honela - ondoren istripuak:
Jarraipenean, jauzi zorrotz bat ere badago, eta bertan nodoak erabilgarri egoteari uzten dio:
Horrela, pantaila-argazkietatik argi dago:
- Makinaren RAMa amaieratik gertu dago;
- RAMaren kontsumoan jauzi handia dago, eta ondoren makina osorako sarbidea bat-batean desgaitzen da;
- Zeregin handi bat iristen da Mongo-ra, eta horrek DBMS prozesua memoria gehiago erabiltzera eta diskotik aktiboki irakurtzera behartzen du.
Gertatzen da Linux memoria librerik gabe geratzen bada (memoriaren presioa ezartzen da) eta trukerik ez badago, orduan to OOM hiltzailea iristen denean, oreka-ekintza bat sor daiteke orriak orrialdeen cachera bota eta diskoan berriro idaztearen artean. Hau kswapd-ek egiten du, zeinak ahal den memoria orri gehien askatzen ditu ondorengo banaketarako.
Zoritxarrez, I/O karga handiarekin batera doan memoria kopuru txiki batekin, kswapd sistema osoaren botila-lepo bihurtzen da, hari lotuta daudelako guztiak sistemako memoria orrien esleipenak (orrien akatsak). Hau oso denbora luzez iraun dezake prozesuek memoria gehiago erabili nahi ez badute, baina OOM-hiltzaile amildegiaren ertzean finkatzen badira.
Galdera naturala da: zergatik dator hain berandu OOM hiltzailea? Gaur egungo iterazioan, OOM hiltzailea oso ergela da: memoria-orri bat esleitzeko saiakerak huts egiten duenean soilik akabatuko du prozesua, hau da. orriaren akatsak huts egiten badu. Hau ez da denbora luzez gertatzen, kswapd-ek ausart memoria-orriak askatzen dituelako, orrialde-cachea (sistemako disko-I/O osoa, hain zuzen ere) diskora itzultzen duelako. Xehetasun gehiagorekin, nukleoan horrelako arazoak ezabatzeko beharrezkoak diren pausoen deskribapenarekin, irakur dezakezu .
Jokabide hau Linux kernel 4.6+ekin.
6. istorioa. Podak Zain geratzen dira
Zenbait kluster, zeinetan lekak funtzionatzen ari diren, gehienak estatuan denbora luzez "zintzilikatzen" zirela nabaritzen hasi ginen. Pending, nahiz eta Docker edukiontziak beraiek dagoeneko nodoetan exekutatzen ari diren eta eskuz lan egin daitekeen.
Gainera, urtean describe ez dago ezer gaizki:
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 containerAzterketa batzuk egin ondoren, kubelet-ak ez duela astirik leken egoerari eta bizitasun/prestasun proben API zerbitzariari bidaltzeko suposatu genuen.
Eta laguntza aztertu ondoren, parametro hauek aurkitu ditugu:
--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)Ikusten denez, balio lehenetsiak nahiko txikiak dira, eta %90ean behar guztiak estaltzen dituzte... Hala ere, gure kasuan ez zen nahikoa izan. Horregatik, balio hauek ezarri ditugu:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... eta kubeletak berrabiarazi zituen, ondoren API zerbitzarirako deien grafikoetan irudi hau ikusi genuen:
... eta bai, dena hegan hasi zen!
PS
Akatsak biltzeko eta artikulu hau prestatzeko emandako laguntzagatik, nire esker ona adierazten diet gure konpainiako ingeniari ugariei, eta bereziki Andrey Klimentyev I+G taldeko nire lankideari ().
PPS
Irakurri ere gure blogean:
- Β«'.
- Kubernetes-en aholkuak eta trikimailuak:
- «»;
- «»;
- «»;
- Β«'.
Iturria: www.habr.com