6 bibikely rafitra mampiala voly amin'ny fiasan'ny Kubernetes [sy ny vahaolana amin'izy ireo]

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 tahirin-kevitra 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 supercronic (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 zombie.

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 lahatsoratra toy izany.

Misy fomba roa hamahana olana:

1. 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

2. Na manomboka asa amin'ny supercronic tsy mivantana, fa mampiasa mitovy tini, 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 tonga lafatra 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 fifanakalozan-kevitra momba ny olana. 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 memcg 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 (manao, ary raha mila fanazavana dia jereo famoahana hafatra) fanavaozana ny kernel Linux hatramin'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:

Hay nisy olana tamin'ny systemd nampiasaina tao 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:

1. #5916;
2. kubernetes #57345.

...ny farany dia manondro ny PR ao amin'ny systemd: #7811 (olana ao amin'ny systemd- #7798).

Tsy eo intsony ny olana Ubuntu 18.04, fa raha te-hanohy hampiasa Ubuntu 16.04, mety ho hitanao fa mahasoa ny vahaolana amin'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:

1. Andramo ny mampiasa ny Docker Registry mivantana ao amin'ny cluster na mivantana miaraka amin'ny cluster (ohatra, GitLab Registry, Nexus, sns.);
2. Mampiasà fitaovana toy ny kraken.

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:

1. Ny RAM amin'ny milina dia manakaiky ny farany;
2. Misy fitsambikinana mafy amin'ny fanjifana RAM, ary avy eo dia tapaka tampoka ny fidirana amin'ny milina manontolo;
3. 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 ao anatin'ny Linux lany ny fitadidiana malalaka (misy tsindry amin'ny 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 eto.

Ity fihetsika ity tokony hihatsara miaraka amin'ny fotony Linux 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 container

Taorian'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 (zuzzas).

PPS

Vakio ihany koa ao amin'ny bilaoginay:

• «plugin kubectl-debug ho an'ny debugging ao amin'ny pods Kubernetes".
• Kubernetes toro-hevitra & tricks loop:
  • «Famindrana loharanon-karena mandeha amin'ny cluster mankany amin'ny fitantanana Helm 2";
  • «Momba ny fizarana node sy ny entana amin'ny fampiharana tranonkala";
  • «Fidirana amin'ny tranokala dev";
  • «Manafaingana ny bootstrap ho an'ny angon-drakitra lehibe".

Source: www.habr.com