![6 хатогиҳои системаи фароғатӣ дар кори Kubernetes [ва ҳалли онҳо]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Дар тӯли солҳои истифодаи Kubernetes дар истеҳсолот, мо бисёр ҳикояҳои ҷолибро дар бораи он, ки чӣ гуна хатогиҳо дар ҷузъҳои гуногуни система ба оқибатҳои ногувор ва/ё нофаҳмо оварда расониданд, ки ба кори контейнерҳо ва қубурҳо таъсир мерасонанд, ҷамъ овардаем. Дар ин мақола мо баъзе аз маъмултарин ё ҷолибро интихоб кардем. Ҳатто агар шумо ҳеҷ гоҳ ба ин гуна ҳолатҳо дучор нашавед ҳам, хондан дар бораи чунин ҳикояҳои детективӣ, махсусан "даст аз дасти аввал" - ҳамеша ҷолиб аст, ҳамин тавр не?..
Ҳикояи 1. Supercronic ва Docker овезон
Дар яке аз кластерҳо мо давра ба давра Docker-и яхкардашударо мегирем, ки ба кори муқаррарии кластер халал мерасонад. Ҳамзамон, дар гузоришҳои 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
…
Он чизе, ки моро дар бораи ин хато бештар ҷалб мекунад, ин паём аст: pthread_create failed: No space left on device. Омӯзиши зуд фаҳмонд, ки Доккер равандро ба ҳам зада наметавонад, аз ин рӯ он давра ба давра ях мезад.
Ҳангоми мониторинг, тасвири зерин ба рӯйдод мувофиқат мекунад:
Чунин вазъият дар дигар гиреҳҳо мушоҳида мешавад:
Дар ҳамон гиреҳҳо мо мебинем:
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>Маълум шуд, ки ин рафтор окибати кор бо подда мебошад (василаи Go, ки мо барои иҷрои корҳои cron дар подкҳо истифода мебарем):
_ 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>
…Мушкилот дар он аст: вақте ки супориш дар суперкроника иҷро мешавад, раванд аз он тавлид мешавад дуруст хотима дода наметавонад, табдил меёбад .
эрод гирифтан: Аниқтараш, равандҳо аз ҷониби вазифаҳои cron тавлид мешаванд, аммо суперкроник системаи ибтидоӣ нест ва наметавонад равандҳоеро, ки фарзандонаш тавлид кардаанд, "қабул" кунанд. Вақте ки сигналҳои SIGHUP ё SIGTERM баланд мешаванд, онҳо ба равандҳои кӯдак интиқол дода намешаванд, ки дар натиҷа равандҳои кӯдак қатъ намешаванд ва дар ҳолати зомби боқӣ мемонанд. Шумо метавонед дар бораи ин ҳама бештар хонед, масалан, дар .
Якчанд роҳҳои ҳалли мушкилот вуҷуд доранд:
- Ҳамчун як роҳи ҳалли муваққатӣ - зиёд кардани шумораи PID дар система дар як лаҳза:
/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 - Ё вазифаҳоро дар суперкроник на мустақиман, балки бо истифода аз ҳамон , ки қодир аст равандҳоро дуруст қатъ кунад ва зомбиҳоро тавлид накунад.
Ҳикояи 2. "Зомбиҳо" ҳангоми нест кардани гурӯҳ
Кубелет ба истеъмоли CPU бисёр оғоз кард:
Ин ба касе писанд нахохад шуд, мо худамонро мусаллах кардем ва ба халли масъала шуруъ намуд. Натичаи тафтиш чунин буд:
- Kubelet зиёда аз сеяки вақти CPU-ро барои гирифтани маълумоти хотира аз ҳама гурӯҳҳо сарф мекунад:
- Дар рӯйхати почтаи таҳиягарони ядро шумо метавонед пайдо кунед . Хулоса, нукта ба ин бармеояд: файлҳои гуногуни tmpfs ва дигар чизҳои шабеҳ аз система пурра нест карда намешаванд ҳангоми нест кардани як гурӯҳ, ба ном zombie. Дер ё зуд онҳо аз кэши саҳифа нест карда мешаванд, аммо дар сервер хотираи зиёд мавҷуд аст ва ядро маҳалли беҳуда сарф кардани вақтро барои нест кардани онҳо намебинад. Аз ин рӯ, онҳо ҷамъ мешаванд. Чаро ин ҳатто рӯй дода истодааст? Ин сервери дорои ҷойҳои кори cron аст, ки доимо ҷойҳои нави корӣ ва бо онҳо подкастҳои нав эҷод мекунад. Ҳамин тариқ, гурӯҳҳои нав барои контейнерҳо дар онҳо таъсис дода мешаванд, ки ба зудӣ нест карда мешаванд.
- Чаро cAdvisor дар kubelet вақти зиёдро сарф мекунад? Инро бо соддатарин иҷроиш дидан осон аст
time cat /sys/fs/cgroup/memory/memory.stat. Агар дар мошини солим амалиёт 0,01 сонияро дар бар гирад, пас дар cron02 проблемавӣ 1,2 сонияро мегирад. Гап дар он аст, ки cAdvisor, ки маълумотро аз sysfs хеле суст мехонад, кӯшиш мекунад, ки хотираи дар гурӯҳҳои зомби истифодашавандаро ба назар гирад. - Барои маҷбуран нест кардани зомбиҳо, мо кӯшиш кардем кэшҳоро тавре, ки дар LKML тавсия шудааст, тоза кунем:
sync; echo 3 > /proc/sys/vm/drop_caches, - вале ядро мураккабтар шуда, машинаро барбод дод.
Чӣ бояд кард? Мушкилот ҳал карда мешавад (, ва барои тавсиф нигаред ) навсозии ядрои Linux ба версияи 4.16.
Таърихи 3. Systemd ва монтажи он
Боз ҳам, кубелет дар баъзе гиреҳҳо захираҳои зиёдро истеъмол мекунад, аммо ин дафъа хотираи аз ҳад зиёдро истеъмол мекунад:
Маълум шуд, ки дар системае, ки дар Ubuntu 16.04 истифода мешавад, мушкилот вуҷуд дорад ва он ҳангоми идоракунии васлҳое, ки барои пайвастшавӣ сохта шудаанд, рух медиҳад. subPath аз ConfigMap ё махфӣ. Баъди ба охир расидани подбор кори худ хидмати systemd ва васлаки хидматрасонии он боқӣ мемонад дар система. Бо мурури замон шумораи зиёди онҳо ҷамъ мешаванд. Дар ин мавзӯъ ҳатто масъалаҳо мавҷуданд:
- ;
- .
... охирини он ба PR дар systemd дахл дорад: (масъала дар systemd - ).
Мушкилот дигар дар Ubuntu 18.04 вуҷуд надорад, аммо агар шумо хоҳед, ки истифодаи Ubuntu 16.04-ро идома диҳед, шумо метавонед роҳи ҳалли моро дар ин мавзӯъ муфид ёбед.
Ҳамин тавр, мо 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... ва он скрипти зеринро истифода мебарад:
#!/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... ва он ҳар 5 дақиқа бо истифода аз суперкроникаи қаблан зикршуда кор мекунад. Dockerfile он чунин менамояд:
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. Рақобат ҳангоми банақшагирии pods
Муайян карда шуд, ки: агар мо дар болои гирех як подка гузошта бошем ва тасвири он ба муддати хеле дароз берун карда шавад, пас дигар подразделе, ки ба як гирех «задааст» бошад. ба кашидани симои подшохи нав шуруъ намекунад. Ба ҷои ин, он интизор мешавад, ки тасвири пештара кашида шавад. Дар натиҷа, як паҳлӯе, ки аллакай ба нақша гирифта шуда буд ва тасвири он метавонад дар як дақиқа зеркашӣ карда шавад, дар ҳолати containerCreating.
Ҳодисаҳо чунин хоҳанд буд:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Ин рӯй медиҳад як тасвири ягона аз феҳристи суст метавонад густаришро манъ кунад дар як гиреҳ.
Мутаассифона, роҳҳои зиёде аз вазъият вуҷуд надоранд:
- Кӯшиш кунед, ки реестри Docker-и худро мустақиман дар кластер ё бевосита бо кластер истифода баред (масалан, Registry GitLab, Nexus ва ғайра);
- Утилитаҳоро истифода баред, ба монанди .
Ҳикояи 5. Гиреҳҳо аз сабаби набудани хотира овезон мешаванд
Ҳангоми кор кардани замимаҳои гуногун, мо инчунин бо вазъияте дучор шудем, ки гиреҳ комилан дастрасиро қатъ мекунад: SSH ҷавоб намедиҳад, ҳама демонҳои назоратӣ меафтанд ва он гоҳ дар гузоришҳо ҳеҷ чизи аномалиявӣ (ё қариб ҳеҷ чиз) вуҷуд надорад.
Ман ба шумо дар тасвирҳо бо мисоли як гиреҳе, ки дар он MongoDB кор мекард, мегӯям.
Ин аст он чизе ки дар боло ба назар мерасад ба садамаҳо:
Ва монанди ин - после садамаҳо:
Дар мониторинг инчунин як ҷаҳиши шадид ба назар мерасад, ки дар он гиреҳ мавҷудияти худро қатъ мекунад:
Ҳамин тариқ, аз скриншотҳо маълум аст, ки:
- Дар RAM дар мошини наздик ба охир аст;
- Дар истеъмоли RAM як ҷаҳиши якбора вуҷуд дорад, ки пас аз он дастрасӣ ба тамоми мошин ногаҳон ғайрифаъол мешавад;
- Вазифаи калон ба Mongo меояд, ки раванди DBMS-ро маҷбур мекунад, ки хотираи бештарро истифода барад ва аз диск фаъолона хонад.
Маълум мешавад, ки агар Linux аз хотираи холӣ тамом шавад (фишори хотира ба вуҷуд меояд) ва мубодила вуҷуд надошта бошад, пас ба Вақте ки қотили OOM меояд, метавонад амали мувозинатӣ байни партофтани саҳифаҳо ба кеши саҳифа ва навиштани онҳо ба диск ба амал ояд. Ин аз ҷониби kswapd анҷом дода мешавад, ки далерона саҳифаҳои хотираро то ҳадди имкон барои паҳнкунии минбаъда озод мекунад.
Мутаассифона, бо сарбории калони воридот ва баромад бо миқдори ками хотираи озод, kswapd монеаи тамоми система мегардад, зеро онхо ба он вобастаанд ҳама тақсимоти (айбҳои саҳифа) саҳифаҳои хотира дар система. Ин метавонад барои муддати хеле дароз идома ёбад, агар равандҳо дигар хотираро истифода набаранд, аммо дар канори вартаи OOM-қотил собит карда шаванд.
Саволи табии ин аст: чаро қотили OOM ин қадар дер меояд? Дар итератсияи кунунии худ қотили OOM бениҳоят аблаҳ аст: он равандро танҳо вақте мекушад, ки кӯшиши ҷудо кардани саҳифаи хотира ноком мешавад, яъне. агар хатогии саҳифа ноком шавад. Ин муддати тӯлонӣ рӯй намедиҳад, зеро kswapd далерона саҳифаҳои хотираро озод мекунад ва кэши саҳифаро (дар тамоми диски I/O дар система) ба диск бармегардонад. Ба таври муфассал, бо тавсифи қадамҳои зарурӣ барои бартараф кардани чунин мушкилот дар ядро, шумо метавонед хонед .
Ин рафтор бо ядрои Linux 4.6+.
Ҳикояи 6. Подҳо дар ҳолати интизорӣ мемонанд
Дар баъзе кластерҳо, ки дар онҳо воқеан ҳам пораҳои зиёд амал мекунанд, мо пай бурдем, ки аксарияти онҳо дар муддати хеле тӯлонӣ дар давлат “овехта” мешаванд. Pending, гарчанде ки худи контейнерҳои Docker аллакай дар гиреҳҳо кор мекунанд ва бо онҳо дастӣ кор кардан мумкин аст.
Гайр аз ин, дар describe чизе нест:
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 containerПас аз чанд кофтуков, мо тахмин кардем, ки кубелет барои фиристодани ҳама маълумот дар бораи ҳолати поддонҳо ва санҷишҳои зинда / омодагӣ ба сервери API вақт надорад.
Ва пас аз омӯзиши кӯмак, мо параметрҳои зеринро пайдо кардем:
--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)Тавре дида мешавад, арзишҳои пешфарз хеле хурд мебошанд, 90 фоиз бошад, тамоми эхтиёчотро конеъ мегардонанд... Вале дар мо ин кифоя набуд. Аз ин рӯ, мо арзишҳои зеринро муқаррар мекунем:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... ва кубелетҳоро аз нав оғоз кардем, ки пас аз он мо дар графикҳои зангҳо ба сервери API расми зеринро дидем:
... ва ҳа, ҳама чиз ба парвоз оғоз кард!
PS
Барои кӯмакашон дар ҷамъоварии хатогиҳо ва таҳияи ин мақола, ман ба муҳандисони сершумори ширкати мо ва махсусан ба ҳамкасби худ аз гурӯҳи тадқиқотии мо Андрей Климентьев ().
PPS
Инчунин дар блоги мо хонед:
- «".
- Маслиҳатҳо ва ҳилаҳои ҳалқаи Kubernetes:
- «»;
- «»;
- «»;
- «".
Манбаъ: will.com