6 amuzaj sistemaj cimoj en la funkciado de Kubernetes [kaj ilia solvo]

Dum la jaroj da uzado de Kubernetes en produktado, ni akumulis sufiĉe multajn interesajn rakontojn pri kiel cimoj en diversaj sistemaj komponantoj kondukis al malagrablaj kaj/aŭ neklaraj sekvoj, kiuj influas la funkciadon de ujoj kaj podoj. En ĉi tiu artikolo, ni kompilis elekton de kelkaj el la plej oftaj aŭ interesaj el ili. Eĉ se vi neniam havas la bonŝancon renkonti tiajn situaciojn, legi pri tiaj mallongaj krimrakontoj - precipe "unuamanaj" - ĉiam estas interese, ĉu ne?..

Rakonto 1. Superkronika kaj la pendanta Dokisto

Sur unu el la aretoj, ni periode ricevis "frostiĝintan" Docker-on, kiu malhelpis la normalan funkciadon de la areto. Samtempe, la sekva estis observita en la Docker-protokoloj:

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

…

La mesaĝo, kiu plej interesas nin en ĉi tiu eraro, estas: pthread_create failed: No space left on deviceRapida studado dokumentado klarigis, ke Docker ne povis forkigi la procezon, tial ĝi periode "frostiĝis".

En monitorado, la sekva bildo respondas al tio, kio okazas:

Simila situacio estas observata ĉe aliaj nodoj:

Sur ĉi tiuj samaj nodoj ni vidas:

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>

Montriĝis, ke ĉi tiu konduto estas sekvo de la funkciado de la podo kun superkrono (Go-utilaĵo, kiun ni uzas por ruli cron-taskojn en podoj):

 _ 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>
…

La problemo estas jena: kiam tasko estas komencita en supercronic, la procezo generita de ĝi, ne povas kompletigi ĝuste, transformiĝante en zombio.

ПримечаниеPli precize, la procezoj estas generitaj de cron-taskoj, sed supercronic ne estas init-sistemo kaj ne povas "adopti" procezojn generitajn de siaj idoj. Kiam SIGHUP- aŭ SIGTERM-signaloj aperas, ili ne estas transdonitaj al la generitaj procezoj, rezulte de kio la idaj procezoj ne finiĝas, restante en zombia stato. Pliajn detalojn pri ĉio ĉi oni povas trovi, ekzemple, en tia artikolo.

Estas kelkaj manieroj solvi la problemon:

1. Kiel provizora solvo - pliigu la nombron de PID-oj en la sistemo samtempe:

          /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. Aŭ vi povas lanĉi taskojn en supercronic ne rekte, sed uzante la saman tini, kiu kapablas ĝuste fini procezojn kaj ne generi zombiojn.

Rakonto 2. "Zombioj" dum forigo de cgroup

Kubelet komencis konsumi multan CPU-on:

Neniu ŝatas ĉi tion, do ni armis nin perfekta kaj komencis trakti la problemon. La rezultoj de la esploro estis jenaj:

• Kubelet pasigas pli ol trionon de sia CPU-tempo tirante memordatumojn el ĉiuj cgrupoj:

  

• Vi povas trovi ĝin en la dissendolisto de kernaj programistoj diskuto pri la problemoMallonge, la esenco estas, ke diversaj tmpfs-dosieroj kaj aliaj similaj aferoj ne estas tute forigitaj de la sistemo forigante cgrupon, la tiel nomataj restas memcg zombiPli frue aŭ pli malfrue ili estos forigitaj el la paĝa kaŝmemoro, sed estas multe da memoro sur la servilo kaj la kerno ne vidas la sencon perdi tempon forigante ilin. Do ili daŭre akumuliĝas. Kial tio okazas entute? Ĉi tiu estas servilo kun cron-taskoj, kiu konstante kreas novajn taskojn, kaj kun ili - novajn podojn. Tiel, novaj cgroupoj estas kreitaj por ujoj en ili, kiuj baldaŭ estas forigitaj.
• Kial cAdvisor en kubelet daŭras tiom longe? Estas facile vidi tion per la plej simpla efektivigo. time cat /sys/fs/cgroup/memory/memory.statSe sur sana maŝino la operacio daŭras 0,01 sekundojn, tiam sur la problema cron02 ĝi daŭras 1,2 sekundojn. La tuta afero estas, ke cAdvisor, kiu legas datumojn el sysf-dosieroj tre malrapide, provas konsideri la uzatan memoron en zombiaj c-grupoj.
• Por perforte forigi la zombiojn, ni provis malplenigi la kaŝmemorojn kiel rekomendite en LKML: sync; echo 3 > /proc/sys/vm/drop_caches, - sed la kerno montriĝis pli kompleksa kaj pendigis la maŝinon.

Kion fari? La problemo estas solvita (kompromiti, kaj vidu la priskribon en anonco pri eldono) kerna ĝisdatigo Linux ĝis versio 4.16.

Historio 3. Systemd kaj ĝia muntado

Denove, kubelet konsumas tro multajn rimedojn ĉe iuj nodoj, sed ĉi-foje temas pri memoro:

Rezultis, ke estis problemo kun systemd uzata en Ubuntu 16.04, kaj ĝi okazas dum administrado de muntadoj kreitaj por konekto subPath el ConfigMaps aŭ sekretoj. Post kiam la podo finiĝos la systemd-servo kaj ĝia serva muntado restas en la sistemo. Kun la tempo, grandega nombro da ili akumuliĝas. Eĉ ekzistas problemoj pri ĉi tiu temo:

1. kops #5916;
2. kubernetes #57345.

...kies lasta referencas PR en systemd: #7811 (problemo en systemd — #7798).

La problemo jam ne plu estas tie Ubuntu 18.04, sed se vi volas daŭre uzi Ubuntu 16.04, vi eble trovos nian solvon pri ĉi tiu temo utila.

Do, ni faris la jenan 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

... kaj ĝi uzas la jenan skripton:

#!/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

... kaj ĝi funkcias ĉiujn 5 minutojn uzante la jam menciitan superkronikon. Ĝia Dockerfile aspektas jene:

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"]

Rakonto 4: Samtempeco en Pod-Planado

Oni rimarkis, ke: se ni havas podon metitan sur nodon kaj ĝia bildo estas elŝutata dum tre longa tempo, tiam alia podo, kiu "alvenis" sur la saman nodon, simple ne komencas tiri la bildon de la nova podoAnstataŭe, ĝi atendas la eltiron de la bildo de la antaŭa podo. Rezulte, podo kiu jam estis planita kaj kies bildo povus esti elŝutita en nur minuto finos en stato de containerCreating.

La eventoj aspektos iel tiel:

Normal  Pulling    8m    kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal  pulling image "registry.example.com/infra/openvpn/openvpn:master"

Ĝi rezultas tion unuopa bildo el malrapida registro povas bloki deplojon sur la nodo.

Bedaŭrinde, ne estas multaj elirejoj el ĉi tiu situacio:

1. Provu uzi vian Docker Registry rekte en la areto aŭ rekte kun la areto (ekzemple, GitLab Registry, Nexus, ktp.);
2. Uzu ilojn kiel ekzemple kraken.

Rakonto 5. Nodoj pendantaj pro nesufiĉa memoro

Dum la funkciigo de diversaj aplikaĵoj, ni ankaŭ renkontis situacion, kie nodo tute ĉesas esti alirebla: SSH ne respondas, ĉiuj monitoraj demonoj malsukcesas, kaj tiam nenio (aŭ preskaŭ nenio) estas nenormala en la protokoloj.

Mi rakontos al vi per bildoj uzante la ekzemplon de unu nodo kie MongoDB funkciis.

Jen kiel aspektas supre por akcidentoj:

Kaj tiel - после akcidentoj:

Monitorado ankaŭ montras akran salton, ĉe kiu punkto la nodo fariĝas neatingebla:

Tiel, el la ekranfotoj estas klare, ke:

1. La maŝino havas malmulte da RAM;
2. Estas akra pliiĝo en RAM-konsumo, post kio aliro al la tuta maŝino subite malŝaltiĝas;
3. Granda tasko alvenas sur Mongo, kiu igas la DBMS-procezon uzi pli da memoro kaj aktive legi de la disko.

Rezultas, ke se en Linux libera memoro elĉerpiĝas (memorpremo okazas) kaj ne estas interŝanĝo, tiam por Kiam la OOM-mortigilo alvenos, eble ekzistos ekvilibro inter ĵeti paĝojn en la paĝkaŝmemoron kaj skribi ilin reen al disko. Ĉi tion pritraktas kswapd, kiu kuraĝe liberigas tiom da memorpaĝoj kiom eble por posta asigno.

Bedaŭrinde, kun alta I/O-ŝarĝo kunligita kun malgranda kvanto da libera memoro, kswapd fariĝas proplempunkto por la tuta sistemo, ĉar ili estas ligitaj al ĝi ĉiuj asignoj (paĝaj eraroj) de memorpaĝoj en la sistemo. Ĉi tio povas daŭri tre longe se la procezoj ne plu volas uzi memoron, sed restas blokitaj ĉe la rando de la abismo de OOM-mortiganto.

La demando estas: kial la OOM-mortigilo venas tiel malfrue? En sia nuna versio, la OOM-mortigilo estas ekstreme stulta: ĝi mortigos la procezon nur kiam la provo asigni memorpaĝon malsukcesas, t.e. se la paĝeraro malsukcesas. Tio ne okazas dum sufiĉe longa tempo, ĉar kswapd kuraĝe liberigas memorpaĝojn, forigante la paĝan kaŝmemoron (ĉiujn diskajn enigojn/eligojn en la sistemo, esence) reen al la disko. Pli detale, kun priskribo de la paŝoj necesaj por solvi tiajn problemojn en la kerno, vi povas legi... tie.

Ĉi tiu konduto devus pliboniĝi kun kerno Linux 4.6 +.

Rakonto 6. Pods blokitaj en Atendanta stato

En iuj aretoj, kie vere multaj podoj funkcias, ni komencis rimarki, ke granda parto de ili "pendis" en la ŝtato dum tre longa tempo. Pending, kvankam la Docker-ujoj mem jam funkcias sur la nodoj kaj oni povas prilabori ilin permane.

Samtempe, describe nenio estas malĝusta:

  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

Post iom da esplorado, ni supozis, ke kubelet simple ne havas tempon sendi ĉiujn informojn pri la stato de podoj kaj pretec-/vivecaj sondiloj al la API-servilo.

Kaj studinte la helpon, ni trovis la jenajn parametrojn:

--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)

Kiel vidite, defaŭltaj valoroj estas sufiĉe malgrandaj, kaj en 90% ili kovras ĉiujn bezonojn... Tamen, en nia kazo tio ne sufiĉis. Tial ni starigis la jenajn valorojn:

--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40

... kaj rekomencis la kubeletojn, post kio ni vidis la jenan bildon sur la grafikaĵoj de petoj al la API-servilo:

...kaj jes, ĉio ekflugis!

PS

Pro helpo en la kolektado de cimoj kaj preparado de la artikolo, mi ŝatus esprimi mian profundan dankemon al la multnombraj inĝenieroj de nia kompanio, kaj precipe al mia kolego el nia esplor- kaj disvolva teamo, Andrej Klimentjev (zuzoj).

PPS

Legu ankaŭ en nia blogo:

• «kubectl-debug kromaĵo por sencimigi en Kubernetes-podoj".
• Buklo de konsiloj kaj trukoj de Kubernetes:
  • «Transdonante rimedojn kurantajn en areto al administrado de Helm 2»;
  • «Pri noda atribuo kaj ŝarĝoj sur TTT-apliko»;
  • «Aliro al dev-ejoj»;
  • «Akcelo de ekfunkciigo por grandaj datumbazoj".

fonto: www.habr.com