6 fermaaklike systeembugs yn 'e wurking fan Kubernetes [en har oplossing]

Yn 'e rin fan' e jierren fan it brûken fan Kubernetes yn 'e produksje hawwe wy in protte nijsgjirrige ferhalen sammele oer hoe't bugs yn ferskate systeemkomponinten liede ta onaangename en / of ûnbegryplike gefolgen dy't de wurking fan konteners en pods beynfloedzje. Yn dit artikel hawwe wy in seleksje makke fan guon fan 'e meast foarkommende as nijsgjirrige. Sels as jo noait gelok hawwe om sokke situaasjes tsjin te kommen, is it lêzen oer sokke koarte detektiveferhalen - benammen "earste hân" - altyd nijsgjirrich, is it net?

Ferhaal 1. Supercronic en Docker hingje

Op ien fan 'e klusters krigen wy periodyk in beferzen Docker, dy't ynterfere mei it normale funksjonearjen fan it kluster. Tagelyk waard it folgjende waarnommen yn 'e Docker-logs:

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

…

Wat ús it meast ynteressearret oan dizze flater is it berjocht: pthread_create failed: No space left on device. Quick Study dokumintaasje ferklearre dat Docker gjin proses koe forke, dat is wêrom it periodyk beferzen.

By tafersjoch komt it folgjende byld oerien mei wat der bart:

In fergelykbere situaasje wurdt waarnommen op oare knopen:

Op deselde knopen sjogge wy:

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>

It die bliken dat dit gedrach is in gefolch fan de pod wurkjen mei superkronyk (in Go-hulpprogramma dat wy brûke om cron-taken yn pods út te fieren):

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

It probleem is dit: as in taak wurdt útfierd yn supercronic, ûntstiet it proses dêrtroch kin net korrekt beëinigje, oerset yn zombie.

remark: Om krekter te wêzen, prosessen wurde spawn troch cron-taken, mar supercronic is gjin init-systeem en kin net "adoptearje" prosessen dy't har bern hawwe. As SIGHUP- of SIGTERM-sinjalen wurde ferhege, wurde se net trochjûn oan 'e bernprosessen, wat resulteart yn' e bernprosessen net beëinigje en bliuwe yn zombiestatus. Jo kinne mear lêze oer dit alles, bygelyks, yn sa'n artikel.

D'r binne in pear manieren om problemen op te lossen:

1. As tydlike oplossing - fergrutsje it oantal PID's yn it systeem op in inkeld punt yn 'e tiid:

          /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. Of launch taken yn supercronic net direkt, mar mei help fan itselde tini, dy't yn steat is om prosessen korrekt te beëinigjen en zombies net te spawnen.

Ferhaal 2. "Zombies" by it wiskjen fan in cgroup

Kubelet begon in protte CPU te konsumearjen:

Nimmen sil dit leuk fine, dus wy wapene ússels perfekt en begûn te gean mei it probleem. De resultaten fan it ûndersyk wiene as folget:

• Kubelet besteget mear as in tredde fan syn CPU-tiid oan it lûken fan ûnthâldgegevens fan alle cgroups:

  

• Yn 'e mailinglist fan kernelûntwikkelders kinne jo fine diskusje oer it probleem. Koartsein komt it punt hjirop del: ferskate tmpfs-bestannen en oare ferlykbere dingen wurde net folslein fan it systeem fuortsmiten by it wiskjen fan in cgroup, de saneamde memcg zombie. Ier of letter sille se wiske wurde fan 'e side-cache, mar d'r is in soad ûnthâld op' e tsjinner en de kearn sjocht it punt net om tiid te fergriemen op it wiskjen. Dêrom bliuwe se opstapelen. Wêrom bart dit sels? Dit is in tsjinner mei cron banen dy't hieltyd skept nije banen, en mei harren nije pods. Sa wurde nije cgroups makke foar konteners dêryn, dy't gau wiske wurde.
• Wêrom fergriemt cAdvisor yn kubelet safolle tiid? Dit is maklik te sjen mei de ienfâldichste útfiering time cat /sys/fs/cgroup/memory/memory.stat. As op in sûne masine de operaasje duorret 0,01 sekonden, dan op 'e problematyske cron02 duorret it 1,2 sekonden. It ding is dat cAdvisor, dy't gegevens fan sysfs heul stadich lêst, besiket rekken te hâlden mei it ûnthâld dat brûkt wurdt yn zombie cgroups.
• Om zombies krêftich te ferwiderjen, hawwe wy besocht caches te wiskjen lykas oanrikkemandearre yn LKML: sync; echo 3 > /proc/sys/vm/drop_caches, - mar de kearn bleek yngewikkelder te wêzen en botste mei de auto.

Wat te dwaan? It probleem wurdt repareare (bedriuwe, en foar in beskriuwing sjoch release berjocht) kernel-update Linux oant ferzje 4.16.

Skiednis 3. Systemd en syn berch

Nochris verbruikt de kubelet tefolle boarnen op guon knopen, mar dizze kear konsumearret it tefolle ûnthâld:

It die bliken dat der in probleem wie mei systemd dy't brûkt waard yn Ubuntu 16.04, en it komt foar by it behearen fan mounts dy't makke binne foar ferbining subPath fan ConfigMap's of geheimen. Nei't de pod syn wurk foltôge hat de systemd tsjinst en syn tsjinst mount bliuwe yn systeem. Yn 'e rin fan' e tiid sammele in grut oantal fan harren. D'r binne sels problemen oer dit ûnderwerp:

1. #5916;
2. kubernetes #57345.

...de lêste ferwiist nei de PR yn systemd: #7811 (probleem yn systemd - #7798).

It probleem is der net mear Ubuntu 18.04, mar as jo trochgean wolle mei brûken Ubuntu 16.04, jo kinne ús oplossing foar dit ûnderwerp nuttich fine.

Dat wy makken de folgjende 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

... en it brûkt it folgjende skript:

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

... en it rint elke 5 minuten mei de earder neamde supercronic. It Dockerfile sjocht der sa út:

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

Ferhaal 4. Konkurrinsjefermogen by it plannen fan pods

It waard opmurken dat: as wy in pod hawwe pleatst op in knooppunt en syn byld wurdt útpompt foar in heul lange tiid, dan sil in oare pod dy't deselde knoop "treffe" gewoan begjint net te lûken it byld fan de nije pod. Ynstee dêrfan wachtet it oant it byld fan 'e foarige pod wurdt lutsen. As resultaat sil in pod dy't al pland wie en wêrfan de ôfbylding yn mar in minút ynladen wurde koe, einigje yn 'e status fan containerCreating.

De eveneminten sille der sa útsjen:

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

It bliuwt dat in inkele ôfbylding fan in trage register kin ynset blokkearje per knooppunt.

Spitigernôch binne d'r net folle manieren út 'e situaasje:

1. Besykje jo Docker Registry direkt te brûken yn it kluster of direkt mei it kluster (bygelyks GitLab Registry, Nexus, ensfh.);
2. Brûk nutsbedriuwen lykas kraken.

Ferhaal 5. Knooppunten hingje troch gebrek oan ûnthâld

Tidens de eksploitaasje fan ferskate applikaasjes, wy tsjinkaam ek in situaasje dêr't in knooppunt folslein ophâldt te wêzen tagonklik: SSH reagearret net, alle tafersjoch daemon falle ôf, en dan is der neat (of hast neat) abnormale yn de logs.

Ik sil jo yn ôfbyldings fertelle mei it foarbyld fan ien knooppunt wêr't MongoDB funksjonearre.

Dit is hoe't boppe op sjocht до ûngelokken:

En sa - после ûngelokken:

By it tafersjoch is d'r ek in skerpe sprong, wêrby't it knooppunt ophâldt beskikber te wêzen:

Sa is út 'e skermôfbyldings dúdlik dat:

1. De RAM op 'e masine is tichtby de ein;
2. Der is in skerpe sprong yn RAM-konsumpsje, wêrnei't tagong ta de hiele masine abrupt útskeakele is;
3. In grutte taak komt op Mongo, dy't it DBMS-proses twingt om mear ûnthâld te brûken en aktyf te lêzen fan skiif.

It docht bliken dat as yn Linux frij ûnthâld rekket op (ûnthâlddruk ûntstiet) en der is gjin swap, dan до As de OOM-moardner oankomt, kin der in lykwichtsaksje ûntstean tusken it smiten fan siden yn de side-cache en it weromskriuwen fan se op skiif. Dit wurdt dien troch kswapd, dy't moedich safolle mooglik ûnthâldsiden frijmakket foar folgjende distribúsje.

Spitigernôch, mei in grutte I / O-lading kombinearre mei in lyts bedrach fan fergees ûnthâld, kswapd wurdt de flessehals fan it hiele systeem, om't se der oan bûn binne allegear allocations (side flaters) fan ûnthâld siden yn it systeem. Dit kin hiel lang trochgean as de prosessen gjin ûnthâld mear brûke wolle, mar oan de râne fan de OOM-killer ôfgrûn fêstlizze.

De natuerlike fraach is: wêrom komt de OOM-moardner sa let? Yn syn hjoeddeistige iteraasje is de OOM-moardner ekstreem dom: it sil it proses allinich deadzje as it besykjen om in ûnthâldside te allocearjen mislearret, d.w.s. as de side flater mislearret. Dit bart net foar in hiel lange tiid, om't kswapd moedich ûnthâldsiden befrijt, en de side-cache (de heule skiif I/O yn it systeem, trouwens) werom nei skiif dumpt. Yn mear detail, mei in beskriuwing fan 'e stappen dy't nedich binne om sokke problemen yn' e kernel te eliminearjen, kinne jo lêze hjir.

Dit gedrach moatte ferbetterje mei in kearn Linux 4.6+.

Ferhaal 6. Pods komme fêst yn Pending state

Yn guon klusters, wêryn't d'r echt in protte pods wurkje, begon wy te merken dat de measten fan har in heul lange tiid yn 'e steat "hingje" Pending, hoewol de Docker-konteners sels al op 'e knopen rinne en kinne mei de hân wurke wurde.

Boppedat, yn describe der is neat mis:

  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

Nei wat graven hawwe wy de oanname makke dat de kubelet gewoan gjin tiid hat om alle ynformaasje oer de steat fan 'e pods en tests foar liveness / reewilligens nei de API-tsjinner te stjoeren.

En nei it studearjen fan help, fûnen wy de folgjende parameters:

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

Lykas sjoen, standertwearden binne frij lyts, en yn 90% dekke se alle behoeften ... Yn ús gefal wie dit lykwols net genôch. Dêrom sette wy de folgjende wearden yn:

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

... en de kubelets opnij starte, wêrnei't wy de folgjende ôfbylding seagen yn 'e grafiken fan oproppen nei de API-tsjinner:

... en ja, alles begûn te fleanen!

PS

Foar har help by it sammeljen fan bugs en it tarieden fan dit artikel, uterje ik myn djippe tankberens oan 'e ferskate yngenieurs fan ús bedriuw, en foaral oan myn kollega fan ús R&D-team Andrey Klimentyev (zuzzas).

PPS

Lês ek op ús blog:

• «kubectl-debug plugin foar debuggen yn Kubernetes pods".
• Kubernetes tips & tricks loop:
  • «Boarnen dy't rinne yn in kluster oerdrage nei Helm 2-behear";
  • «Oer node tawizing en loads op in web applikaasje";
  • «Tagong ta dev sites";
  • «Bootstrap fersnelle foar grutte databases".

Boarne: www.habr.com