6 bugs tas-sistema divertenti fl-operat ta' Kubernetes [u s-soluzzjoni tagħhom]

Matul is-snin ta 'użu ta' Kubernetes fil-produzzjoni, akkumulajna ħafna stejjer interessanti ta 'kif bugs f'diversi komponenti tas-sistema wasslu għal konsegwenzi spjaċevoli u/jew inkomprensibbli li jaffettwaw l-operat ta' kontenituri u imżiewed. F'dan l-artikolu għamilna għażla ta 'wħud mill-aktar komuni jew interessanti. Anke jekk qatt ma tkun xortik tajba biżżejjed li tiltaqa' ma' sitwazzjonijiet bħal dawn, il-qari dwar stejjer qosra ta' ditektifs bħal dawn - speċjalment "l-ewwel" - huwa dejjem interessanti, hux?...

Storja 1. Supercronic u Docker mdendlin

Fuq wieħed mill-clusters, irċevejna perjodikament Docker iffriżat, li interferiet mal-funzjonament normali tal-cluster. Fl-istess ħin, dan li ġej ġie osservat fir-reġistru 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

…

L-iktar li jinteressana dwar dan l-iżball huwa l-messaġġ: pthread_create failed: No space left on device. Studju malajr dokumentazzjoni spjega li Docker ma setax jagħmel proċess, u huwa għalhekk li ffriżat perjodikament.

Fil-monitoraġġ, l-istampa li ġejja tikkorrispondi għal dak li qed jiġri:

Sitwazzjoni simili hija osservata fuq nodi oħra:

Fl-istess nodi naraw:

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>

Irriżulta li din l-imġieba hija konsegwenza tal-powd li jaħdem magħhom superkroniku (utilità Go li nużaw biex inħaddmu impjiegi cron fil-miżwed):

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

Il-problema hija din: meta kompitu jitmexxa f'supercronic, il-proċess nissel minnha ma tistax tittermina b'mod korrett, tidwir fi zombie.

Innota: Biex inkun aktar preċiż, il-proċessi jitnisslu minn kompiti cron, iżda supercronic mhix sistema init u ma tistax "jadotta" proċessi li wliedha biedu. Meta s-sinjali SIGHUP jew SIGTERM jitqajmu, ma jiġux mgħoddija lill-proċessi tat-tfal, u dan jirriżulta fil-proċessi tat-tfal ma jispiċċawx u jibqgħu fi status ta 'zombie. Tista’ taqra aktar dwar dan kollu, pereżempju, fi artikolu bħal dan.

Hemm ftit modi kif issolvi l-problemi:

1. Bħala soluzzjoni temporanja - żid in-numru ta 'PIDs fis-sistema f'punt wieħed fiż-żmien:

          /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. Jew tniedi kompiti fil supercronic mhux direttament, iżda bl-użu l-istess tini, li huwa kapaċi jtemm il-proċessi b'mod korrett u ma jbid zombies.

Storja 2. "Zombies" meta tħassar cgroup

Kubelet beda jikkonsma ħafna CPU:

Ħadd mhu se jħobb dan, allura armajna ruħna perfetta u bdew jittrattaw il-problema. Ir-riżultati tal-investigazzjoni kienu kif ġej:

• Kubelet iqatta 'aktar minn terz tal-ħin tas-CPU tiegħu jiġbed data tal-memorja mill-cgroups kollha:

  

• Fil-lista tal-posta tal-iżviluppaturi tal-qalba tista' ssib diskussjoni tal-problema. Fil-qosor, il-punt jasal għal dan: diversi fajls tmpfs u affarijiet simili oħra ma jitneħħewx kompletament mis-sistema meta tħassar cgroup, l-hekk imsejjaħ memcg Zombie. Illum jew għada dawn se jitħassru mill-cache tal-paġna, iżda hemm ħafna memorja fuq is-server u l-kernel ma jarax il-punt li jaħli l-ħin biex iħassarhom. Għalhekk jibqgħu jinġabru. Għaliex qed jiġri dan? Dan huwa server b'impjiegi cron li kontinwament joħloq impjiegi ġodda, u magħhom imżiewed ġodda. Għalhekk, jinħolqu cgroups ġodda għal kontenituri fihom, li dalwaqt jitħassru.
• Għaliex cAdvisor f'kubelet jaħli daqshekk ħin? Dan huwa faċli biex tara bl-eżekuzzjoni sempliċi time cat /sys/fs/cgroup/memory/memory.stat. Jekk fuq magna b'saħħitha l-operazzjoni tieħu 0,01 sekondi, allura fuq il-cron02 problematiku tieħu 1,2 sekondi. Il-ħaġa hija li cAdvisor, li jaqra data mis-sysfs bil-mod ħafna, jipprova jqis il-memorja użata f'cgroups zombie.
• Biex inneħħu l-zombies bil-qawwa, ippruvajna nneħħi l-caches kif rakkomandat f'LKML: sync; echo 3 > /proc/sys/vm/drop_caches, - iżda l-qalba rriżulta li kienet aktar ikkumplikata u ħabtet il-karozza.

X'tagħmel? Il-problema qed tiġi rranġata (jikkommettu, u għal deskrizzjoni ara messaġġ ta 'rilaxx) aġġornament tal-kernel Linux sal-verżjoni 4.16.

Storja 3. Systemd u l-muntatura tiegħu

Għal darb'oħra, il-kubelet qed jikkonsma wisq riżorsi fuq xi nodi, iżda din id-darba qed jikkonsma wisq memorja:

Irriżulta li kien hemm problema bis-systemd użat fi Ubuntu 16.04, u dan iseħħ meta jiġu ġestiti l-muntaturi li huma maħluqa għall-konnessjoni subPath minn ConfigMaps jew sigrieti. Wara li l-pod ikun lesta x-xogħol tiegħu is-servizz systemd u l-muntatura tas-servizz tiegħu jibqgħu fis-sistema. Maż-żmien, numru kbir minnhom jakkumulaw. Hemm ukoll kwistjonijiet dwar dan is-suġġett:

1. #5916;
2. kubernetes #57345.

...l-aħħar minnhom jirreferi għall-PR fis-systemd: #7811 (ħarġa fis-systemd - #7798).

Il-problema m'għadhiex hemm Ubuntu 18.04, imma jekk trid tkompli tuża Ubuntu 16.04, tista' ssib is-soluzzjoni tagħna dwar dan is-suġġett utli.

Allura għamilna d-DaemonSet li ġej:

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

... u juża l-iskrittura li ġejja:

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

... u taħdem kull 5 minuti bl-użu tas-supercronic imsemmi qabel. Dockerfile tiegħu jidher bħal dan:

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

Storja 4. Kompetittività meta skedar imżiewed

Ġie nnutat li: jekk ikollna pod imqiegħed fuq node u l-immaġni tiegħu tiġi ppumpjata għal żmien twil ħafna, allura pod ieħor li "jolqot" l-istess nodu sempliċement se ma tibda tiġbed l-immaġni tal-powd il-ġdid. Minflok, tistenna sakemm tinġibed l-immaġini tal-powd preċedenti. B’riżultat ta’ dan, pod li kien diġà skedat u li l-immaġni tiegħu setgħet titniżżel f’minuta biss se jispiċċa fl-istatus ta’ containerCreating.

L-avvenimenti se jidhru xi ħaġa bħal din:

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

Jirriżulta li immaġini waħda minn reġistru bil-mod jista 'jimblokka l-iskjerament għal kull node.

Sfortunatament, m'hemmx ħafna modi biex toħroġ mis-sitwazzjoni:

1. Ipprova uża r-Reġistru Docker tiegħek direttament fil-cluster jew direttament mal-cluster (per eżempju, GitLab Reġistru, Nexus, eċċ.);
2. Uża utilitajiet bħal xquq.

Storja 5. Nodes hang minħabba nuqqas ta 'memorja

Waqt it-tħaddim ta 'diversi applikazzjonijiet, iltqajna wkoll ma' sitwazzjoni fejn node ma jibqax kompletament aċċessibbli: SSH ma jirrispondix, id-daemons ta 'monitoraġġ kollha jaqgħu, u allura m'hemm xejn (jew kważi xejn) anomali fir-zkuk.

Jien ngħidlek fl-istampi billi tuża l-eżempju ta 'node wieħed fejn ħadmet MongoDB.

Dan huwa dak li jidher atop li inċidenti:

U bħal dan - wara inċidenti:

Fil-monitoraġġ, hemm ukoll qabża qawwija, li fiha n-nodu ma jibqax disponibbli:

Għalhekk, mill-screenshots jidher ċar li:

1. Ir-RAM fuq il-magna hija qrib it-tmiem;
2. Hemm qabża qawwija fil-konsum ta 'RAM, wara li l-aċċess għall-magna kollha huwa diżattivat f'daqqa;
3. Jasal kompitu kbir fuq Mongo, li jġiegħel lill-proċess tad-DBMS juża aktar memorja u jaqra b'mod attiv mid-disk.

Jirriżulta li jekk fi Linux il-memorja libera tispiċċa (isseħħ pressjoni tal-memorja) u ma jkunx hemm swap, imbagħad li Meta jasal il-qattiel OOM, jista 'jseħħ att ta' bilanċ bejn li titfa' paġni fil-cache tal-paġna u tiktebhom lura fuq id-diska. Dan isir minn kswapd, li b'kuraġġ jillibera kemm jista 'jkun paġni tal-memorja għal distribuzzjoni sussegwenti.

Sfortunatament, b'tagħbija I/O kbira flimkien ma 'ammont żgħir ta' memorja ħielsa, kswapd isir il-konġestjoni tas-sistema kollha, għax huma marbuta magħha kollha allokazzjonijiet (ħsarat fil-paġna) tal-paġni tal-memorja fis-sistema. Dan jista 'jdum għal żmien twil ħafna jekk il-proċessi ma jridux jużaw il-memorja aktar, iżda huma ffissati fit-tarf stess tal-abbiss OOM-qattiel.

Il-mistoqsija naturali hija: għaliex il-qattiel OOM jasal daqshekk tard? Fl-iterazzjoni attwali tiegħu, il-qattiel OOM huwa estremament stupid: se joqtol il-proċess biss meta t-tentattiv biex tiġi allokata paġna tal-memorja jfalli, i.e. jekk it-tort tal-paġna jonqos. Dan ma jseħħx għal żmien pjuttost twil, minħabba li kswapd b'kuraġġ jillibera l-paġni tal-memorja, u jwarrab il-cache tal-paġna (l-I/O tad-disk kollu fis-sistema, fil-fatt) lura fid-disk. F'aktar dettall, b'deskrizzjoni tal-passi meħtieġa biex jiġu eliminati problemi bħal dawn fil-qalba, tista 'taqra hawn.

Din l-imġieba għandhom jitjiebu b'qalba Linux 4.6 +.

Storja 6. Il-miżwed jeħlu fi stat Pendenti

F'xi raggruppamenti, li fihom verament ħafna imżiewed joperaw, bdejna ninnutaw li ħafna minnhom "hang" għal żmien twil ħafna fl-istat Pending, għalkemm il-kontenituri Docker infushom diġà qed jaħdmu fuq in-nodi u jistgħu jinħadmu manwalment.

Barra minn hekk, fi describe m'hemm xejn ħażin:

  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

Wara xi tħaffir, għamilna l-assunzjoni li l-kubelet sempliċement m'għandux ħin biex jibgħat l-informazzjoni kollha dwar l-istat tal-miżwed u t-testijiet tal-ħajja/prontezza lis-server tal-API.

U wara studjaw l-għajnuna, sibna l-parametri li ġejjin:

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

Kif jidher, valuri default huma pjuttost żgħar, u f'90% ikopru l-bżonnijiet kollha... Madankollu, fil-każ tagħna dan ma kienx biżżejjed. Għalhekk, aħna nissettjaw il-valuri li ġejjin:

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

... u reġgħet bdiet il-kubelets, u wara rajna l-istampa li ġejja fil-graffs tas-sejħiet lis-server tal-API:

... u iva, kollox beda jtir!

PS

Għall-għajnuna tagħhom fil-ġbir ta 'bugs u t-tħejjija ta' dan l-artikolu, nesprimi l-gratitudni profonda tiegħi lill-bosta inġiniera tal-kumpanija tagħna, u speċjalment lill-kollega tiegħi mit-tim tagħna ta 'R&D Andrey Klimentyev (zuzzas).

PPS

Aqra wkoll fuq il-blog tagħna:

• «plugin kubectl-debug għad-debugging fil-miżwed Kubernetes".
• Kubernetes tips & tricks loop:
  • «It-trasferiment tar-riżorsi li jaħdmu f'grupp għall-ġestjoni Helm 2»;
  • «Dwar l-allokazzjoni tan-nodi u t-tagħbijiet fuq applikazzjoni tal-web»;
  • «Aċċess għal siti dev»;
  • «Tħaffef tal-bootstrap għal databases kbar".

Sors: www.habr.com