🥇 Makosa matano wakati wa kupeleka programu yako ya kwanza kwenye Kubernetes

Imeshindwa na Aris-Dreamer

Watu wengi wanaamini kuwa inatosha kuhamisha programu hadi Kubernetes (kwa kutumia Helm au kwa mikono) na watafurahi. Lakini si rahisi hivyo.

Timu Mail.ru Cloud Solutions ilitafsiriwa makala na mhandisi wa DevOps Julian Gindi. Anashiriki mitego ambayo kampuni yake ilikumbana nayo wakati wa mchakato wa uhamiaji ili usikanyage kwenye safu sawa.

Hatua ya Kwanza: Kuweka Maombi ya Pod na Mipaka

Wacha tuanze kwa kuweka mazingira safi ambayo maganda yetu yataendesha. Kubernetes hufanya kazi nzuri ya kuratibu maganda na kushughulikia hali za kutofaulu. Lakini ikawa kwamba mpangaji wakati mwingine hawezi kuweka ganda ikiwa ni vigumu kukadiria ni rasilimali ngapi inahitaji kufanya kazi kwa mafanikio. Hapa ndipo maombi ya rasilimali na mipaka yanapokuja. Kuna mijadala mingi kuhusu mbinu bora ya kuweka maombi na mipaka. Wakati mwingine inahisi kama ni sanaa zaidi kuliko sayansi. Hapa kuna mbinu yetu.

Maombi ya ganda - Hii ndio thamani kuu inayotumiwa na kipanga ratiba kuweka ganda kikamilifu.

Ya Nyaraka za Kubernetes: Hatua ya kuchuja huamua seti ya nodi ambapo ganda linaweza kupangwa. Kwa mfano, kichujio cha PodFitsResources hukagua ikiwa nodi ina rasilimali za kutosha kukidhi maombi maalum ya rasilimali ya ganda.

Tunatumia maombi ya maombi ili yaweze kutumika kukadiria ni rasilimali ngapi Kwa kweli Programu inaihitaji ili kufanya kazi ipasavyo. Kwa njia hii kipanga ratiba kinaweza kuweka nodi kihalisia. Hapo awali tulitaka kuweka maombi kwa ukingo ili kuhakikisha kuwa kila ganda lina idadi kubwa ya rasilimali za kutosha, lakini tuligundua kuwa nyakati za kuratibu ziliongezeka sana na baadhi ya maganda hayakuwahi kuratibiwa kikamilifu, kana kwamba hakuna maombi ya rasilimali yaliyopokelewa kwa ajili yao.

Katika hali hii, kipanga ratiba mara nyingi kingesukuma maganda na kushindwa kuzipanga upya kwa sababu ndege ya udhibiti haikujua ni rasilimali ngapi ambazo programu ingehitaji, kipengele muhimu cha kanuni ya kuratibu.

Vikomo vya Pod - hii ni kikomo wazi zaidi kwa ganda. Inawakilisha kiwango cha juu zaidi cha rasilimali ambazo nguzo itatenga kwa kontena.

Tena, kutoka nyaraka rasmi: Ikiwa kontena ina kikomo cha kumbukumbu cha GiB 4, basi kubelet (na muda wa kukimbia wa kontena) itaitekeleza. Muda wa utekelezaji hauruhusu kontena kutumia zaidi ya kikomo cha rasilimali kilichobainishwa. Kwa mfano, wakati mchakato katika chombo unajaribu kutumia zaidi ya kiasi kinachoruhusiwa cha kumbukumbu, kernel ya mfumo husitisha mchakato huo kwa kosa la "nje ya kumbukumbu" (OOM).

Chombo kinaweza kutumia rasilimali nyingi zaidi kuliko ilivyobainishwa katika ombi la rasilimali, lakini haiwezi kamwe kutumia zaidi ya ilivyoainishwa kwenye kikomo. Thamani hii ni vigumu kuweka kwa usahihi, lakini ni muhimu sana.

Kwa hakika, tunataka mahitaji ya rasilimali ya ganda kubadilika katika mzunguko wa maisha wa mchakato bila kuingilia michakato mingine katika mfumo—hilo ndilo lengo la kuweka mipaka.

Kwa bahati mbaya, siwezi kutoa maagizo maalum juu ya maadili gani ya kuweka, lakini sisi wenyewe tunafuata sheria zifuatazo:

Kwa kutumia zana ya kupima mzigo, tunaiga kiwango cha msingi cha trafiki na kufuatilia matumizi ya rasilimali za pod (kumbukumbu na kichakataji).
Tunaweka maombi ya ganda kwa thamani ya chini kiholela (yenye kikomo cha rasilimali cha takriban mara 5 ya thamani ya maombi) na kuzingatia. Wakati maombi ni ya chini sana, mchakato hauwezi kuanza, mara nyingi husababisha makosa ya ajabu ya wakati wa kukimbia.

Kumbuka kuwa vikomo vya juu vya rasilimali hufanya kuratibu kuwa ngumu zaidi kwa sababu ganda linahitaji nodi lengwa na rasilimali za kutosha zinazopatikana.

Hebu fikiria hali ambapo una seva ya wavuti nyepesi na kikomo cha juu sana cha rasilimali, sema 4 GB ya kumbukumbu. Mchakato huu utalazimika kuongezeka kwa usawa, na kila moduli mpya italazimika kuratibiwa kwenye nodi yenye angalau GB 4 ya kumbukumbu inayopatikana. Ikiwa hakuna nodi kama hiyo, nguzo lazima ianzishe nodi mpya ili kuchakata ganda hilo, ambalo linaweza kuchukua muda. Ni muhimu kuweka tofauti kati ya maombi ya rasilimali na mipaka kwa kiwango cha chini ili kuhakikisha kuongeza kasi na laini.

Hatua ya pili: kusanidi majaribio ya Maisha na Utayari

Hii ni mada nyingine hila ambayo mara nyingi hujadiliwa katika jumuiya ya Kubernetes. Ni muhimu kuwa na ufahamu mzuri wa majaribio ya Uhai na Utayari kwani hutoa utaratibu wa programu kufanya kazi vizuri na kupunguza muda wa kupumzika. Walakini, zinaweza kusababisha utendakazi mbaya kwa programu yako ikiwa hazijasanidiwa ipasavyo. Chini ni muhtasari wa jinsi sampuli zote mbili zilivyo.

Uhai inaonyesha kama chombo kinaendelea. Ikishindikana, kubelet huua kontena na sera ya kuanzisha upya imewezeshwa kwake. Ikiwa chombo hakina uchunguzi wa Liveness, basi hali chaguo-msingi itafanikiwa - hii ndio inasema katika Nyaraka za Kubernetes.

Uchunguzi wa maisha unapaswa kuwa wa bei nafuu, kumaanisha kuwa haufai kutumia rasilimali nyingi, kwa sababu unaendeshwa mara kwa mara na unahitaji kufahamisha Kubernetes kwamba programu inaendeshwa.

Ukiweka chaguo la kuendesha kila sekunde, hii itaongeza ombi 1 kwa sekunde, kwa hivyo fahamu kuwa rasilimali za ziada zitahitajika kushughulikia trafiki hii.

Katika kampuni yetu, majaribio ya Liveness huangalia vipengele vya msingi vya programu, hata kama data (kwa mfano, kutoka kwa hifadhidata ya mbali au kache) haipatikani kikamilifu.

Tumeweka mipangilio ya programu kwa sehemu ya mwisho ya "afya" ambayo inarejesha tu msimbo wa majibu wa 200. Hii ni dalili kwamba mchakato unaendelea na unaweza kushughulikia maombi (lakini bado si trafiki).

Mfano Utayari inaonyesha kama chombo kiko tayari kutoa maombi. Ikiwa uchunguzi wa utayari haufaulu, kidhibiti cha sehemu ya mwisho huondoa anwani ya IP ya ganda kutoka sehemu za mwisho za huduma zote zinazolingana na ganda. Hii pia imesemwa katika nyaraka za Kubernetes.

Uchunguzi wa utayari hutumia rasilimali zaidi kwa sababu lazima zitumwe kwa upande wa nyuma kwa njia inayoonyesha kuwa programu iko tayari kukubali maombi.

Kuna mijadala mingi katika jamii kuhusu kupata hifadhidata moja kwa moja. Kwa kuzingatia hali ya juu (ukaguzi unafanywa mara kwa mara, lakini unaweza kurekebishwa), tuliamua kuwa kwa baadhi ya programu, utayari wa kutumikia trafiki huhesabiwa tu baada ya kuthibitisha kwamba rekodi zinarejeshwa kutoka kwa hifadhidata. Majaribio ya utayari yaliyoundwa vyema yalihakikisha viwango vya juu vya upatikanaji na kuondolewa kwa muda wa chini wakati wa kusambaza.

Ukiamua kuuliza hifadhidata ili kujaribu utayari wa programu yako, hakikisha ni ya bei nafuu iwezekanavyo. Wacha tuchukue ombi hili:

SELECT small_item FROM table LIMIT 1

Hapa kuna mfano wa jinsi tunavyosanidi maadili haya mawili katika Kubernetes:

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

Unaweza kuongeza chaguzi za ziada za usanidi:

initialDelaySeconds - ni sekunde ngapi zitapita kati ya uzinduzi wa chombo na kuanza kwa sampuli.
periodSeconds - muda wa kusubiri kati ya kukimbia kwa sampuli.
timeoutSeconds - idadi ya sekunde ambapo kitengo kinachukuliwa kuwa cha dharura. Muda wa kuisha mara kwa mara.
failureThreshold — idadi ya makosa ya jaribio kabla ya ishara ya kuanza upya kutumwa kwenye ganda.
successThreshold - idadi ya probes mafanikio kabla ya pod kwenda katika hali tayari (baada ya kushindwa, wakati pod kuanza au kurejesha).

Hatua ya tatu: kusanidi sera chaguo-msingi za mtandao kwa pod

Kubernetes ina topografia ya mtandao "gorofa"; kwa chaguo-msingi, maganda yote yanawasiliana moja kwa moja. Katika baadhi ya matukio hii haifai.

Tatizo linalowezekana la usalama ni kwamba mshambulizi anaweza kutumia programu moja iliyo hatarini kutuma trafiki kwa maganda yote kwenye mtandao. Kama ilivyo kwa maeneo mengi ya usalama, kanuni ya upendeleo mdogo inatumika hapa. Kimsingi, sera za mtandao zinafaa kubainisha kwa uwazi ni miunganisho ipi kati ya ganda inayoruhusiwa na ambayo hairuhusiwi.

Kwa mfano, hapa chini kuna sera rahisi inayokataa trafiki yote inayoingia kwa nafasi mahususi ya majina:

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

Taswira ya usanidi huu:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Maelezo zaidi hapa.

Hatua ya nne: tabia maalum kwa kutumia ndoano na vyombo vya init

Mojawapo ya malengo yetu kuu ilikuwa kuhakikisha usambazaji kwa Kubernetes bila muda wa chini kwa wasanidi programu. Hii ni ngumu kwa sababu kuna chaguzi nyingi za kuzima programu na kuweka huru rasilimali walizotumia.

Shida maalum ziliibuka na Nginx. Tuligundua kuwa maganda haya yalipotumwa kwa mfuatano, miunganisho amilifu iliangushwa kabla ya kukamilika kwa mafanikio.

Baada ya utafiti wa kina mtandaoni, ilibainika kuwa Kubernetes haingojei miunganisho ya Nginx ijichoke yenyewe kabla ya kusitisha ganda. Kutumia ndoano ya kusimamisha mapema, tulitekeleza utendakazi ufuatao na tukaondoa kabisa wakati wa kupumzika:

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

Lakini 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

Dhana nyingine muhimu sana ni matumizi ya vyombo vya init kushughulikia uanzishaji wa programu maalum. Hii ni muhimu hasa ikiwa una mchakato wa uhamishaji wa hifadhidata unaotumia rasilimali nyingi ambao unahitaji kuendeshwa kabla ya programu kuanza. Unaweza pia kubainisha kikomo cha juu zaidi cha rasilimali kwa mchakato huu bila kuweka kikomo kama hicho kwa programu kuu.

Mpango mwingine wa kawaida ni kupata siri katika chombo cha init ambacho hutoa sifa hizo kwa moduli kuu, ambayo inazuia upatikanaji usioidhinishwa wa siri kutoka kwa moduli kuu ya maombi yenyewe.

Kama kawaida, nukuu kutoka kwa hati: Anzisha vyombo huendesha msimbo maalum au huduma kwa usalama ambazo zingepunguza usalama wa picha ya chombo cha programu. Kwa kutenganisha zana zisizo za lazima, unaweka kikomo eneo la shambulio la picha ya chombo cha programu.

Hatua ya Tano: Kusanidi Kernel

Hatimaye, hebu tuzungumze kuhusu mbinu ya juu zaidi.

Kubernetes ni jukwaa linalonyumbulika sana ambalo hukuruhusu kuendesha mizigo ya kazi jinsi unavyoona inafaa. Tuna idadi ya maombi ya utendaji wa juu ambayo yanahitaji rasilimali nyingi. Baada ya kufanya jaribio la kina la upakiaji, tuligundua kuwa programu moja ilikuwa ikijitahidi kushughulikia mzigo uliotarajiwa wa trafiki wakati mipangilio chaguomsingi ya Kubernetes ilipokuwa inatumika.

Walakini, Kubernetes hukuruhusu kuendesha kontena la upendeleo ambalo hubadilisha vigezo vya kernel tu kwa ganda maalum. Hivi ndivyo tulivyotumia kubadilisha idadi ya juu zaidi ya miunganisho iliyo wazi:

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

Hii ni mbinu ya juu zaidi ambayo mara nyingi haihitajiki. Lakini ikiwa programu yako inatatizika kukabiliana na mzigo mzito, unaweza kujaribu kurekebisha baadhi ya mipangilio hii. Maelezo zaidi juu ya mchakato huu na kuweka maadili tofauti - kama kawaida katika nyaraka rasmi.

Kwa kumalizia

Ingawa Kubernetes inaweza kuonekana kama suluhisho lililotengenezwa tayari nje ya kisanduku, kuna hatua chache muhimu unazohitaji kuchukua ili kuweka programu zako zifanye kazi vizuri.

Katika uhamaji wako wa Kubernetes, ni muhimu kufuata "mzunguko wa kupima upakiaji": zindua programu, ipakie ijaribu, angalia vipimo na tabia ya kuongeza alama, rekebisha usanidi kulingana na data hiyo, kisha urudie mzunguko tena.

Kuwa wa kweli kuhusu trafiki yako inayotarajiwa na ujaribu kusukuma zaidi ya hiyo ili kuona ni vipengele vipi vinavyovunjika kwanza. Kwa mbinu hii ya kurudia, ni mapendekezo machache tu yaliyoorodheshwa yanaweza kutosha kufikia mafanikio. Au inaweza kuhitaji ubinafsishaji wa kina.

Daima jiulize maswali haya:

Je, programu hutumia rasilimali ngapi na kiasi hiki kitabadilikaje?
Mahitaji ya kweli ya kuongeza ni yapi? Programu itashughulikia trafiki ngapi kwa wastani? Vipi kuhusu kilele cha trafiki?
Je, ni mara ngapi huduma itahitaji kuongeza mlalo? Maganda mapya yanahitaji kuletwa mtandaoni kwa haraka kiasi gani ili kupokea trafiki?
Maganda yanafungwa kwa usahihi vipi? Je, hii ni muhimu hata kidogo? Je, inawezekana kufikia kupelekwa bila muda wa chini?
Unawezaje kupunguza hatari za usalama na kupunguza uharibifu kutoka kwa ganda lolote lililoathiriwa? Je, huduma zozote zina ruhusa au ufikiaji ambazo hazihitaji?

Kubernetes hutoa jukwaa la ajabu ambalo hukuruhusu kutumia mbinu bora za kupeleka maelfu ya huduma katika kundi. Hata hivyo, kila maombi ni tofauti. Wakati mwingine utekelezaji unahitaji kazi kidogo zaidi.

Kwa bahati nzuri, Kubernetes hutoa usanidi unaohitajika kufikia malengo yote ya kiufundi. Kwa kutumia mseto wa maombi na vikomo vya rasilimali, Uchunguzi wa Uhai na Utayari, vyombo vya init, sera za mtandao, na upangaji wa kernel maalum, unaweza kufikia utendakazi wa juu pamoja na uvumilivu wa hitilafu na uboreshaji wa haraka.

Nini kingine cha kusoma:

Chanzo: mapenzi.com

Tano hukosa wakati wa kupeleka programu ya kwanza kwenye Kubernetes