![6 bibikely rafitra mampiala voly amin'ny fiasan'ny Kubernetes [sy ny vahaolana amin'izy ireo]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Nandritra ny taona maro nampiasana ny Kubernetes tamin'ny famokarana, dia nanangona tantara mahaliana maro momba ny fomba nitondran'ny bibikely ao amin'ny singa rafitra isan-karazany amin'ny vokatra tsy mahafinaritra sy/na tsy takatry ny saina miantraika amin'ny fiasan'ny container sy pods. Ato amin'ity lahatsoratra ity dia nanao fifantenana ny sasany amin'ireo mahazatra indrindra na mahaliana. Na dia tsy tsara vintana amin'ny toe-javatra toy izany aza ianao, dia mahaliana foana ny famakiana tantara fohy momba ny mpitsongo - indrindra fa ny "tanana voalohany", sa tsy izany?
Tantara 1. Supercronic sy Docker mihantona
Amin'ny iray amin'ireo cluster dia nahazo Docker mangatsiaka izahay, izay manelingelina ny fiasan'ny cluster. Tamin'izany fotoana izany dia voamarika tao amin'ny logs Docker ireto manaraka ireto:
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
β¦
Ny tena mahaliana anay amin'ity fahadisoana ity dia ny hafatra: pthread_create failed: No space left on device. Fianarana haingana nanazava fa i Docker dia tsy afaka manao dingana iray, ka izany no mahatonga azy io ho mangatsiaka tsindraindray.
Amin'ny fanaraha-maso dia mifanaraka amin'ny zava-mitranga ity sary manaraka ity:
Misy toe-javatra mitovy amin'izany hita amin'ny nodes hafa:
Ao amin'ireo nodes ireo ihany no hitantsika:
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>Hita fa vokatry ny fiasan'ny pod io fihetsika io (fampiasana Go izay ampiasainay hampandehanana asa cron amin'ny pods):
_ 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>
β¦Ny olana dia izao: rehefa misy asa atao amin'ny supercronic, ny fizotrany dia niteraka azy tsy afaka mifarana tsara, mivadika ho .
fanamarihana: Raha ny marimarina kokoa, ny fizotran'ny asa dia ateraky ny asa cron, fa ny supercronic dia tsy rafitra init ary tsy afaka "manangana" ireo dingana naterak'ireo zanany. Rehefa miakatra ny mari-pamantarana SIGHUP na SIGTERM dia tsy ampitaina amin'ny fizotry ny zaza izy ireo, ka tsy mitsahatra ny fizotran'ny zaza ary mijanona amin'ny sata zombie. Azonao atao ny mamaky bebe kokoa momba izany rehetra izany, ohatra, ao amin'ny .
Misy fomba roa hamahana olana:
- Amin'ny maha vahaolana vonjimaika - ampitomboy ny isan'ny PID ao amin'ny rafitra amin'ny fotoana iray:
/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 - Na manomboka asa amin'ny supercronic tsy mivantana, fa mampiasa mitovy , izay afaka mamarana ny fizotran'ny fomba tsara ary tsy miteraka zombies.
Tantara 2. "Zombies" rehefa mamafa cgroup
Nanomboka nandany CPU betsaka i Kubelet:
Tsy hisy ho tia anβizany, ka nitam-piadiana izahay ary nanomboka niatrika ny olana. Toy izao ny vokatry ny fanadihadiana:
- Kubelet dia mandany mihoatra ny ampahatelon'ny fotoanan'ny CPU-ny misintona angona fitadidiana avy amin'ny cgroup rehetra:
- Ao amin'ny lisitry ny mailin'ny mpamorona kernel dia azonao jerena . Raha fintinina dia midina amin'izao ny hevitra: Ny rakitra tmpfs isan-karazany sy ny zavatra hafa mitovy amin'izany dia tsy esorina tanteraka amin'ny rafitra rehefa mamafa cgroup dia ilay atao hoe Zombie. Na ho ela na ho haingana dia ho voafafa amin'ny cache pejy izy ireo, saingy betsaka ny fahatsiarovana ao amin'ny server ary tsy hitan'ny kernel ny antony handany fotoana amin'ny famafana azy ireo. Izany no mahatonga azy ireo tsy mitsaha-mitombo. Nahoana no mitranga izany? Ity dia mpizara misy asa cron izay mamorona asa vaovao tsy tapaka, ary miaraka amin'izy ireo pods vaovao. Noho izany dia misy cgroups vaovao noforonina ho an'ny kaontenera ao anatiny, izay voafafa tsy ho ela.
- Nahoana no mandany fotoana be ny cAdvisor ao amin'ny kubelet? Mora hita izany amin'ny famonoana tsotra indrindra
time cat /sys/fs/cgroup/memory/memory.stat. Raha amin'ny milina salama ny fandidiana dia 0,01 segondra, dia amin'ny cron02 misy olana dia 1,2 segondra. Ny zava-misy dia ny cAdvisor, izay mamaky ny angon-drakitra avy amin'ny sysfs miadana, dia manandrana mandinika ny fahatsiarovana ampiasaina amin'ny cgroups zombie. - Mba hanesorana an-keriny ny zombies, dia nanandrana nanala ny cache araka ny soso-kevitra ao amin'ny LKML izahay:
sync; echo 3 > /proc/sys/vm/drop_caches, - fa ny kernel dia lasa sarotra kokoa ary nandona ny fiara.
Ny hatao? Voavaha ny olana (, ary raha mila fanazavana dia jereo ) manavao ny kernel Linux amin'ny version 4.16.
Tantara 3. Systemd sy ny tendrombohitra
Averina indray, mandany loharanon-karena be loatra amin'ny nodes sasany ny kubelet, fa amin'ity indray mitoraka ity dia mandany fitadidiana be loatra:
Hita fa misy olana amin'ny systemd ampiasaina ao amin'ny Ubuntu 16.04, ary mitranga izany rehefa mitantana mounts izay noforonina ho an'ny fifandraisana. subPath avy amin'ny ConfigMap's na secret's. Rehefa vita ny asany ny pod mijanona ny serivisy systemd sy ny serivisy serivisy amin'ny rafitra. Rehefa mandeha ny fotoana, dia maro amin'izy ireo no miangona. Misy olana mihitsy aza momba ity lohahevitra ity:
- ;
- .
...ny farany dia manondro ny PR ao amin'ny systemd: (olana ao amin'ny systemd- ).
Tsy misy intsony ny olana ao amin'ny Ubuntu 18.04, fa raha te hanohy ny fampiasana Ubuntu 16.04 ianao dia mety ho hitanao fa mahasoa ity lohahevitra ity.
Noho izany dia nanao ity DaemonSet manaraka ity izahay:
---
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... ary mampiasa ity script manaraka ity:
#!/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... ary mandeha isaky ny 5 minitra amin'ny fampiasana ny supercronic voalaza teo aloha. Ny Dockerfile dia toa izao:
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"]Tantara 4. Fifaninanana rehefa manao fandaharam-potoana pods
Tsikaritra fa: raha manana pod apetraka eo amin'ny node iray isika ary mivoaka mandritra ny fotoana maharitra ny sariny, dia pod iray hafa izay "mikapoka" ilay node iray ihany tsy manomboka misintona ny sarin`ny pod vaovao. Miandry kosa izy mandra-pisintona ny sarin'ny pod teo aloha. Vokatr'izany, ny pod izay efa voalahatra ary ny sary azo alaina tao anatin'ny iray minitra monja dia hiafara amin'ny satan'ny containerCreating.
Ny hetsika dia ho toy izao manaraka izao:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Mipoitra izany sary tokana avy amin'ny rejisitra miadana dia afaka manakana ny fandefasana isaky ny node.
Mampalahelo fa tsy misy fomba maro hivoahana amin'ny toe-javatra:
- Andramo ny mampiasa ny Docker Registry mivantana ao amin'ny cluster na mivantana miaraka amin'ny cluster (ohatra, GitLab Registry, Nexus, sns.);
- MampiasΓ fitaovana toy ny .
Tantara 5. Node mihantona noho ny tsy fahampian'ny fitadidiana
Nandritra ny fampandehanana ny fampiharana isan-karazany, dia nifanena ihany koa ny toe-javatra iray izay nitsahatra tanteraka ny node iray: tsy mamaly ny SSH, mianjera ny daemon fanaraha-maso rehetra, ary avy eo tsy misy na inona na inona (na saika tsy misy na inona na inona) ao anaty logs.
Hilaza aminao amin'ny sary aho amin'ny fampiasana ny ohatry ny node iray izay niasan'ny MongoDB.
Toy izao ny endriky ny atop Π΄ΠΎ loza:
Ary toy izany - ΠΏΠΎΡΠ»Π΅ loza:
Amin'ny fanaraha-maso dia misy ihany koa ny fitsambikinana mafy, izay tsy misy intsony ny node:
Noho izany, avy amin'ny pikantsary dia mazava fa:
- Ny RAM amin'ny milina dia manakaiky ny farany;
- Misy fitsambikinana mafy amin'ny fanjifana RAM, ary avy eo dia tapaka tampoka ny fidirana amin'ny milina manontolo;
- Misy asa lehibe tonga ao amin'ny Mongo, izay manery ny fizotran'ny DBMS hampiasa fitadidiana bebe kokoa sy hamaky mavitrika avy amin'ny kapila.
Hita fa raha lany fahatsiarovana maimaim-poana ny Linux (miditra ny tsindry fitadidiana) ary tsy misy swap, dia Π΄ΠΎ Rehefa tonga ny mpamono OOM dia mety hisy fifandanjana eo anelanelan'ny fanipazana pejy ao amin'ny cache pejy sy ny fanoratana azy ireo hiverina amin'ny kapila. Izany dia ataon'ny kswapd, izay manafaka amin-kerim-po ny pejy fitadidiana betsaka araka izay azo atao ho an'ny fizarana manaraka.
Indrisy anefa, miaraka amin'ny entana I/O lehibe miampy fahatsiarovana maimaim-poana kely, Ny kswapd dia lasa sakana amin'ny rafitra manontolo, satria mifamatotra aminβizany izy ireo ny rehetra fanomezan-dΓ lana (pejy diso) ny pejy fitadidiana ao amin'ny rafitra. Mety hitohy mandritra ny fotoana maharitra izany raha tsy te hampiasa fitadidiana intsony ny fizotrany, fa raikitra eo amin'ny sisin'ny lavaka OOM-killer.
Ny fanontaniana voajanahary dia hoe: maninona no tonga tara be ilay mpamono OOM? Amin'ny famerimberenana amin'izao fotoana izao, ny mpamono OOM dia tena adala: hamono ny dingana ihany izy rehefa tsy nahomby ny fikasana hanokana pejy fahatsiarovana, i.e. raha tsy mahomby ny pejy. Tsy mitranga izany mandritra ny fotoana maharitra, satria ny kswapd dia manafaka amin-kerim-po ny pejy fitadidiana, manary ny cache pejy (ny kapila I/O manontolo ao amin'ny rafitra, raha ny marina) miverina amin'ny kapila. Amin'ny antsipiriany bebe kokoa, miaraka amin'ny famaritana ny dingana ilaina amin'ny famongorana ny olana toy izany ao amin'ny kernel, azonao vakiana .
Ity fihetsika ity miaraka amin'ny Linux kernel 4.6+.
Tantara 6. Miraikitra amin'ny fanjakana miandry ny pods
Ao amin'ny cluster sasany, izay misy pods maro be miasa, dia nanomboka nahatsikaritra izahay fa ny ankamaroan'izy ireo dia "mihantona" mandritra ny fotoana maharitra ao amin'ny fanjakana. Pending, na dia efa mandeha amin'ny nodes aza ny container Docker ary azo ampiasaina amin'ny tanana.
Ankoatra izany, in describe tsy misy maharatsy:
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 containerTaorian'ny fandavahana sasany dia nihevitra izahay fa ny kubelet dia tsy manam-potoana handefasana ny fampahalalana rehetra momba ny toetry ny pods sy ny fitsapam-piainana / fahavononana amin'ny mpizara API.
Ary rehefa avy nianatra fanampiana izahay dia nahita ireto mason-tsivana manaraka ireto:
--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)Araka ny hita, kely ny sanda default, ary amin'ny 90% dia mahafeno ny filana rehetra izy ireo... Na izany aza, raha ny anay dia tsy ampy izany. Noho izany, mametraka ireto sanda manaraka ireto izahay:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... ary namerina indray ny kubelets, ary avy eo dia nahita ity sary manaraka ity tao amin'ny sarin'ny antso amin'ny mpizara API:
... ary eny, nanomboka nanidina ny zava-drehetra!
Sal
Noho ny fanampian'izy ireo amin'ny fanangonana bibikely sy fanomanana ity lahatsoratra ity, dia maneho ny fankasitrahako lalina ireo injeniera marobe ao amin'ny orinasanay aho, ary indrindra ho an'ny mpiara-miasa amiko avy amin'ny ekipa R&D Andrey Klimentyev ().
PPS
Vakio ihany koa ao amin'ny bilaoginay:
- Β«".
- Kubernetes toro-hevitra & tricks loop:
- Β«";
- Β«";
- Β«";
- Β«".
Source: www.habr.com