6 izklaidējošas sistēmas kļūdas Kubernetes darbībā [un to risinājums]

Gadu gaitā, izmantojot Kubernetes ražošanā, esam uzkrājuši daudz interesantu stāstu par to, kā dažādu sistēmas komponentu kļūdas noveda pie nepatīkamām un/vai nesaprotamām sekām, kas ietekmē konteineru un podiņu darbību. Šajā rakstā mēs esam apkopojuši dažus no visizplatītākajiem vai interesantākajiem. Pat ja jums nekad nav paveicies saskarties ar šādām situācijām, lasīt par šādiem īsiem detektīvstāstiem - īpaši "no pirmavotiem" - vienmēr ir izklaidējoši, vai ne?

Stāsts 1. Supercronic un iestrēdzis Docker

Vienā no klasteriem mēs periodiski saņēmām “piekārtu” Docker, kas traucēja klastera normālu darbību. Tajā pašā laikā Docker žurnālos tika novērots sekojošais

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

…

Šajā kļūdā mūs visvairāk interesē ziņojums: pthread_create failed: No space left on device. Paviršs pētījums dokumentācija paskaidroja, ka Docker nevar sadalīt procesu, tāpēc tas periodiski “uzkaras”.

Uzraudzībā notiekošais atbilst šādam attēlam:

Līdzīga situācija tiek novērota citos mezglos:

Tajos pašos mezglos mēs redzam:

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>

Izrādījās, ka šī uzvedība ir sekas, ko pāksts strādāja ar superkronisks (Utilīta Go, ko izmantojam, lai palaistu cron darbus podiņos):

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

Problēma ir šāda: kad uzdevums tiek sākts superkronikā, process ir saistīts ar to nevar pareizi pabeigt, pārvēršoties par zombijs.

PiezīmePrecīzāk sakot, procesus rada cron uzdevumi, taču superkroniks nav sākotnējā sistēma un nevar "pieņemt" procesus, ko radījuši tā bērni. Kad parādās SIGHUP vai SIGTERM signāli, tie netiek nodoti pakārtotajiem procesiem, kā rezultātā pakārtotie procesi netiek pārtraukti, paliekot zombiju statusā. Vairāk par to visu varat lasīt, piemēram, iekš tāds raksts.

Ir vairāki veidi, kā atrisināt problēmas:

1. Kā pagaidu risinājums — palieliniet PID skaitu sistēmā vienā brīdī:

          /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. Vai arī veiciet uzdevumu palaišanu superkronikā nevis tieši, bet izmantojot to pašu Tini, kas spēj graciozi pārtraukt procesus un neradīt zombijus.

Stāsts 2. "Zombiji" dzēšot cgroup

Kubelet sāka patērēt daudz CPU:

Tas nevienam nepatīk, tāpēc mēs bruņojāmies ideāls un sāka risināt problēmu. Izmeklēšanas rezultāti bija šādi:

• Kubelet pavada vairāk nekā trešdaļu CPU laika, lai iegūtu atmiņas datus no visām cgrupām:

  

• Kodola izstrādātāju adresātu sarakstā varat atrast problēmas apspriešana. Īsāk sakot, būtība ir tāda dažādi tmpfs faili un citas līdzīgas lietas netiek pilnībā izņemtas no sistēmas dzēšot cgrupu, t.s memcg zombijs. Agri vai vēlu tie tomēr tiks dzēsti no lapas kešatmiņas, tomēr serverī ir daudz atmiņas un kodols neredz jēgu tērēt laiku to dzēšanai. Tāpēc viņi turpina krāties. Kāpēc tas vispār notiek? Šis ir serveris ar cron darbiem, kas pastāvīgi rada jaunas darbavietas un līdz ar to arī jaunus podziņus. Tādējādi tajās esošajiem konteineriem tiek izveidotas jaunas cgrupas, kuras drīz vien tiek izdzēstas.
• Kāpēc cAdvisor kubeletā pavada tik daudz laika? To ir viegli redzēt, veicot vienkāršāko izpildi time cat /sys/fs/cgroup/memory/memory.stat. Ja veselā mašīnā darbība aizņem 0,01 sekundi, tad problēmai cron02 tas aizņem 1,2 sekundes. Lieta tāda, ka cAdvisor, kas ļoti lēni nolasa datus no sysfs, cenšas ņemt vērā arī zombiju cgrupās izmantoto atmiņu.
• Lai piespiedu kārtā noņemtu zombijus, mēs mēģinājām notīrīt kešatmiņas, kā ieteica LKML: sync; echo 3 > /proc/sys/vm/drop_caches, - bet kodols izrādījās sarežģītāks un apčakarēja mašīnu.

Ko darīt? Problēma tiek novērstaapņemties, un skatiet aprakstu sadaļā atbrīvošanas ziņojums) kodola atjauninājums Linux līdz versijai 4.16.

Stāsts 3. Systemd un tā stiprinājums

Atkal, kubelet dažos mezglos patērē pārāk daudz resursu, taču šoreiz tas ir vairāk atmiņas:

Izrādījās, ka radās problēma ar systemd, ko izmantoja Ubuntu 16.04, un tas notiek, pārvaldot savienojumam izveidotos stiprinājumus subPath no ConfigMap'ov vai secret'ov. Pēc podiņa izslēgšanas paliek sistēmas pakalpojums un tā servisa stiprinājums sistēmā. Laika gaitā tie uzkrājas milzīgs daudzums. Par šo tēmu ir pat problēmas:

1. #5916;
2. kubernetes#57345.

... pēdējā no tām atsaucas uz PR sistēmād: #7811 (problēma sistēmād - #7798).

Problēmas vairs nav Ubuntu 18.04, bet, ja vēlaties turpināt lietot Ubuntu 16.04., mūsu risinājums šai tēmai varētu jums noderēt.

Tātad, mēs esam izveidojuši šādu 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

... un tas izmanto šo skriptu:

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

... un tas darbojas ik pēc 5 minūtēm ar iepriekš minētā superkronika palīdzību. Tā Dockerfile izskatās šādi:

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

4. stāsts: Vienlaicība pod plānošanā

Tika pamanīts, ka: ja mums ir uzlikts pods uz mezgla un tā attēls tiek izsūknēts ļoti ilgi, tad cits pods, kas "trāpīja" tajā pašā mezglā vienkārši nesāk vilkt jaunu pāksts attēlu. Tā vietā tas gaida, līdz tiks “izvilkts” iepriekšējā aplikuma attēls. Rezultātā pods, kas jau bija ieplānots un kura attēlu varēja lejupielādēt tikai minūtes laikā, nonāks statusā uz ilgu laiku. containerCreating.

Pasākumi izskatīsies apmēram šādi:

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

Izrādās, ka viens attēls no lēna reģistra var bloķēt izvietošanu uz mezglu.

Diemžēl nav daudz izeju no situācijas:

1. Mēģiniet izmantot savu Docker reģistru tieši klasterī vai tieši kopā ar klasteru (piemēram, GitLab reģistrs, Nexus utt.);
2. Izmantojiet tādas utilītas kā Kraken.

Stāsts 5. Piekārti mezgli atmiņas trūkuma dēļ

Dažādu aplikāciju darbības laikā saņēmām arī situāciju, kad mezgls pilnībā pārstāj būt pieejams: SSH nereaģē, nokrīt visi uzraudzības dēmoni, un tad žurnālos nav nekā (vai gandrīz nekā) nenormāla.

Es jums pastāstīšu attēlos, izmantojot piemēru vienam mezglam, kurā darbojās MongoDB.

Šādi izskatās virsotne līdz nelaimes gadījumi:

Un šādi - pēc nelaimes gadījumi:

Uzraudzībā ir arī straujš lēciens, pie kura mezgls vairs nav pieejams:

Tātad no ekrānuzņēmumiem varat redzēt, ka:

1. Iekārtas operatīvā atmiņa ir gandrīz beigusies;
2. Straujš lēciens RAM patēriņā, pēc kura piekļuve visai mašīnai tiek pēkšņi atspējota;
3. Mongo ierodas liels uzdevums, kas liek DBVS procesam izmantot vairāk atmiņas un aktīvi lasīt no diska.

Izrādās, ka, ja iekšā Linux brīvā atmiņa beidzas (rodas atmiņas spiediens) un mijmaiņas nav, tad līdz Pēc OOM slepkavas ierašanās var būt līdzsvars starp lapu iemetīšanu lapas kešatmiņā un ierakstīšanu atpakaļ diskā. To apstrādā kswapd, kas varonīgi atbrīvo pēc iespējas vairāk atmiņas lappušu vēlākai piešķiršanai.

Diemžēl ar lielu I/O slodzi kopā ar nelielu brīvas atmiņas daudzumu, kswapd kļūst par visas sistēmas sašaurinājumujo viņi ir ar to saistīti viss atmiņas lapu sadalījums (lapu defekti) sistēmā. Tas var turpināties ļoti ilgi, ja procesi vairs nevēlas izmantot atmiņu, bet fiksējas uz OOM slepkavas bezdibena pašas malas.

Jautājums ir dabisks: kāpēc OOM slepkava nāk tik vēlu? Pašreizējā iterācijā OOM killer ir ārkārtīgi stulbs: tas nogalinās procesu tikai tad, ja mēģinājums piešķirt atmiņas lapu neizdodas, t.i. ja lapas kļūda pāriet ar kļūdu. Tas nenotiek pietiekami ilgi, jo kswapd varonīgi atbrīvo lappuses no atmiņas, izskalojot lapu kešatmiņu (būtībā visu sistēmas disku I/O) atpakaļ diskā. Sīkāk varat izlasīt ar aprakstu par darbībām, kas nepieciešamas, lai novērstu šādas kodola problēmas šeit.

Šī uzvedība vajadzētu uzlaboties ar kodolu Linux 4.6 +.

6. stāsts. Pāksti iestrēgst gaidīšanas stāvoklī

Dažos klasteros, kuros darbojas patiešām liels skaits pākstīm, mēs sākām pamanīt, ka lielākā daļa no tām karājas stāvoklī ļoti ilgu laiku. Pending, lai gan paši Docker konteineri jau darbojas mezglos, un jūs varat ar tiem strādāt manuāli.

Turklāt iekšā describe nav nekā slikta:

  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

Pēc rakšanas mēs izdarījām pieņēmumu, ka kubelet vienkārši nav laika nosūtīt API serverim visu informāciju par podiņu stāvokli, dzīvīguma / gatavības paraugiem.

Un, izpētot palīdzību, mēs atradām šādus parametrus:

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

Kā redzams, noklusējuma vērtības ir diezgan mazas, un 90% tie sedz visas vajadzības... Tomēr mūsu gadījumā ar to nepietika. Tāpēc mēs iestatām šādas vērtības:

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

... un restartēja kubelets, pēc tam mēs redzējām šādu attēlu grafikos, lai piekļūtu API serverim:

... un jā, viss sāka lidot!

PS

Par palīdzību kļūdu apkopošanā un raksta sagatavošanā es izsaku lielu pateicību mūsu uzņēmuma daudzajiem inženieriem un jo īpaši mūsu kolēģim no mūsu pētniecības un attīstības komandas Andrejam Klimentjevam (zuzzas).

PPS

Lasi arī mūsu emuārā:

• «kubectl-debug spraudnis atkļūdošanai Kubernetes podiņos'.
• Kubernetes padomu un triku cikls:
  • «Klasterī darbojošos resursu pārsūtīšana, ko kontrolē Helm 2";
  • «Par mezglu piešķiršanu un slodzēm tīmekļa lietojumprogrammā";
  • «Piekļuve izstrādes vietnēm";
  • «Sāknēšanas paātrināšana lielām datu bāzēm'.

Avots: www.habr.com