![6 fhabht córais siamsúil i bhfeidhmiú Kubernetes [agus a réiteach]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Thar na blianta a bhain úsáid as Kubernetes i dtáirgeadh, tá go leor scéalta suimiúla bailithe againn faoin gcaoi ar eascair iarmhairtí míthaitneamhacha agus/nó dothuigthe ag fabhtanna i gcomhpháirteanna córais éagsúla a chuir isteach ar oibriú coimeádán agus pods. San Airteagal seo rinneamar rogha de chuid de na cinn is coitianta nó is suimiúla. Fiú mura mbíonn an t-ádh leat dul i ngleic le cásanna den sórt sin, bíonn sé suimiúil i gcónaí léamh faoi ghearrscéalta den sórt sin - go háirithe “go pearsanta” - nach bhfuil?
Scéal 1. Supercronic agus Docker ar crochadh
Ar cheann de na braislí, fuair muid Docker reoite go tréimhsiúil, rud a chuir isteach ar ghnáthghníomhú an bhraisle. Ag an am céanna, breathnaíodh an méid seo a leanas i logaí 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
…
Is é an rud is mó a bhfuil spéis againn san earráid seo ná an teachtaireacht: pthread_create failed: No space left on device. Staidéar cursory mhínigh sé nach féidir le Docker an próiseas a fhorc, agus is é sin an fáth go mbíonn sé “hangs” go tréimhsiúil.
I monatóireacht, comhfhreagraíonn an méid atá ag tarlú leis an bpictiúr seo a leanas:
Breathnaítear staid den chineál céanna ar nóid eile:
Ar na nóid chéanna feicimid:
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>Iompaigh sé amach go bhfuil an iompar mar thoradh ar obair an pod le (áisiúlacht Go a úsáidimid chun jabanna cron a rith i gcódanna):
_ 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>
…Is í an fhadhb atá leis seo: nuair a chuirtear tús le tasc i supercronic, an próiseas a sceith sé ní féidir a chomhlánú i gceart, ag casadh isteach .
Tabhair faoi deara: Le bheith níos cruinne, is iad tascanna cron a dhéanann próisis a sceith, ach ní córas init é supercronic agus ní féidir leis na próisis a "ghlacadh" a rinne a leanaí. Nuair a ardaítear comharthaí SIGHUP nó SITERM, ní chuirtear ar aghaidh iad chuig próisis an linbh, rud a fhágann nach bhfoirceannann próisis an linbh agus go bhfanann siad i stádas zombie. Is féidir leat tuilleadh a léamh faoi seo go léir, mar shampla, i .
Tá cúpla bealach ann chun fadhbanna a réiteach:
- Mar réiteach sealadach oibre - cuir le líon na PIDanna sa chóras ag pointe amháin ama:
/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 - Nó tascanna a sheoladh i supercronic ní go díreach, ach ag baint úsáide as an gcéanna , atá in ann próisis gracefully fhoirceannadh agus ní sceathraí zombies.
Scéal 2. “Zombies” agus cgroup á scriosadh
Thosaigh Kubelet ag ithe go leor LAP:
Ní maith le haon duine é seo, agus mar sin armálamar sinn féin agus thosaigh sé ag déileáil leis an bhfadhb. Bhí torthaí an imscrúdaithe mar seo a leanas:
- Caitheann Kubelet níos mó ná an tríú cuid den am LAP ag tarraingt sonraí cuimhne ó na grúpaí go léir:
- I liosta seoltaí na forbróirí eithne, is féidir leat a fháil . I mbeagán focal, is é an pointe go ní bhaintear comhaid tmpfs éagsúla agus rudaí eile dá samhail go hiomlán as an gcóras nuair a scriosadh cgroup, mar a thugtar air zombie. Luath nó mall scriosfar as an taisce leathanaigh iad, ach tá go leor cuimhne ar an bhfreastalaí agus ní fheiceann an eithne an pointe ag cur am amú ar iad a scriosadh. Sin an fáth go gcoinníonn siad ag carnadh suas. Cén fáth go bhfuil sé seo ag tarlú fiú? Is freastalaí é seo le post cron a chruthaíonn poist nua i gcónaí, agus pods nua leo. Mar sin, cruthaítear cgroups nua le haghaidh coimeádáin iontu, a scriostar go luath.
- Cén fáth a gcuireann cAdvisor in kubelet an oiread sin ama amú? Is furasta é seo a fheiceáil leis an bhforghníomhú is simplí
time cat /sys/fs/cgroup/memory/memory.stat. Más rud é ar mheaisín sláintiúil a thógann an oibríocht 0,01 soicind, ansin ar an cron02 fhadhb a thógann sé 1,2 soicind. Is é an rud go ndéanann cAdvisor, a léann sonraí ó sysfs go han-mhall, iarracht an chuimhne a úsáidtear i ngrúpaí zombie a chur san áireamh. - Chun na zombies a bhaint go héigeantach, rinneamar iarracht na caches a ghlanadh mar atá molta ag LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - ach an croí iompaigh amach a bheith níos casta agus crochadh an carr.
Cad atá le déanamh? Tá an fhadhb á réiteach, agus féach cur síos i ) tríd an eithne Linux a nuashonrú go leagan 4.16.
Stair 3. Systemd agus a mount
Arís, ídíonn kubelet an iomarca acmhainní ar roinnt nóid, ach an uair seo is mó cuimhne é:
Tharla sé go bhfuil fadhb ann i systemd a úsáidtear i Ubuntu 16.04, agus tarlaíonn sé agus gléasanna á mbainistiú a chruthaítear le haghaidh ceangail subPath ó ConfigMap'ov nó secret'ov. Tar éis múchadh pod fanann an tseirbhís chórasach agus a gléas seirbhíse sa chóras. Le himeacht ama, carnann siad méid ollmhór. Tá ceisteanna fiú ar an ábhar seo:
- ;
- .
... sa cheann deireanach de a dtagraíonn siad don PR in systemd: (eisiúint i systemd - ).
Níl an fhadhb ann a thuilleadh in Ubuntu 18.04, ach más mian leat leanúint ar aghaidh ag baint úsáide as Ubuntu 16.04, b'fhéidir go mbeidh ár gcuid oibre ar an ábhar seo úsáideach duit.
Mar sin, tá an DaemonSet seo a leanas déanta againn:
---
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... agus úsáideann sé an script seo:
#!/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... agus ritheann sé gach 5 nóiméad le cabhair ón supercronic a luadh cheana. Breathnaíonn a Dockerfile mar seo:
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"]Scéal 4. Iomaíochas agus pods á sceidealú
Tugadh faoi deara: má tá pod againn curtha ar nód agus a íomhá a phumpáil amach ar feadh i bhfad, ansin beidh pod eile a "bhuail" an nód céanna go simplí. Ní thosaíonn a tharraingt ar an íomhá ar an pod nua. Ina áit sin, fanann sé go ‘tarraingítear’ íomhá an phod roimhe seo. Mar thoradh air sin, beidh pod a bhí pleanáilte cheana féin agus a bhféadfaí a íomhá a íoslódáil i díreach nóiméad ag críochnú sa stádas ar feadh i bhfad. containerCreating.
Breathnóidh na himeachtaí ar rud éigin mar seo:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Casadh sé amach go is féidir le híomhá amháin ó chlár mall bac a chur ar imscaradh chuig an nód.
Ar an drochuair, níl go leor bealaí amach as an gcás:
- Déan iarracht do Chlárlann Docker a úsáid go díreach sa bhraisle nó go díreach leis an mbraisle (m.sh. Clárlann GitLab, Nexus, etc.);
- Úsáid fóntais mar .
Scéal 5. Tá nóid ar crochadh mar gheall ar easpa cuimhne
Le linn feidhmiú na n-iarratas éagsúla, thángamar ar chás freisin ina scoireann nód go hiomlán de bheith inrochtana: ní fhreagraíonn SSH, titeann gach deamhan monatóireachta amach, agus ansin níl aon rud (nó beagnach aon rud) aimhrialta sna logaí.
Inseoidh mé duit i bpictiúir ag baint úsáide as an sampla de nód amháin inar fheidhmigh MongoDB.
Is é seo an chuma atá ar bharr na craoibhe до timpistí:
Agus mar seo - tar éis timpistí:
I monatóireacht, tá léim ghéar ann freisin, ag a scoirfidh an nód de bheith ar fáil:
Mar sin, ó na screenshots tá sé soiléir:
- Tá an RAM ar an meaisín gar do rith amach;
- Tá léim ghéar ar thomhaltas RAM, agus ina dhiaidh sin tá rochtain ar an meaisín iomlán faoi mhíchumas go tobann;
- Sroicheann tasc mór Mongo, rud a fhágann go n-úsáideann an próiseas DBMS níos mó cuimhne agus go léann sé go gníomhach ón diosca.
Tarlaíonn sé má ritheann Linux as cuimhne in aisce (socraíonn brú cuimhne isteach) agus nach bhfuil babhtáil ann, ansin до Nuair a shroicheann an marfóir OOM, d'fhéadfadh gníomh cothromaíochta teacht chun cinn idir leathanaigh a chaitheamh isteach sa taisce leathanaigh agus iad a scríobh ar ais ar diosca. Déanann kswapd é seo, a shaorann go cróga an oiread leathanaigh chuimhne agus is féidir lena ndáileadh ina dhiaidh sin.
Ar an drochuair, le ualach mór I/O mar aon le méid beag cuimhne saor in aisce, thiocfaidh chun bheith kswapd an tranglam ar an gcóras iomlán, toisc go bhfuil siad ceangailte leis go léir leithdháiltí (lochtanna leathanaigh) de leathanaigh chuimhne sa chóras. Féadfaidh sé seo dul ar aghaidh ar feadh tréimhse an-fhada mura bhfuil na próisis ag iarraidh cuimhne a úsáid níos mó, ach iad a shocrú ar imeall an duibheagáin killer OOM.
Tá an cheist nádúrtha: cén fáth a thagann an killer OOM chomh déanach? Ina atriall faoi láthair, tá an killer OOM thar a bheith dúr: ní mharóidh sé an próiseas ach amháin nuair a theipeann ar an iarracht leathanach cuimhne a leithdháileadh, i.e. má éiríonn le locht leathanach le hearráid. Ní tharlaíonn sé seo fada go leor mar go scaoileann kswapd leathanaigh chuimhne go bríomhar trí thaisce na leathanach (an diosca I/O ar fad ar an gcóras, go bunúsach) a shruthlú ar ais go diosca. Níos mine, le cur síos ar na céimeanna is gá chun deireadh a chur le fadhbanna den sórt sin san eithne, is féidir leat léamh .
An iompar seo le eithne Linux 4.6+.
Scéal 6. Téann pods i bhfostú sa riocht atá ar feitheamh
I roinnt braislí, ina bhfuil go leor pods ag feidhmiú i ndáiríre, thosaigh muid ag tabhairt faoi deara go bhfuil an chuid is mó acu “ar crochadh” ar feadh tréimhse an-fhada sa stát. Pending, cé go bhfuil na coimeádáin Docker iad féin ag rith ar na nóid cheana féin agus is féidir iad a oibriú de láimh.
Thairis sin, i describe níl aon rud mícheart:
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 containerTar éis tochailt timpeall, rinneamar an toimhde nach bhfuil an t-am ag an kubelet an fhaisnéis go léir faoi staid na pods, samplaí beocht / ullmhachta a sheoladh chuig an bhfreastalaí API.
Agus tar éis staidéar a dhéanamh ar chabhair, fuaireamar na paraiméadair seo a leanas:
--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)Mar a fheictear, tá luachanna réamhshocraithe sách beag, agus i 90% clúdaíonn siad gach riachtanas ... Mar sin féin, inár gcás, ní raibh sé seo go leor. Mar sin, socróimid na luachanna seo a leanas:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... agus na kubelets a atosú, agus ina dhiaidh sin chonaic muid an pictiúr seo a leanas ar na graif chun rochtain a fháil ar an bhfreastalaí API:
... agus tá, thosaigh gach rud ag eitilt!
PS
Le cabhair a fháil maidir le fabhtanna a bhailiú agus an t-alt a ullmhú, ba mhaith liom mo bhuíochas a ghabháil le hinnealtóirí iomadúla ár gcuideachta, agus go háirithe lenár gcomhghleacaí ónár bhfoireann T&F Andrey Klimentyev ().
PSP
Léigh freisin ar ár mblag:
- «'.
- Lúb leideanna & cleasanna Kubernetes:
- «";
- «";
- «";
- «'.
Foinse: will.com