Meriv çawa xwe bigihîne çavkaniyên Kubernetes Pod

Meriv çawa xwe bigihîne çavkaniyên Kubernetes PodXelat ji aliyê Tohad

Dema ku bi Kubernetes re dest pê dike, gelemperî ye ku meriv sazkirina çavkaniyên konteynerê ji bîr bike. Di vê nuqteyê de, bes e ku meriv pê ewle bibe ku wêneya Docker dixebite û dikare li koma Kubernetes were bicîh kirin.

Lê paşê pêdivî ye ku serîlêdan li gel serîlêdanên din di komek hilberînê de were bicîh kirin. Ji bo kirina vê yekê, hûn hewce ne ku çavkaniyan ji bo konteynerê veqetînin û pê ewle bin ku têra wan hene ku serîlêdanê ragihînin û bixebitin, û ku serîlêdanên din ên xebitandinê dê pirsgirêkan nebînin.

tîma Kubernetes aaS ji Mail.ru gotarek li ser çavkaniyên konteynerê (CPU & MEM), daxwaz û sînorên çavkaniyê wergerandin. Hûn ê feydeyên van mîhengan fêr bibin û heke hûn wan saz nekin çi diqewime.

Çavkaniyên Computing

Du celeb çavkaniyên me bi yekîneyên jêrîn hene:

  • Yekîneya pêvajoyê ya navendî (CPU) - core;
  • Bîr (MEM) - bytes.

Çavkanî ji bo her konteynir têne diyar kirin. Di pelê Pod YAML ya jêrîn de, hûn ê beşek çavkaniyê bibînin ku çavkaniyên daxwazkirî û sînorkirî dihewîne:

  • Çavkaniyên Pod ên Daxwazkirî = berhevoka çavkaniyên daxwazkirî yên hemî konteyneran;
  • Sînorê Çavkaniya Pod = Berhevoka Hemî Sînorên Çavkaniya Pod.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

Mînaka Çavkaniyên Daxwazî ​​û Bisînor

warê resources.requested ji taybetmendiyê Pod yek ji hêmanan e ku ji bo dîtina girêka xwestî tê bikar anîn. Jixwe hûn dikarin ji bo wê danîna Pod plan bikin. Meriv çawa girêkek minasib dibîne?

Kubernetes ji çend hêmanan pêk tê, di nav de girêkek sereke an jî girêkek master (Balafira Kontrolê ya Kubernetes). Node master çend pêvajoyên xwe hene: kube-apiserver, kube-kontroller-manager û kube-scheduler.

Pêvajoya kube-scheduler berpirsiyar e ji bo vekolîna podên ku nû hatine afirandin û dîtina girêkên karker ên mimkun ên ku bi hemî daxwazên pod re têkildar in, tevî hejmara çavkaniyên hatine xwestin. Navnîşa girêkên ku ji hêla kube-scheduler ve hatine dîtin rêzkirî ye. Pod li ser girêka bi pûanên herî bilind tê plansaz kirin.

Meriv çawa xwe bigihîne çavkaniyên Kubernetes PodDê Podê binefşî li ku derê were danîn?

Di wêneyê de hûn dikarin bibînin ku kube-scheduler divê Podek nû ya binefşî plansaz bike. Koma Kubernetes du girêk dihewîne: A û B. Wekî ku hûn dibînin, kube-scheduler nikare Podek li ser girêka A-yê plansaz bike - çavkaniyên berdest (ne daxwazkirî) bi daxwazên Pod-a binefşî re hev nagirin. Ji ber vê yekê, bîranîna 1 GB ya ku ji hêla Pod-a binefşî ve hatî daxwaz kirin dê li ser girêka A bicîh nebe, ji ber ku bîra berdest 0,5 GB ye. Lê girêka B têra xwe çavkaniyên xwe hene. Wekî encamek, kube-scheduler biryar dide ku mebesta Pod-a binefşî node B ye.

Naha em dizanin ka çavkaniyên daxwazkirî çawa bandorê li bijartina nodê dike ku Pod bimeşîne. Lê bandora çavkaniyên marjînal çi ye?

Sînorê çavkaniyê sînorek e ku CPU/MEM nikare derbas bike. Lêbelê, çavkaniya CPU-ê maqûl e, ji ber vê yekê konteynerên ku digihîjin sînorên xwe yên CPU dê nebin sedema derketina Pod. Di şûna wê de, kişandina CPU dê dest pê bike. Ger sînorê karanîna MEM-ê bigihîje, konteynir dê ji ber OOM-Killer were sekinandin û heke ji hêla mîhenga RestartPolicy ve were destûr kirin dê ji nû ve were destpêkirin.

Çavkaniyên xwestin û herî zêde bi hûrgulî

Meriv çawa xwe bigihîne çavkaniyên Kubernetes PodTêkiliya çavkaniyê di navbera Docker û Kubernetes de

Awayê çêtirîn ku meriv rave bike ka daxwazên çavkaniyê û sînorên çavkaniyê çawa dixebitin ev e ku meriv têkiliya di navbera Kubernetes û Docker de destnîşan bike. Di wêneya jor de hûn dikarin bibînin ka zeviyên Kubernetes û alayên destpêka Docker çawa bi hev ve girêdayî ne.

Bîranîn: daxwaz û sînorkirin

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Wekî ku li jor jî hate destnîşan kirin, bîranîn bi byteyan tê pîvandin. Çi qewimî Belgekirina Kubernetes, em dikarin bîrê wekî jimare diyar bikin. Bi gelemperî ew yekjimarek e, mînakî 2678 - ango 2678 byte. Hûn dikarin paşgiran jî bikar bînin G и Gi, Ya sereke ev e ku ji bîr mekin ku ew ne wekhev in. Yekem dehemîn û ya duyemîn jî binar e. Mîna mînaka ku di belgeya k8s de hatî destnîşan kirin: 128974848, 129e6, 129M, 123Mi - ew di pratîkê de wekhev in.

Vebijêrk Kubernetes limits.memory ala hev dike --memory ji Docker. Di rewşê de request.memory Ji bo Docker tîrek tune ji ber ku Docker vê qadê bikar nayîne. Hûn dikarin bipirsin, gelo ev pêdivî ye? Erê hewce ye. Wekî ku min berê jî got, zevî ji bo Kubernetes girîng e. Li ser bingeha agahdariya ji wê, kube-scheduler biryar dide ku li ser kîjan girêka Pod-ê plansaz bike.

Heke hûn ji bo daxwazek bîranînek têr nake, çi dibe?

Ger konteynir gihîştibe sînorên bîranîna daxwazkirî, wê hingê Pod di komek Pod de tê danîn ku dema ku têra bîra di girêkê de nebe disekine.

Heke hûn sînorê bîranînê pir kêm destnîşan bikin çi dibe?

Ger konteynir ji sînorê bîranînê derbas bibe, ew ê ji ber OOM-Killed were qedandin. Û heke gengaz be dê li ser bingeha RestartPolicy ku nirxa xwerû ye ji nû ve dest pê bike Always.

Ger hûn bîranîna daxwazkirî diyar nekin çi dibe?

Kubernetes dê nirxa sînor bigire û wê wekî nirxa xwerû destnîşan bike.

Heke hûn sînorek bîranînê diyar nekin dikare çi bibe?

Di konteynerê de ti sînorkirin tune; ew dikare bi qasî ku bixwaze bîranînê bikar bîne. Ger ew dest bi karanîna hemî bîranîna berdest a nodê bike, wê hingê OOM dê wî bikuje. Dûv re konteynir heke gengaz be li ser bingeha RestartPolicy ji nû ve were destpêkirin.

Ger hûn sînorên bîranînê diyar nekin çi dibe?

Ev senaryoya herî xirab e: plansaz nizane ku konteynir çend çavkaniyan hewce dike, û ev dikare bibe sedema pirsgirêkên cidî li ser girêk. Di vê rewşê de, dê xweş be ku sînorên xwerû li ser cîhê navan (ji hêla LimitRange ve hatî danîn) hebin. Ti sînorên xwerû tune - Pod bê sînor e, ew dikare bi qasî ku bixwaze bîranînê bikar bîne.

Ger bîranîna daxwazkirî ji ya ku girêk dikare pêşkêşî bike zêdetir be, dê Pod neyê plansaz kirin. Vê girîng e ku hûn bîr bînin Requests.memory - ne nirxa herî kêm. Ev danasînek mîqdara bîranînê ye ku bes e ku konteynir bi berdewamî bixebite.

Bi gelemperî tê pêşniyar kirin ku ji bo heman nirxê were danîn request.memory и limit.memory. Ev piştrast dike ku Kubernetes dê Podek li ser girêkek ku têra wê bîranînê ye ku Pod bimeşîne lê têrê nake ku wê bixebite nexşe bike. Bînin bîra xwe: Plansaziya Kubernetes Pod tenê hesab dike requests.memoryû limits.memory nahesibîne.

CPU: daxwaz û sînor

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Bi CPU re her tişt hinekî tevlihevtir e. Vegera wêneya têkiliya di navbera Kubernetes û Docker de, hûn dikarin wê bibînin request.cpu peyda dike --cpu-shares, lêbelê limit.cpu ala hev dike cpus li Docker.

CPU-ya ku Kubernetes daxwaz dike bi 1024-ê, rêjeya çerxên CPU-yê tê zêdekirin. Heke hûn dixwazin 1 bingeha tevahî daxwaz bikin, divê hûn lê zêde bikin cpu: 1wek ku li jor tê nîşandan.

Daxwaza kernelek tam (nîsbet = 1024) nayê vê wateyê ku konteynera we wê wergire. Ger makîneya weya mêvandar tenê yek bingehek heye û hûn ji yek konteyneran zêdetir dimeşînin, wê hingê divê hemî konteyneran CPU-ya berdest di navbera wan de parve bikin. Ev çawa dibe? Ka em li wêneyê binêrin.

Meriv çawa xwe bigihîne çavkaniyên Kubernetes Pod
Daxwaza CPU - Pergala Yekane Core

Ka em bifikirin ku we pergalek mêvandar a yek-core heye ku konteyneran dimeşîne. Mom (Kubernetes) piçek (CPU) pejandiye û dixwaze di navbera zarokan (konteyniran) de dabeş bike. Sê zarok pîçeka tev dixwazin (nîsbet = 1024), zarokekî din nîvê pîvazê dixwaze (512). Mom dixwaze adil be û hesabek hêsan dike.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Li ser bingeha hesabkirinê, sê zarok dê 28% ji bingehîn bistînin, û ne tevahiya bingehîn. Zarokê çaremîn dê 14% ji kernelê tije bistîne, ne nîvê. Lê heke we pergalek pir-core hebe dê tişt cûda bibin.

Meriv çawa xwe bigihîne çavkaniyên Kubernetes Pod
Daxwaza CPU - Pergala Pir-Core (4).

Di wêneya li jor de hûn dikarin bibînin ku sê zarok pîçek tevahî dixwazin, û yek jî nîvî dixwaze. Ji ber ku dayikê çar pîvaz çêkiriye, her yek ji zarokên wê bi qasî ku bixwaze dê bistîne. Di pergalek pir-bingehîn de, çavkaniyên pêvajoyê li hemî navgînên pêvajoyê yên berdest têne belav kirin. Ger konteynir bi kêmtirî yek bingehê CPU-ya tije ve sînorkirî be, ew dîsa jî dikare wê 100% bikar bîne.

Hesabên jorîn têne hêsan kirin da ku fêm bikin ka CPU çawa di nav konteyneran de tê belavkirin. Bê guman, ji bilî konteyneran bixwe, pêvajoyên din jî hene ku çavkaniyên CPU-yê jî bikar tînin. Dema ku pêvajoyên di yek konteynerê de bêkar in, yên din dikarin çavkaniya wê bikar bînin. CPU: "200m" peyda dike CPU: 0,2, ku tê wateya nêzîkî 20% ji yek bingehîn.

Niha em li ser biaxivin limit.cpu. CPU ya ku Kubernetes sînor dike bi 100-ê tê zêdekirin. Encam ew e ku konteynir her 100 μs bikar bîne (cpu-period).

limit.cpu ala Docker li hev dike --cpus. Ev tevliheviyek nû ya kevn e --cpu-period и --cpu-quota. Bi danîna wê, em destnîşan dikin ka çend çavkaniyên CPU-yê yên berdest konteynir dikare herî zêde bikar bîne berî ku dest pê bike:

  • cpus - kombînasyona cpu-period и cpu-quota. cpus = 1.5 wekhevkirina mîhengê cpu-period = 100000 и cpu-quota = 150000;
  • CPU-dem - serdem CPU CFS scheduler, default 100 microseconds;
  • cpu-kota - hejmara mîkro çirkeyan di hundurê de cpu-period, ku ji hêla konteynerê ve girêdayî ye.

Ger hûn CPU-ya têra daxwazkirî saz bikin çi dibe?

Ger konteynir ji ya ku saz kiriye zêdetir hewce bike, ew ê CPU-yê ji pêvajoyên din bidize.

Ger hûn sînorê CPU-yê pir kêm destnîşan bikin çi dibe?

Ji ber ku çavkaniya CPU-ê verastkirî ye, throttling dê vebe.

Ger hûn daxwazek CPU diyar nekin çi dibe?

Mîna bîranînê, nirxa daxwazê ​​bi sînor re wekhev e.

Ger hûn sînorê CPU-ê diyar nekin çi dibe?

Dê konteynir bi qasî ku hewce bike CPU bikar bîne. Ger di qada navan de polîtîkaya CPU-ya xwerû (LimitRange) were destnîşankirin, wê hingê ev sînor ji bo konteynerê jî tê bikar anîn.

Ger hûn daxwazek an jî sînorê CPU-ê diyar nekin çi dibe?

Mîna bîranînê, ev senaryoya herî xirab e. Plansaz nizane ku konteynera we çend çavkaniyan hewce dike, û ev dikare bibe sedema pirsgirêkên cidî li ser girêkê. Ji bo ku hûn ji vê yekê dûr nekevin, hûn hewce ne ku ji bo cîhên navan (LimitRange) sînorên xwerû destnîşan bikin.

Bînin bîra xwe: heke hûn CPU ji ya ku nod dikarin peyda bikin zêdetir daxwaz bikin, Pod dê neyê plansaz kirin. Requests.cpu - ne nirxa hindiktirîn, lê nirxek bes e ku Pod dest pê bike û bêyî têkçûn bixebite. Ger serîlêdan hesabên tevlihev pêk neyne, bijareya çêtirîn sazkirinê ye request.cpu <= 1 û bi qasî ku hewce be gelek kopiyan bidin destpêkirin.

Mîqdara îdeal a çavkaniyên daxwazkirî an sînorê çavkaniyê

Em li ser sînorkirina çavkaniyên komputerê fêr bûn. Naha ew dem e ku em bersiva pirsê bidin: "Poda min çend çavkaniyan hewce dike ku serîlêdanê bêyî pirsgirêk bimeşîne? Mîqdara îdeal çi ye?

Mixabin, bersivên zelal ên van pirsan tune. Heke hûn nizanin serîlêdana we çawa dixebite an çiqas CPU an bîranîna jê re lazim e, vebijarka çêtirîn ev e ku hûn gelek bîranîn û CPU bidin serîlêdanê û dûv re ceribandinên performansê bikin.

Digel ceribandinên performansê, hefteyek di şopandinê de tevgera serîlêdanê bişopînin. Ger grafîk destnîşan dikin ku serîlêdana we ji ya ku we xwestiye kêmtir çavkaniyan dixwe, hûn dikarin mîqdara CPU an bîranîna tê xwestin kêm bikin.

Wek nimûne vê yekê bibînin Tabloya Grafana. Ew cûdahiya di navbera çavkaniyên daxwazkirî an sînorê çavkaniyê û karanîna çavkaniya heyî de nîşan dide.

encamê

Daxwazkirin û bisînorkirina çavkaniyan dibe alîkar ku koma Kubernetes te saxlem bimîne. Veavakirina sînorê rast lêçûn kêm dike û sepanan her dem dimeşîne.

Bi kurtasî, çend tişt hene ku meriv ji bîr neke:

  1. Çavkaniyên daxwazkirî vesazkirinek e ku di dema destpêkirinê de tête hesibandin (gava Kubernetes plan dike ku serîlêdanê mêvandar bike). Berevajî vê, sînorkirina çavkaniyan di dema xebitandinê de girîng e - gava ku serîlêdan jixwe li ser nodê dimeşe.
  2. Li gorî bîranînê, CPU çavkaniyek birêkûpêk e. Ger CPU têra xwe tune be, Pod-a we nayê girtin û mekanîzmaya rijandinê dê vebe.
  3. Çavkaniyên daxwazkirî û sînorê çavkaniyê ne nirxên herî kêm û herî zêde ne! Bi danasîna çavkaniyên daxwazkirî, hûn piştrast dikin ku serîlêdan dê bê pirsgirêk bimeşe.
  4. Pratîkek baş ev e ku meriv daxwaza bîranînê bi sînorê bîranînê re wekhev bike.
  5. Ok sazkirinê tê xwestin CPU <=1, heke serîlêdan hesabên tevlihev nake.
  6. Ger hûn bêtir çavkaniyan ji ya ku li ser girêkek peyda dibin daxwaz bikin, Pod dê çu carî ji wê girêkê re neyê plansaz kirin.
  7. Ji bo destnîşankirina rêjeya rast a çavkaniyên / sînorên çavkaniyê yên daxwazkirî, ceribandin û çavdêriya barkirinê bikar bînin.

Ez hêvî dikim ku ev gotar ji we re dibe alîkar ku hûn têgeha bingehîn a sînorkirina çavkaniyê fam bikin. Û hûn ê bikaribin vê zanînê di karê xwe de bicîh bikin.

Bextê te xweş bî

Wekî din çi bixwînin:

  1. Çavdêriya SRE: Navên nav û Structure Metric.
  2. Zêdetirî 90 Amûrên Kêrhatî ji bo Kubernetes: Dabeşkirin, Rêvebirin, Çavdêrî, Ewlekarî û Zêdetir.
  3. Kanala me li dora Kubernetes di Telegram de.

Source: www.habr.com

Add a comment