Dema ku serîlêdana yekem li Kubernetes bicîh dikin pênc winda dibin

Dema ku serîlêdana yekem li Kubernetes bicîh dikin pênc winda dibinJi hêla Aris Dreamer ve têkçû

Pir kes difikirin ku bes e ku meriv serîlêdanê li Kubernetes veguhezîne (an Helm bikar bîne an jî bi destan bikar bîne) - û dê bextewar be. Lê her tişt ne ewqas hêsan e.

tîma Mail.ru Cloud Solutions gotarek ji hêla endezyar DevOps Julian Gindy ve hatî wergerandin. Ew vedibêje ku pargîdaniya wî di pêvajoya koçberiyê de bi çi xeletiyan re rû bi rû maye da ku hûn li ser heman rahê gav neavêjin.

Gav Yek: Daxwaz û Sînorên Pod Saz bikin

Werin em bi sazkirina jîngehek paqij a ku tê de polên me dê bimeşin dest pê bikin. Kubernetes di plansazkirin û têkçûna pod de mezin e. Lê derket holê ku nexşer carinan nikare podek bi cîh bike heke dijwar be ku texmîn bike ka çend çavkaniyan hewce dike ku bi serfirazî bixebite. Li vir daxwazên çavkaniyan û sînoran derdikevin holê. Li ser nêzîkbûna çêtirîn ji bo danîna daxwaz û sînoran gelek nîqaş hene. Carinan xuya dike ku ev bi rastî ji zanistiyê bêtir hunerek e. Li vir nêzîkatiya me ye.

Daxwazên Pod nirxa sereke ye ku ji hêla plansazker ve tê bikar anîn da ku pod bi rengek çêtirîn bi cîh bike.

Ji Belgekirina Kubernetes: Pêngava parzûnê komek girêkan diyar dike ku li wir Pod dikare were plansaz kirin. Mînakî, Parzûna PodFitsResources kontrol dike ku bibîne ka girêkek têra xwe çavkaniyên ku daxwazên çavkaniyek taybetî ji podek têr dike heye.

Em daxwazên serîlêdanê bi vî rengî bikar tînin ku em dikarin çend çavkaniyan texmîn bikin di rastî Serlêdan hewce dike ku ew bi rêkûpêk bixebite. Bi vî rengî plansaz dikare bi rastî girêkan bi cîh bike. Di destpêkê de, me xwest ku em daxwaznameyên xwe zêde bername bikin da ku çavkaniyên têr ji bo her Pod peyda bikin, lê me dît ku dema plansazkirinê pir zêde zêde bû, û hin Pod bi tevahî nehatin plansaz kirin, mîna ku ji wan re daxwazên çavkaniyê tune ne.

Di vê rewşê de, plansazker bi gelemperî "pişkan" dike û nekare wan ji nû ve birêkûpêk bike ji ber ku balafira kontrolê nizane ka dê serîlêdanê çiqas çavkaniyan hewce bike, ku ev yek hêmanek bingehîn a algorîtmaya plansazkirinê ye.

sînorên Pod ji bo podek sînorek zelaltir e. Ew mîqdara herî zêde ya çavkaniyên ku kom dê ji konteynerê re veqetîne temsîl dike.

Dîsa, ji belgeyên fermî: Ger konteynerek xwedan sînorê bîranînê 4 GiB be, wê hingê kubelet (û dema xebitandina konteynerê) wê bicîh bike. Dema xebitandinê rê nade ku konteynir ji sînorê çavkaniyê ya diyarkirî zêdetir bikar bîne. Mînakî, dema ku pêvajoyek di konteynerê de hewl dide ku ji mêjera destûrî ya bîranînê zêdetir bikar bîne, kernelê pergalê bi xeletiyek "ji bîranînê" (OOM) pêvajoyê bi dawî dike.

Konteynir her gav dikare ji daxwaza çavkaniyê bêtir çavkaniyan bikar bîne, lê ew çu carî nikare ji sînor zêdetir bikar bîne. Ev nirx zehmet e ku rast were danîn, lê ew pir girîng e.

Bi îdeal, em dixwazin ku hewcedariyên çavkaniyê yên pod-ê di dema heyama pêvajoyek de bêyî mudaxelekirina pêvajoyên din ên pergalê biguhezin - armanca danîna sînoran ev e.

Mixabin, ez nikarim rêwerzên taybetî li ser kîjan nirxan destnîşan bikim bidim, lê em bixwe rêzikên jêrîn digirin:

  1. Bi karanîna amûrek ceribandina barkirinê, em astek bingehîn a seyrûseferê simule dikin û karanîna çavkaniyên pod (bîr û pêvajoyê) temaşe dikin.
  2. Daxwazên pod li ser nirxek kêfî kêm (bi sînorek çavkaniyê bi qasî 5 carî nirxa daxwazê ​​ye) bicîh bikin û temaşe bikin. Dema ku daxwaz di astek pir nizm de bin, pêvajo nikare dest pê bike, bi gelemperî dibe sedema xeletiyên dema xebitandinê yên Go-ya şîrîn.

Ez destnîşan dikim ku tixûbên çavkaniyê yên bilind plansazkirinê dijwartir dike ji ber ku pod pêdivî bi girêkek armancek bi têra xwe çavkaniyên berdest heye.

Rewşek bifikirin ku we serverek malperek sivik heye ku bi sînorek çavkaniyek pir zêde, mîna 4 GB bîranîn heye. Ev pêvajo îhtîmal e ku pêdivî ye ku bi rengek horizontî were pîvandin, û her podek nû pêdivî ye ku li ser nodek bi kêmî ve 4 GB bîranîna berdest were plansaz kirin. Ger girêkek wusa tunebe, divê kombûn girêkek nû destnîşan bike da ku vê podê bidomîne, ku dibe ku hin dem bigire. Girîng e ku meriv cûdahiyek hindiktirîn di navbera daxwazên çavkaniyê û sînoran de bi dest bixe da ku pîvana bilez û bêkêmasî peyda bike.

Gav Du: Testên Zindî û Amadekariyê saz bikin

Ev mijarek din a nazik e ku pir caran di civata Kubernetes de tê nîqaş kirin. Girîng e ku meriv ji ceribandinên Liveness û Amadekariyê baş têgihiştinek hebe ji ber ku ew mekanîzmayek ji bo xebata nermalavê ya bi îstîqrar peyda dikin û dema domandinê kêm dikin. Lêbelê, ew dikarin bi ciddî bandorek li ser performansa serîlêdana we bikin ger rast neyên mîheng kirin. Li jêr kurteyek ku her du nimûne ne.

Zindî nîşan dide ka konteynir dimeşe. Ger ew têk neçe, kubelet konteynerê dikuje û polîtîkaya ji nû ve destpêkirinê ji bo wê tê çalak kirin. Ger konteynir bi Probeya Livenessê ve nebe, wê hingê rewşa xwerû dê serketî be - wekî ku tê gotin Belgekirina Kubernetes.

Lêpirsînên liveness divê erzan bin, ango gelek çavkaniyan nexwin, ji ber ku ew pir caran dixebitin û divê Kubernetes agahdar bikin ku serîlêdan dimeşîne.

Ger we vebijarka ku her saniyeyekê bimeşîne destnîşan bike, ev ê di her çirkeyê de 1 daxwaz lê zêde bike, ji ber vê yekê hay ji xwe hebin ku ji bo pêvajoya vê seyrûseferê dê çavkaniyên din hewce bike.

Li pargîdaniya me, ceribandinên Liveness hêmanên bingehîn ên serîlêdanê diceribînin, tewra ku dane (mînakî, ji databasek dûr an cache) bi tevahî peyda nebe.

Me di serîlêdanan de xala dawî ya "tenduristî" saz kiriye ku bi tenê kodek bersivê ya 200 vedigerîne. Ev nîşanek e ku pêvajo dimeşe û karibe daxwazan bi rê ve bibe (lê hêj ne trafîkê).

Nimûneyî Amadekirin destnîşan dike ka konteynir amade ye ku daxwazan bike. Ger lêpirsîna amadebûnê têk biçe, kontrolkerê xala dawîn navnîşana IP-ya podê ji xalên dawî yên hemî karûbarên ku bi podê re hevaheng in derdixe. Ev di belgeyên Kubernetes de jî tê gotin.

Lêpirsînên amadehiyê bêtir çavkaniyan dixwe, ji ber ku divê ew bi vî rengî li piştê bixin ku nîşan bidin ku serîlêdan amade ye ku daxwazan qebûl bike.

Di civatê de gelek nîqaş hene ka meriv rasterast bigihîje databasê. Bi ber çavan re (kontrol pir caran in, lê ew dikarin bêne kontrol kirin), me biryar da ku ji bo hin serlêdanan, amadebûna ji bo xizmetkirina seyrûseferê tenê piştî kontrolkirina ku tomar ji databasê têne vegerandin tê hesibandin. Ceribandinên amadehiyê yên baş-sêwirandî astên bilindtir ên hebûna peyda kirin û di dema bicîhkirinê de dema domandinê ji holê rakirin.

Heke hûn biryar didin ku ji databasê bipirsin da ku amadebûna serîlêdana xwe ceribandin, pê ewle bin ku ew bi qasî ku gengaz erzan e. Ka em vê pirsê bikin:

SELECT small_item FROM table LIMIT 1

Li vir mînakek e ku em çawa van her du nirxan li Kubernetes mîheng dikin:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

Hûn dikarin hin vebijarkên mîhengê yên din zêde bikin:

  • initialDelaySeconds - Di navbera avêtina konteynerê û destpêka destpêkirina sondajê de dê çend saniye derbas bibe.
  • periodSeconds - Navbera bendê di navbera ceribandinên nimûneyê de.
  • timeoutSeconds - Hejmara saniyeyên piştî ku pod wekî acîl tê hesibandin. Demjimêra normal.
  • failureThreshold berî ku sînyalek ji nû ve destpêkirinê ji pod re were şandin, hejmara têkçûna testê ye.
  • successThreshold hejmara ceribandinên serketî ye berî ku pod veguhezîne rewşa amade (piştî têkçûnek dema ku pod dest pê dike an baş dibe).

Gav Sêyem: Sazkirina Polîtîkayên Tora Xwerû ya Pod

Kubernetes xwedan topografiyek torê ya "drav" e, ji hêla xwerû ve hemî pod rasterast bi hevûdu re têkilî daynin. Di hin rewşan de ev nayê xwestin.

Pirsgirêkek ewlehiyê ya potansiyel ev e ku êrîşkarek dikare serîlêdanek xedar bikar bîne da ku seyrûseferê bişîne hemî podên li ser torê. Mîna ku di gelek warên ewlehiyê de, prensîba kêmtirîn îmtiyazê li vir jî derbas dibe. Bi îdeal, polîtîkayên torê divê bi eşkere diyar bikin ka kîjan girêdan di navbera pods de destûr in û kîjan ne.

Mînakî, ya jêrîn siyasetek hêsan e ku hemî seyrûsefera hatina ji bo cîhek navek taybetî red dike:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

Dîtina vê veavakirinê:

Dema ku serîlêdana yekem li Kubernetes bicîh dikin pênc winda dibin
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Agahiya zêdetir vir.

Gav Çar: Tevgera Xweserî bi Çêlik û Konteynirên Destpêkê

Yek ji mebestên me yên sereke ew bû ku em li Kubernetes-ê bêyî demdirêj ji bo pêşdebiran bicîh bikin. Ev dijwar e ji ber ku gelek vebijark ji bo girtina sepanan û berdana çavkaniyên wan ên hatine bikar anîn hene.

Zehmetiyên taybetî derketin holê nginx. Me ferq kir ku dema ku van Pod bi rêzê ve têne bicîh kirin, girêdanên çalak berî ku bi serfirazî biqedin qut bûn.

Piştî lêkolînek berfireh li ser Înternetê, derket holê ku Kubernetes li benda girêdanên Nginx namîne ku xwe biqewirîne berî ku pod biqede. Bi arîkariya çenga pêş-rawestanê, me fonksiyona jêrîn bicîh anî û bi tevahî ji demajoyê xilas bû:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

Paradîgmayek din a pir bikêr ev e ku meriv konteynerên destpêkê bikar bîne da ku dest bi destpêkirina serîlêdanên taybetî bike. Ev bi taybetî bikêr e heke we pêvajoyek koçkirina databasa-çavkaniyek zexm heye ku divê berî destpêkirina serîlêdanê were meşandin. Her weha hûn dikarin ji bo vê pêvajoyê sînorek çavkaniyek bilindtir diyar bikin bêyî ku ji bo serîlêdana sereke sînorek weha destnîşan bikin.

Pîlana din a hevpar gihandina sirên di konteynera destpêkê de ye, ku van pêbaweriyan ji modula sereke re peyda dike, ku rê li ber gihandina bêdestûr ji sirên ji modula serîlêdana sereke bixwe digire.

Wekî her carê, jêderek ji belgeyê: konteyneran bi ewlehî koda bikarhêner an karûbarên ku wekî din dê ewlehiya wêneya konteynera serîlêdanê tawîz bike dimeşîne. Bi veqetandina amûrên nepêwîst re, hûn rûyê êrîşê ya wêneya konteynera serîlêdanê sînordar dikin.

Gav pênc: Veavakirina Kernel

Di dawiyê de, em li ser teknîkek pêşkeftî biaxivin.

Kubernetes platformek zehf maqûl e ku dihêle hûn bargiraniyên xebatê bimeşînin lê belê hûn guncan dibînin. Gelek serîlêdanên me yên pir bikêr hene ku çavkaniyek zehf zexm in. Piştî ceribandina barkirinê ya berfireh, me dît ku yek ji serîlêdanan dema ku mîhengên xwerû yên Kubernetes di meriyetê de bûn, zehmetiyek dijwar dikişand li ser barkirina seyrûsefera bendewariyê.

Lêbelê, Kubernetes destûrê dide te ku hûn konteynirek îmtiyaz bimeşînin ku tenê ji bo podek taybetî pîvanên kernel diguhezîne. Ya ku me bikar anî ji bo guhertina herî zêde hejmara girêdanên vekirî ev e:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

Ev teknîkek pêşkeftî ye ku pir caran ne hewce ye. Lê heke serîlêdana we ji bo ku bi barek giran re mijûl bibe, hûn dikarin hin ji van mîhengan biceribînin. Zêdetir agahdarî li ser vê pêvajoyê û danîna nirxên cûda - wekî her gav di belgeyên fermî de.

Di encamê de

Digel ku Kubernetes wekî çareseriyek derveyî xuya dike, çend gavên bingehîn hene ku divê werin avêtin da ku serîlêdan bi rêkûpêk bimeşin.

Li seranserê koçberiya Kubernetes, girîng e ku meriv "çerxa ceribandina barkirinê" bişopîne: serîlêdanê bimeşînin, wê di bin barkirinê de biceribînin, metrîk û tevgera pîvandinê bişopînin, veavakirinê li ser bingeha vê daneyê rast bikin, dûv re vê dewrê dîsa dubare bikin.

Di derbarê seyrûsefera bendewarî de realîst bin û hewl bidin ku ji wê wêdetir biçin da ku bibînin ka kîjan pêkhate pêşî dişkînin. Bi vê nêzîkatiya dubare, tenê çend pêşniyarên navnîşkirî dibe ku ji bo bidestxistina serfiraziyê bes bin. An jî dibe ku bêtir xwerûkirina kûrahî hewce bike.

Her tim van pirsan ji xwe bipirsin:

  1. Serlêdan çend çavkaniyan dixwe û ev mîqdar dê çawa biguhere?
  2. Pêdiviyên pîvana rastîn çi ne? Serlêdan dê bi navînî çiqas seyrûseferê bigire? Çi li ser trafîkê lûtkeyê?
  3. Dê çend caran karûbar hewce bike ku mezin bibe? Ji bo wergirtina seyrûseferê çiqas zû pêdivî ye ku podên nû werin hilanîn û xebitandin?
  4. Pod bi çi rengî bi dilşewatî têne girtin? Ma bi tevahî pêdivî ye? Ma gengaz e ku meriv bêyî wextê dakêşanê bi dest bixe?
  5. Meriv çawa xetereyên ewlehiyê kêm dike û zirarê ji her podên lihevhatî sînordar dike? Ma tu karûbar destûr an gihîştinên ku ew ne hewce ne hene?

Kubernetes platformek bêhempa peyda dike ku destûrê dide te ku hûn pratîkên çêtirîn bikar bînin da ku bi hezaran karûbar di komekê de bicîh bikin. Lêbelê, hemî serlêdan cûda ne. Carinan pêkanîna xebatek piçûktir hewce dike.

Xwezî, Kubernetes mîhengên pêwîst peyda dike da ku bigihîje hemî armancên teknîkî. Bi karanîna berhevokek daxwaz û sînoran, vekolînên Liveness û Amadekariyê, konteynerên destpêkê, polîtîkayên torê, û birêkûpêkkirina kernelê xwerû, hûn dikarin performansa bilind digel tolerasyona xeletiyê û mezinbûna bilez bi dest bixin.

Wekî din çi bixwînin:

  1. Pratîkên çêtirîn û pratîkên çêtirîn ên ji bo xebitandina konteyniran û Kubernetes di hawîrdorên hilberînê de.
  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