ProHoster > 6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

GjatĂ« viteve tĂ« pĂ«rdorimit tĂ« Kubernetes nĂ« produkcion, ne kemi mbledhur shumĂ« histori interesante se si defektet nĂ« komponentĂ«t e ndryshĂ«m sistemor çonin nĂ« pasoja tĂ« pakĂ«ndshme dhe/ose tĂ« paqarta qĂ« ndikonin nĂ« funksionimin e kontejnerĂ«ve dhe pod-eve. NĂ« kĂ«tĂ« artikull kemi pĂ«rgatitur njĂ« pĂ«rzgjedhje tĂ« disa prej mangĂ«sive mĂ« tĂ« shpeshta ose mĂ« interesante nga ato. Edhe nĂ«se ju nuk do keni fatin tĂ« pĂ«rballeni ndonjĂ«herĂ« me situata tĂ« tilla, leximi rreth kĂ«tyre detektivĂ«ve tĂ« shkurtĂ«r — sidomos, "nga burime tĂ« para" — Ă«shtĂ« gjithmonĂ« argĂ«tues, apo jo?..

Historia 1. Supercronic dhe Docker-i i ngecur

Në një nga klasterët tanë, përherë e më shumë merrnim një Docker të "ngecur", që e pengonte funksionimin normal të klasterit. Në të njëjtën kohë, në logjet e Docker-it vërehej kjo

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




Në këtë gabim, ajo që na intereson më shumë është mesazhi: pthread_create failed: No space left on device. Një studim i shpejtë dokumentacionin tregoi se Docker nuk mund të fillonte një proces, për shkak të së cilës përherë e më shumë "ngecte".

NĂ« monitorim, ky ishte pamja:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Një situatë e ngjashme vërehet edhe në nyja të tjera:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Në këto nyja po ashtu shohim:

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] 
root     17398  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     16852  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      9473  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      4664  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     30571  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     24113  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root     16475  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      7176  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] 
root      1090  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl]

Doli se, ky sjellje është pasojë e aktivitetit të pod-it me supercronic (një utilitar në Go, që ne e përdorim për të ekzekutuar detyra cron në pod-e):

 _ 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] 
|       _ [curl] 
|       _ [curl] 
|       _ [curl] 



Problemi është si vijon: kur një detyrë aktivizohet në supercronic, procesi i krijuar prej tij, nuk mund të përfundojë siç duhet, duke u shndërruar në zombi.

Shënim: Nëse flasim më saktë, proceset krijohen nga detyrat cron, megjithatë supercronic nuk është një sistem init dhe nuk ka mundësi "të adoptojë" proceset që krijojnë fëmijët e tij. Kur ndodhin sinjalet SIGHUP ose SIGTERM, ato nuk kalojnë te proceset e krijuara, duke sjellë kështu që proceset fëmijë nuk përfundojnë dhe mbeten në statusin zombi. Më shumë rreth kësaj mund të lexoni, për shembull, në një artikull të tillë.

Ka disa mënyra për të zgjidhur problemet:

  1. Si njĂ« zgjidhje pĂ«rkohĂ«sore — rritni numrin e PID-ve nĂ« sistem nĂ« njĂ« moment tĂ« vetĂ«m:
           /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. Ose, mund të aktivizoni detyrat në supercronic jo direkt, por me ndihmën e të njëjtit tini, i cili ka aftësi për të përfunduar proceset siç duhet dhe nuk prodhon zombi.

Historia 2. "Zombit" gjatë fshirjes së cgroup

Kubelet filloi të konsumonte shumë CPU:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Kjo nuk do t'i pëlqejë askujt, prandaj armatohemi perf dhe filluam të hetojmë problemin. Rezultatet e hetimit rezultuan si vijon:

  • Kubelet po shpenzon mĂ« shumĂ« se njĂ« tĂ« tretĂ«n e kohĂ«s sĂ« procesorit pĂ«r tĂ« nxjerrĂ« tĂ« dhĂ«na nĂ« lidhje me memorinĂ« nga tĂ« gjitha cgroup:

    6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

  • NĂ« listĂ«n e zhvilluesve tĂ« bĂ«rthamĂ«s mund tĂ« gjeni diskutimin e problemit. NĂ«se pĂ«rshkruhet shkurt, thelbi Ă«shtĂ« se skedarĂ«t e ndryshĂ«m tmpfs dhe gjĂ«rat e ngjashme nuk fshihen plotĂ«sisht nga sistemi kur fshihet cgroup — mbeten tĂ« ashtuquajturat memcg zombi. PavarĂ«sisht se do tĂ« fshihen nga cache e faqes, memorie nĂ« server ka shumĂ« dhe bĂ«rthama nuk sheh ndonjĂ« kuptim pĂ«r tĂ« kaluar kohĂ« nĂ« fshirjen e tyre. Prandaj, ata vazhdojnĂ« tĂ« grumbullohen. Pse ndodh kjo? Ky Ă«shtĂ« njĂ« server me detyra cron, i cili vazhdimisht krijon punĂ« tĂ« reja, dhe me to — pod tĂ« rinj. KĂ«shtu, krijohen cgroup tĂ« reja pĂ«r konteinerĂ«t, tĂ« cilat shumĂ« shpejt fshihen.
  • Pse cAdvisor nĂ« kubelet shpenzon kaq shumĂ« kohĂ«? ËshtĂ« e lehtĂ« ta shikosh me njĂ« ekzekutim tĂ« thjeshtĂ« time cat /sys/fs/cgroup/memory/memory.stat. NĂ«se nĂ« njĂ« makinĂ« tĂ« shĂ«ndetshme operacioni zĂ« 0.01 sekonda, nĂ« makinĂ« problematike cron02 zĂ« 1.2 sekonda. TĂ« gjitha janĂ« pĂ«r shkak se cAdvisor lexon tĂ« dhĂ«na nga sysfs tepĂ«r ngadalĂ« dhe pĂ«rpiqet tĂ« marrĂ« parasysh memorjen e pĂ«rdorur dhe nĂ« cgroups zombi.
  • PĂ«r tĂ« fshirĂ« me forcĂ« zombi, provuam tĂ« pastroni cache-in, siç rekomandohej nĂ« LKML: sync; echo 3 > /proc/sys/vm/drop_caches,— por bĂ«rthama u duk mĂ« komplekse dhe e mbylli makinĂ«n.

ÇfarĂ« duhet tĂ« bĂ«jmĂ«? Problemi rregullohet (komit, pĂ«rshkrimin e shihni nĂ« njoftimin e lançimit) duke pĂ«rditĂ«suar bĂ«rthamĂ«n Linux nĂ« versionin 4.16.

Historia 3. Systemd dhe montimi i tij

SĂ«rish kubelet konsumon shumĂ« burime nĂ« disa nyje, por kĂ«tĂ« herĂ« — pĂ«rveç inteligjencĂ«s — tashmĂ« Ă«shtĂ« memorie:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Doli që kishte një problem me systemd, i përdorur në Ubuntu 16.04, dhe ndodhi gjatë menaxhimit të mount-ave që krijoheshin për lidhjen subPath nga ConfigMap ose sekret. Pas përfundimit të punës së pod-it shërbimi systemd dhe montimi i tij mbeten në sistem. Me kalimin e kohës, grumbullohen një numër i madh. Në këtë temë ka madje çështje:

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


 nĂ« tĂ« fundit pĂ«rmenden PR nĂ« systemd: #7811 (çështja nĂ« systemd — #7798).

Problemi nuk ekziston më në Ubuntu 18.04, por nëse dëshironi të vazhdoni të përdorni Ubuntu 16.04, mund t'ju duhen zgjidhjet tona për këtë temë.

Pra, ne bëmë DaemonSet-in e mëposhtëm:

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


 dhe përdoret një skenar i tillë:

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


 dhe ai niset çdo 5 minuta me ndihmĂ«n e supercronic qĂ« pĂ«rmendet mĂ« parĂ«. Dockerfile i tij dukej kĂ«shtu:

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

Historia 4. Konkurrenca në planifikimin e podëve

ËshtĂ« vĂ«rejtur se: nĂ«se kemi njĂ« pod qĂ« vendoset nĂ« njĂ« nod dhe imazhi i tij merret shumĂ« ngadalĂ«, atĂ«herĂ« njĂ« pod tjetĂ«r qĂ« "ka rĂ«nĂ«" nĂ« kĂ«tĂ« nod thjesht nuk fillon tĂ« tĂ«rheqĂ« imazhin e pod-it tĂ« ri. NĂ« vend tĂ« kĂ«saj, ai pret derisa tĂ« pĂ«rfundojĂ« tĂ«rheqja e imazhit tĂ« pod-it tĂ« mĂ«parshĂ«m. Si rezultat, pod-i qĂ« tashmĂ« ishte planifikuar dhe imazhi i tij mund tĂ« shkarkohej pĂ«r vetĂ«m njĂ« minutĂ«, mund tĂ« mbetet pĂ«r njĂ« kohĂ« tĂ« gjatĂ« nĂ« statusin containerCreating.

Në ngjarje do të jetë përafërsisht si më poshtë:

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

Kështu që një imazh i vetëm nga një regjistër i ngadaltë mund të bllokojë vendosjen në nod.

Fatkeqësisht, nuk ka shumë zgjidhje për këtë:

  1. Përpiquni të përdorni regjistrin tuaj Docker direkt në klasër ose direkt me klasrën (për shembull, GitLab Registry, Nexus, etj.);
  2. Shfrytëzoni mjete të tilla si kraken.

Historia 5. Ndalimi i nyjeve për shkak të mungesës së memories

Gjatë përdorimit të aplikacioneve të ndryshme, kemi hasur situata ku një nyje plotësisht pushon së qeni e aksesueshme: nuk përgjigjet SSH, të gjitha demonët e monitorimit ndalen, dhe në log nuk ka (ose pothuajse asgjë) anomali.

Do të tregoj me figura për një nyje ku funksiononte MongoDB.

Kështu duket atop në dëmtimi:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Dhe kĂ«shtu — pas dĂ«mtimi:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Në monitorim gjithashtu vërehet një ngritje e menjëhershme, ku nyja pushon së qeni e aksesueshme:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]

Prandaj, nga screenshotet duket se:

  1. Memoria operativë në makinë është afër fundit;
  2. Vërehet një ngritje e menjëhershme të konsumit të memories operativë, pas së cilës ndalon rëndë aksesin në të gjithë makinën;
  3. Në Mongo bie një detyrë e madhe, e cila e detyron procesin e DBMS të përdorë më shumë memory dhe të lexojë aktivisht nga disku.

ËshtĂ« fakt se nĂ«se nĂ« Linux pĂ«rfundon memoria e lirĂ« (ndodh presioni i memories) dhe swap nuk ka, atĂ«herĂ« nĂ« ardhja e OOM killer mund tĂ« ndodhi ekuilibrimi midis hedhjes sĂ« faqeve nĂ« cache dhe tĂ« shkruarit e tyre pĂ«rsĂ«ri nĂ« disk. KĂ«saj i merr pĂ«rsipĂ«r kswapd, i cili guximshĂ«m çliron sa mĂ« shumĂ« faqe tĂ« memories pĂ«r shpĂ«rndarje tĂ« mĂ«tejshme.

Fatkeqësisht, me ngarkesë të madhe I/O së bashku me një sasi të vogël të memories së lirë, kswapd bëhet shishja e shishkave të sistemit, sepse mbi të lidhen të gjithë ndarjet (page faults) e faqeve të memories në sistem. Kjo mund të vazhdojë shumë gjatë, nëse proceset nuk duan të përdorin më shumë memorie, por ngjiten në skaj të humbjes OOM-killer.

Kjo ngjall pyetje: pse OOM killer vjen aq vonë? Në iteracionin e tij aktual OOM killer është jashtëzakonisht i përtacë: ai do të eliminojë procesin vetëm kur dështojë përpjekja për të alokuar një faqe memories, dmth. nëse page fault kalon me gabim. Kjo nuk ndodh për një kohë të gjatë, sepse kswapd guximshëm çliron faqe memories, duke hedhur cache-in e faqeve (të gjithë I/O të diskut në sistem, në thelb) përsëri në disk. Më shumë detaje, me përshkrimin e hapave të nevojshëm për të zgjidhur probleme të tilla në bërthamë, mund të lexoni këtu.

Kjo sjellje duhet të përmirësohet me bërthamën Linux 4.6+.

Historia 6. Pod’ëtĂ« ngecin nĂ« gjendje Pending

NĂ« disa klasterĂ«, ku ekzekutohen me tĂ« vĂ«rtetĂ« shumĂ« pod’ë, filluam tĂ« vĂ«rejmĂ« se njĂ« pjesĂ« e madhe e tyre ngec nĂ« gjendje Ja disa mundĂ«si (po supozoj se planifikuesi po funksionon normalisht):, megjithĂ«se vetĂ« kontejnerĂ«t Docker janĂ« tashmĂ« tĂ« lançuar nĂ« nyje dhe mund tĂ« punojmĂ« me ta manualisht.

Megjithatë, në përshkruaj nuk ka asgjë të keqe:

  Lloji    Arsyja                  Mosha               Nga                     Mesazhi
  ----    ------                  ----               ----                     -------
  Normal  Programuar              1m                  programuesi-default        Shpërndarja e suksesshme e sphinx-0 në ss-dev-kub07
  Normal  Ngjitur me Sukses     1m                  kontroluesi i ngjitur dhe të shkëputur  Suksesi i ngjitjes për volumin "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Vendosur me Sukses     1m                  kubelet, ss-dev-kub07    Vendosur me Sukses për volumin "sphinx-config"
  Normal  Vendosur me Sukses     1m                  kubelet, ss-dev-kub07    Vendosur me Sukses për volumin "default-token-fzcsf"
  Normal  Vendosur me Sukses     49s (x2 për 51s)  kubelet, ss-dev-kub07    Vendosur me Sukses për volumin "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Tërhequr               43s                kubelet, ss-dev-kub07    Imazhi i kontejnerit "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" tashmë është i pranishëm në makinë
  Normal  Krijuar                 43s                kubelet, ss-dev-kub07    Krijuar kontejner
  Normal  Nisin                   43s                kubelet, ss-dev-kub07    Nisin kontejner
  Normal  Tërhequr               43s                kubelet, ss-dev-kub07    Imazhi i kontejnerit "registry.example.com/infra/sphinx/sphinx:v1" tashmë është i pranishëm në makinë
  Normal  Krijuar                 42s                kubelet, ss-dev-kub07    Krijuar kontejner
  Normal  Nisin                   42s                kubelet, ss-dev-kub07    Nisin kontejner

Duke gĂ«rmuar, ne bĂ«mĂ« supozimin se kubelet-i thjesht nuk arrin tĂ« dĂ«rgojĂ« API-serverit tĂ« gjitha informacionet nĂ« lidhje me gjendjen e pod’ëve, proave tĂ« liveness/readiness.

Dhe pasi studiuam ndihmën, gjetëm parametrat e mëposhtëm:

--kube-api-qps - QPS të përdoret gjatë bisedës me API-serverin e kubernetes (default 5)
--kube-api-burst - Burst të përdoret gjatë bisedës me API-serverin e kubernetes (default 10) 
--event-qps - Nëse > 0, kufizo krijimet e ngjarjeve për sekondë në këtë vlerë. Nëse 0, pa kufizim. (default 5)
--event-burst - Madhësia maksimale e rekordit të ngjarjeve të përkohshme, lejon përkohësisht rekordet e ngjarjeve të arrijnë në këtë numër, duke mos e kaluar ende event-qps. Përdoret vetëm nëse --event-qps > 0 (default 10) 
--registry-qps - Nëse > 0, kufizo tërheqjet e regjistrit QPS në këtë vlerë.
--registry-burst - Madhësia maksimale e tërheqjeve të përkohshme, lejon përkohësisht tërheqjet të arrijnë në këtë numër, duke mos e kaluar ende registry-qps. Përdoret vetëm nëse --registry-qps > 0 (default 10)

As you can see, vlerat e paracaktuara — janĂ« mjaft tĂ« vogla, dhe nĂ« 90 % ato mbulojnĂ« tĂ« gjitha nevojat
 MegjithatĂ«, nĂ« rastin tonĂ« kjo ishte e pamjaftueshme. Prandaj ne vendosĂ«m kĂ«to vlera:

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


 dhe rinuam kubelet’ët, pas tĂ« cilave nĂ« grafiket e qasjes nĂ« API-server ne pamĂ« kĂ«tĂ« pamje:

6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]


 dhe po, gjithçka filloi tĂ« fluturojĂ«!

P.S.

Për ndihmën në grumbullimin e bug-eve dhe përgatitjen e artikullit, falënderoj me shumë mirënjohje inxhinierët tanë, dhe veçanërisht kolegun nga ekipi ynë R&D, Andrey Klimentiev.zuzzas).

P.P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster