🥇Jinsi ya kufikia nyenzo za Kubernetes Pod

Tuzo la Tohad

Unapoanza na Kubernetes, ni kawaida kusahau kuhusu kusanidi rasilimali za kontena. Katika hatua hii, inatosha kuhakikisha kuwa picha ya Docker inafanya kazi na inaweza kupelekwa kwenye nguzo ya Kubernetes.

Lakini baadaye programu inahitaji kutumwa katika nguzo ya uzalishaji pamoja na programu zingine. Ili kufanya hivyo, unahitaji kutenga rasilimali kwa chombo na uhakikishe kuwa kuna kutosha kwao ili kupata programu na kufanya kazi, na kwamba programu nyingine zinazoendesha hazitapata matatizo.

Timu Kubernetes aaS kutoka Mail.ru ilitafsiri makala kuhusu rasilimali za kontena (CPU & MEM), maombi na vikwazo vya rasilimali. Utajifunza manufaa ya mipangilio hii na kitakachofanyika usipoiweka.

Rasilimali za kompyuta

Tuna aina mbili za rasilimali zilizo na vitengo vifuatavyo:

Kitengo cha usindikaji cha kati (CPU) - cores;
Kumbukumbu (MEM) - ka.

Rasilimali zimeainishwa kwa kila chombo. Katika faili ifuatayo ya Pod YAML, utaona sehemu ya rasilimali ambayo ina rasilimali zilizoombwa na kikomo:

Rasilimali za Podi zilizoombwa = jumla ya rasilimali zilizoombwa za kontena zote;
Upeo wa Rasilimali ya Pod = Jumla ya Vikomo vyote vya Rasilimali za 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

Mfano wa Rasilimali Zilizoombwa na Finyu

Shamba resources.requested kutoka kwa vipimo vya Pod ni mojawapo ya vipengele vinavyotumiwa kupata nodi inayotakiwa. Tayari unaweza kupanga uwekaji wa Pod kwa ajili yake. Unapataje nodi inayofaa?

Kubernetes ina vipengele kadhaa, ikiwa ni pamoja na nodi kuu au nodi kuu (Ndege ya Kudhibiti ya Kubernetes). Nodi kuu ina michakato kadhaa: kube-apiserver, kube-controller-manager na kube-scheduler.

Mchakato wa kube-scheduler una jukumu la kukagua maganda mapya yaliyoundwa na kutafuta nodi zinazowezekana za wafanyikazi ambazo zinalingana na maombi yote ya pod, pamoja na idadi ya rasilimali zilizoombwa. Orodha ya nodi zilizopatikana na kube-scheduler zimeorodheshwa. Podi imepangwa kwenye nodi na alama za juu zaidi.

Jengo la zambarau litawekwa wapi?

Katika picha unaweza kuona kwamba kube-scheduler inapaswa kuratibu Podi mpya ya zambarau. Kundi la Kubernetes lina nodi mbili: A na B. Kama unavyoona, kube-scheduler haiwezi kuratibu Pod kwenye nodi A - rasilimali zinazopatikana (zisizoombwa) hazilingani na maombi ya Podi ya zambarau. Kwa hivyo, 1 GB ya kumbukumbu iliyoombwa na Pod ya zambarau haitafaa kwenye node A, kwani kumbukumbu inayopatikana ni 0,5 GB. Lakini nodi B ina rasilimali za kutosha. Kwa hivyo, kube-scheduler anaamua kuwa mwisho wa Pod ya zambarau ni nodi B.

Sasa tunajua jinsi rasilimali zilizoombwa zinavyoathiri uchaguzi wa nodi ya kuendesha Pod. Lakini ni nini athari ya rasilimali ndogo?

Kikomo cha rasilimali ni mpaka ambao CPU/MEM haiwezi kuvuka. Hata hivyo, rasilimali ya CPU inaweza kunyumbulika, kwa hivyo vyombo vinavyofikia kikomo chao cha CPU havitasababisha Pod kuondoka. Badala yake, CPU throttling itaanza. Ikiwa kikomo cha matumizi cha MEM kimefikiwa, kontena litasimamishwa kwa sababu ya OOM-Killer na kuwashwa upya ikiwa inaruhusiwa na mpangilio wa RestartPolicy.

Rasilimali zilizoombwa na upeo wa juu kwa undani

Mawasiliano ya rasilimali kati ya Docker na Kubernetes

Njia bora ya kueleza jinsi maombi ya rasilimali na mipaka ya rasilimali hufanya kazi ni kutambulisha uhusiano kati ya Kubernetes na Docker. Katika picha hapo juu unaweza kuona jinsi sehemu za Kubernetes na bendera za kuanza za Docker zinahusiana.

Kumbukumbu: ombi na kizuizi

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

Kama ilivyoelezwa hapo juu, kumbukumbu hupimwa kwa baiti. Kulingana na Nyaraka za Kubernetes, tunaweza kubainisha kumbukumbu kama nambari. Kawaida ni nambari kamili, kwa mfano 2678 - ambayo ni, 2678 byte. Unaweza pia kutumia viambishi tamati G и Gi, jambo kuu ni kukumbuka kuwa sio sawa. Ya kwanza ni decimal na ya pili ni ya binary. Kama mfano uliotajwa kwenye hati za k8s: 128974848, 129e6, 129M, 123Mi - wao ni kivitendo sawa.

Chaguo la Kubernetes limits.memory inalingana na bendera --memory kutoka Docker. Katika kesi ya request.memory Hakuna mshale wa Docker kwa sababu Docker haitumii uwanja huu. Unaweza kuuliza, hii ni muhimu hata? Ndiyo haja. Kama nilivyosema hapo awali, uwanja ni muhimu kwa Kubernetes. Kulingana na taarifa kutoka kwayo, kube-scheduler huamua ni nodi gani ya kuratibu Pod.

Ni nini hufanyika ikiwa utaweka kumbukumbu haitoshi kwa ombi?

Ikiwa chombo kimefikia mipaka ya kumbukumbu iliyoombwa, basi Pod imewekwa kwenye kikundi cha Pods ambazo huacha wakati hakuna kumbukumbu ya kutosha katika node.

Nini kitatokea ikiwa utaweka kikomo cha kumbukumbu chini sana?

Ikiwa kontena itazidi kikomo cha kumbukumbu, itasitishwa kwa sababu ya OOM-Killed. Na itaanza upya ikiwezekana kulingana na RestartPolicy ambapo thamani chaguomsingi iko Always.

Nini kitatokea ikiwa hutabainisha kumbukumbu iliyoombwa?

Kubernetes itachukua thamani ya kikomo na kuiweka kama thamani chaguomsingi.

Nini kinaweza kutokea ikiwa hutataja kikomo cha kumbukumbu?

Chombo hakina vizuizi; kinaweza kutumia kumbukumbu nyingi kadri inavyotaka. Ikiwa ataanza kutumia kumbukumbu zote zilizopo za nodi, basi OOM itamuua. Chombo kitaanzishwa upya ikiwezekana kulingana na RestartPolicy.

Nini kitatokea ikiwa hutataja mipaka ya kumbukumbu?

Hii ndio hali mbaya zaidi: mpangaji hajui ni rasilimali ngapi chombo kinahitaji, na hii inaweza kusababisha shida kubwa kwenye nodi. Katika kesi hii, itakuwa nzuri kuwa na mipaka chaguo-msingi kwenye nafasi ya majina (iliyowekwa na LimitRange). Hakuna mipaka chaguo-msingi - Pod haina kikomo, inaweza kutumia kumbukumbu nyingi inavyotaka.

Ikiwa kumbukumbu iliyoombwa ni zaidi ya nodi inaweza kutoa, Pod haitaratibiwa. Ni muhimu kukumbuka hilo Requests.memory - sio thamani ya chini. Haya ni maelezo ya kiasi cha kumbukumbu kinachotosha kuweka chombo kikiendelea.

Kwa kawaida hupendekezwa kuweka thamani sawa kwa request.memory и limit.memory. Hii inahakikisha kwamba Kubernetes haitaratibu Pod kwenye nodi ambayo ina kumbukumbu ya kutosha kuendesha Pod lakini haitoshi kuiendesha. Kumbuka: Upangaji wa Kubernetes Pod huzingatia tu requests.memoryNa limits.memory haizingatii.

CPU: ombi na kikomo

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

Kwa CPU kila kitu ni ngumu zaidi. Kurudi kwenye picha ya uhusiano kati ya Kubernetes na Docker, unaweza kuona hiyo request.cpu inafanana na --cpu-shares, ambapo limit.cpu inalingana na bendera cpus katika Docker.

CPU ambayo Kubernetes inaomba inazidishwa na 1024, uwiano wa mizunguko ya CPU. Ikiwa unataka kuomba msingi 1 kamili, lazima uongeze cpu: 1kama inavyoonyeshwa hapo juu.

Kuomba kernel kamili (idadi = 1024) haimaanishi kuwa chombo chako kitaipokea. Ikiwa mashine yako ya seva pangishi ina msingi mmoja tu na unatumia zaidi ya kontena moja, basi vyombo vyote lazima vishiriki CPU inayopatikana kati yake. Je, hii hutokeaje? Hebu tuangalie picha.

Ombi la CPU - Mfumo Mmoja wa Msingi

Wacha tufikirie kuwa una mfumo wa mwenyeji wa msingi mmoja unaoendesha vyombo. Mama (Kubernetes) alioka mkate (CPU) na anataka kuigawanya kati ya watoto (vyombo). Watoto watatu wanataka pai nzima (idadi = 1024), mtoto mwingine anataka nusu ya pai (512). Mama anataka kuwa wa haki na hufanya hesabu rahisi.

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

Kulingana na hesabu, watoto watatu watapata 28% ya msingi, na sio msingi wote. Mtoto wa nne atapata 14% ya punje kamili, sio nusu. Lakini mambo yatakuwa tofauti ikiwa una mfumo wa msingi mwingi.

Ombi la CPU - Mfumo wa Multi-Core (4).

Katika picha hapo juu unaweza kuona kwamba watoto watatu wanataka pie nzima, na mmoja anataka nusu. Kwa kuwa mama alioka mikate minne, kila mmoja wa watoto wake atapata nyingi anavyotaka. Katika mfumo wa msingi-nyingi, rasilimali za kichakataji husambazwa kwenye viini vyote vya kichakataji vinavyopatikana. Ikiwa kontena ina kikomo cha chini ya msingi mmoja kamili wa CPU, bado inaweza kuitumia kwa 100%.

Hesabu zilizo hapo juu zimerahisishwa ili kuelewa jinsi CPU inavyosambazwa kati ya vyombo. Kwa kweli, kando na vyombo vyenyewe, kuna michakato mingine ambayo pia hutumia rasilimali za CPU. Wakati michakato katika chombo kimoja haifanyi kazi, wengine wanaweza kutumia rasilimali yake. CPU: "200m" inafanana na CPU: 0,2, ambayo ina maana takriban 20% ya msingi mmoja.

Sasa tuzungumzie limit.cpu. CPU ambayo Kubernetes inaweka mipaka inazidishwa na 100. Matokeo yake ni muda ambao chombo kinaweza kutumia kila µs 100 (cpu-period).

limit.cpu inalingana na bendera ya Docker --cpus. Huu ni mchanganyiko mpya wa zamani --cpu-period и --cpu-quota. Kwa kuiweka, tunaonyesha ni rasilimali ngapi za CPU zinazopatikana ambazo kontena inaweza kutumia kwa kiwango cha juu kabla ya kuanza kusukuma:

cpus - mchanganyiko cpu-period и cpu-quota. cpus = 1.5 sawa na kuweka cpu-period = 100000 и cpu-quota = 150000;
Kipindi cha CPU - kipindi Kipanga ratiba cha CPU CFS, sekunde 100 chaguo-msingi;
mgawo wa CPU - idadi ya microseconds ndani cpu-period, ambayo imefungwa na chombo.

Ni nini hufanyika ikiwa utasakinisha CPU isiyotosha iliyoombwa?

Ikiwa kontena inahitaji zaidi ya ilivyosakinisha, itaiba CPU kutoka kwa michakato mingine.

Nini kitatokea ikiwa utaweka kikomo cha CPU chini sana?

Kwa kuwa rasilimali ya CPU inaweza kubadilishwa, kuteleza kutawashwa.

Nini kitatokea ikiwa hutataja ombi la CPU?

Kama ilivyo kwa kumbukumbu, thamani ya ombi ni sawa na kikomo.

Nini kitatokea ikiwa hutabainisha kikomo cha CPU?

Chombo kitatumia CPU nyingi kadri inavyohitaji. Ikiwa sera chaguo-msingi ya CPU (LimitRange) imefafanuliwa katika nafasi ya majina, basi kikomo hiki pia kinatumika kwa kontena.

Nini kitatokea ikiwa hutabainisha ombi au kikomo cha CPU?

Kama ilivyo kwa kumbukumbu, hii ndiyo hali mbaya zaidi. Kipanga ratiba hajui ni rasilimali ngapi za chombo chako kinahitaji, na hii inaweza kusababisha matatizo makubwa kwenye nodi. Ili kuepuka hili, unahitaji kuweka vikomo chaguo-msingi vya nafasi za majina (LimitRange).

Kumbuka: ikiwa unaomba CPU zaidi kuliko nodi zinaweza kutoa, Pod haitaratibiwa. Requests.cpu - sio thamani ya chini, lakini thamani ya kutosha kuanza Pod na kufanya kazi bila kushindwa. Ikiwa programu haifanyi mahesabu magumu, chaguo bora ni kusakinisha request.cpu <= 1 na uzindue nakala nyingi kadri inavyohitajika.

Kiasi kinachofaa cha rasilimali zilizoombwa au kikomo cha rasilimali

Tulijifunza juu ya kizuizi cha rasilimali za kompyuta. Sasa ni wakati wa kujibu swali: "Pod yangu inahitaji rasilimali ngapi ili kuendesha programu bila matatizo yoyote? Ni kiasi gani kinachofaa?

Kwa bahati mbaya, hakuna majibu wazi kwa maswali haya. Ikiwa hujui jinsi programu yako inavyofanya kazi au ni kiasi gani cha CPU au kumbukumbu inayohitaji, chaguo bora ni kuipa programu kumbukumbu na CPU nyingi na kisha kufanya majaribio ya utendakazi.

Mbali na vipimo vya utendakazi, fuatilia tabia ya programu katika ufuatiliaji kwa wiki. Ikiwa grafu zinaonyesha kuwa programu yako inatumia rasilimali chache kuliko ulizoomba, unaweza kupunguza kiasi cha CPU au kumbukumbu iliyoombwa.

Kama mfano tazama hii Dashibodi ya Grafana. Inaonyesha tofauti kati ya rasilimali iliyoombwa au kikomo cha rasilimali na matumizi ya sasa ya rasilimali.

Hitimisho

Kuomba na kuweka kikomo rasilimali husaidia kuweka kundi lako la Kubernetes likiwa na afya. Usanidi unaofaa wa kikomo hupunguza gharama na huweka programu zikiendeshwa kila wakati.

Kwa kifupi, kuna mambo machache ya kuzingatia:

Nyenzo zilizoombwa ni usanidi ambao huzingatiwa wakati wa kuanza (wakati Kubernetes inapanga kupangisha programu). Kinyume chake, kupunguza rasilimali ni muhimu wakati wa utekelezaji—wakati programu tayari inafanya kazi kwenye nodi.
Ikilinganishwa na kumbukumbu, CPU ni rasilimali iliyodhibitiwa. Ikiwa hakuna CPU ya kutosha, Pod yako haitazimika na utaratibu wa kubana utawashwa.
Rasilimali zilizoombwa na kikomo cha rasilimali sio maadili ya chini na ya juu! Kwa kufafanua rasilimali zilizoombwa, unahakikisha kwamba programu itaendeshwa bila matatizo.
Mazoezi mazuri ni kuweka ombi la kumbukumbu sawa na kikomo cha kumbukumbu.
Sawa kusakinisha ombi CPU <=1, ikiwa programu haifanyi mahesabu magumu.
Ukiomba rasilimali zaidi ya zinazopatikana kwenye nodi, Pod haitawahi kuratibiwa kwa nodi hiyo.
Kuamua kiasi sahihi cha rasilimali/vikomo vya rasilimali zilizoombwa, tumia upimaji wa mzigo na ufuatiliaji.

Natumaini makala hii itakusaidia kuelewa dhana ya msingi ya ukomo wa rasilimali. Na utaweza kutumia maarifa haya katika kazi yako.

Mafanikio!

Nini kingine cha kusoma:

Chanzo: mapenzi.com

Jinsi ya kupata rasilimali za Kubernetes Pod