🥇 Makosa 10 ya kawaida unapotumia Kubernetes

Kumbuka. tafsiri.: Waandishi wa makala hii ni wahandisi kutoka kampuni ndogo ya Kicheki, pipetail. Waliweza kuweka pamoja orodha ya ajabu ya [wakati mwingine banal, lakini bado] matatizo makubwa sana na maoni potofu kuhusiana na uendeshaji wa makundi ya Kubernetes.

Kwa miaka mingi ya kutumia Kubernetes, tumefanya kazi na idadi kubwa ya vikundi (zote zinazosimamiwa na zisizodhibitiwa - kwenye GCP, AWS na Azure). Baada ya muda, tulianza kuona kwamba makosa fulani yalirudiwa mara kwa mara. Hata hivyo, hakuna aibu katika hili: tumefanya wengi wao wenyewe!

Nakala hiyo ina makosa ya kawaida na pia inataja jinsi ya kusahihisha.

1. Rasilimali: maombi na mipaka

Kipengee hiki hakika kinastahili tahadhari ya karibu zaidi na nafasi ya kwanza kwenye orodha.

Ombi la CPU kawaida ama haijabainishwa kabisa au ina thamani ya chini sana (kuweka maganda mengi kwenye kila nodi iwezekanavyo). Kwa hivyo, nodi huwa zimejaa. Wakati wa mzigo mkubwa, nguvu ya usindikaji ya nodi hutumiwa kikamilifu na mzigo fulani wa kazi hupokea tu kile "iliyoomba" na. CPU throttling. Hii husababisha kuongezeka kwa muda wa kusubiri, muda, na matokeo mengine yasiyofurahisha. (Soma zaidi kuhusu hili katika tafsiri yetu nyingine ya hivi karibuni: “Vikomo vya CPU na msisimko mkali katika Kubernetes"- takriban. tafsiri.)

Juhudi nzuri (sana hakuna ilipendekeza):

resources: {}

Ombi la CPU ya chini sana (sana hakuna ilipendekeza):

   resources:
      Requests:
        cpu: "1m"

Kwa upande mwingine, kuwepo kwa kikomo cha CPU kunaweza kusababisha kuruka bila sababu ya mizunguko ya saa na maganda, hata kama kichakataji cha nodi hakijapakiwa kikamilifu. Tena, hii inaweza kusababisha ucheleweshaji ulioongezeka. Mabishano yanaendelea karibu na kigezo Kiwango cha juu cha CPU CFS katika kernel ya Linux na CPU throttling kulingana na mipaka iliyowekwa, pamoja na kuzima mgao wa CFS... Ole, mipaka ya CPU inaweza kusababisha matatizo zaidi kuliko wanaweza kutatua. Maelezo zaidi kuhusu hili yanaweza kupatikana kwenye kiungo hapa chini.

Uchaguzi kupita kiasi (kushinda) matatizo ya kumbukumbu yanaweza kusababisha matatizo makubwa zaidi. Kufikia kikomo cha CPU kunajumuisha kuruka mizunguko ya saa, huku kufikia kikomo cha kumbukumbu kunahusisha kuua ganda. Je, umewahi kuona OOMkill? Ndiyo, ndivyo tunavyozungumzia.

Je, ungependa kupunguza uwezekano wa haya kutokea? Usigawanye kumbukumbu kupita kiasi na utumie QoS Iliyohakikishwa (Ubora wa Huduma) kwa kuweka ombi la kumbukumbu hadi kikomo (kama katika mfano ulio hapa chini). Soma zaidi kuhusu hili katika Henning Jacobs maonyesho (Mhandisi Kiongozi katika Zalando).

Kupasuka (nafasi kubwa ya kupata OOMkilled):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Imethibitishwa:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Ni nini kitakachoweza kusaidia wakati wa kuweka rasilimali?

Pamoja na vipimo-seva unaweza kuona matumizi ya sasa ya rasilimali ya CPU na utumiaji wa kumbukumbu na maganda (na vyombo vilivyomo). Uwezekano mkubwa zaidi, tayari unatumia. Endesha tu amri zifuatazo:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Walakini, zinaonyesha matumizi ya sasa tu. Inaweza kukupa wazo mbaya la mpangilio wa ukubwa, lakini mwishowe utahitaji historia ya mabadiliko katika metriki kwa wakati (kujibu maswali kama vile: "Mzigo wa juu zaidi wa CPU ulikuwa nini?", "Mzigo ulikuwa nini jana asubuhi?", nk.). Kwa hili unaweza kutumia Prometheus, DataDog na zana zingine. Wanapata tu vipimo kutoka kwa seva ya vipimo na kuzihifadhi, na mtumiaji anaweza kuzihoji na kuzipanga ipasavyo.

VerticalPodAutoscaler inaruhusu automatiska mchakato huu. Hufuatilia CPU na historia ya matumizi ya kumbukumbu na kuweka maombi mapya na vikomo kulingana na maelezo haya.

Kutumia nguvu ya kompyuta kwa ufanisi sio kazi rahisi. Ni kama kucheza Tetris wakati wote. Iwapo unalipa nguvu nyingi sana za kukokotoa na matumizi ya wastani ya chini (sema ~ 10%), tunapendekeza uangalie bidhaa kulingana na AWS Fargate au Virtual Kubelet. Zimeundwa kwa mtindo wa bili usio na seva/kulipa kwa matumizi, ambao unaweza kuwa wa bei nafuu katika hali kama hizo.

2. Uhai na utayari huchunguza

Kwa chaguomsingi, ukaguzi wa uhai na utayari haujawashwa katika Kubernetes. Na wakati mwingine wanasahau kuwasha ...

Lakini ni jinsi gani nyingine unaweza kuanzisha upya huduma katika tukio la kosa mbaya? Na msawazishaji wa mzigo anajuaje kuwa ganda liko tayari kukubali trafiki? Au kwamba inaweza kushughulikia trafiki zaidi?

Vipimo hivi mara nyingi huchanganyikiwa na kila mmoja:

Uhai - angalia "kuishi", ambayo huanza tena pod ikiwa inashindwa;
Utayari - ukaguzi wa utayari, ikiwa itashindwa, hutenganisha ganda kutoka kwa huduma ya Kubernetes (hii inaweza kuangaliwa kwa kutumia kubectl get endpoints) na trafiki haifiki kwake hadi ukaguzi unaofuata ukamilike kwa mafanikio.

Cheki hizi zote mbili INAYOFANYIKA WAKATI WA MZUNGUKO MZIMA WA MAISHA WA POD. Ni muhimu sana.

Dhana potofu ya kawaida ni kwamba uchunguzi wa utayari huendeshwa tu wakati wa kuanza ili msawazishaji ajue kuwa ganda liko tayari (Ready) na inaweza kuanza kuchakata trafiki. Walakini, hii ni moja tu ya chaguzi za matumizi yao.

Mwingine ni uwezekano wa kujua kwamba trafiki kwenye pod ni nyingi na inapakia kupita kiasi (au ganda hufanya mahesabu ya rasilimali). Katika kesi hii, ukaguzi wa utayari husaidia kupunguza mzigo kwenye pod na "upoe".. Kukamilisha kwa ufanisi ukaguzi wa utayari katika siku zijazo inaruhusu kuongeza mzigo kwenye ganda tena. Katika kesi hii (ikiwa mtihani wa utayari haufaulu), kutofaulu kwa jaribio la uhai kunaweza kuwa na tija sana. Kwa nini uanzishe tena ganda ambalo ni la afya na linafanya kazi kwa bidii?

Kwa hiyo, katika baadhi ya matukio, hakuna hundi kabisa ni bora kuliko kuwawezesha na vigezo vilivyowekwa vibaya. Kama ilivyoelezwa hapo juu, ikiwa kuangalia utayari wa nakala za uhai, basi uko kwenye matatizo makubwa. Chaguo linalowezekana ni kusanidi mtihani wa utayari tuNa uhai hatari kuondoka kando.

Aina zote mbili za hundi hazipaswi kushindwa wakati utegemezi wa kawaida unashindwa, vinginevyo hii itasababisha kutofaulu (kama-avalanche) kwa maganda yote. Kwa maneno mengine, usijidhuru.

3. LoadBalancer kwa kila huduma ya HTTP

Uwezekano mkubwa zaidi, una huduma za HTTP kwenye kundi lako ambazo ungependa kusambaza kwa ulimwengu wa nje.

Ukifungua huduma kama type: LoadBalancer, mtawala wake (kulingana na mtoa huduma) atatoa na kujadili LoadBalancer ya nje (sio lazima iendeshe L7, lakini hata kwenye L4), na hii inaweza kuathiri gharama (anwani ya IPv4 tuli ya nje, nguvu ya kompyuta, bili ya kila sekunde. ) kutokana na haja ya kuunda idadi kubwa ya rasilimali hizo.

Katika kesi hii, ni mantiki zaidi kutumia mizani moja ya nje ya mzigo, kufungua huduma kama type: NodePort. Au bora zaidi, panua kitu kama hicho kidhibiti-nginx-ingress (Au traefik), ambaye atakuwa pekee NodePort sehemu ya mwisho inayohusishwa na kisawazisha mzigo wa nje na itaelekeza trafiki kwenye nguzo kwa kutumia ingress-Kubernetes rasilimali.

Huduma zingine za ndani ya nguzo (ndogo) zinazoingiliana zinaweza "kuwasiliana" kwa kutumia huduma kama vile ClusterIP na utaratibu wa ugunduzi wa huduma uliojengewa ndani kupitia DNS. Usitumie tu DNS/IP yao ya umma, kwani hii inaweza kuathiri muda wa kusubiri na kuongeza gharama ya huduma za wingu.

4. Kuongeza kikundi kiotomatiki bila kuzingatia sifa zake

Unapoongeza nodi na kuziondoa kutoka kwa nguzo, hupaswi kutegemea baadhi ya vipimo vya msingi kama vile matumizi ya CPU kwenye nodi hizo. Upangaji wa podi lazima uzingatie mengi vikwazo, kama vile ushirika wa ganda/nodi, uchafu na ustahimilivu, maombi ya rasilimali, QoS, n.k. Kutumia autoscaler ya nje ambayo haizingatii nuances hizi inaweza kusababisha matatizo.

Fikiria kwamba ganda fulani linapaswa kuratibiwa, lakini nguvu zote za CPU zinazopatikana zinaombwa/kutenganishwa na ganda. anakwama katika hali Pending. Kichunguzi otomatiki cha nje huona wastani wa upakiaji wa sasa wa CPU (sio ulioombwa) na hakianzishi upanuzi. (kupunguza) - haina kuongeza node nyingine. Kwa hivyo, ganda hili halitaratibiwa.

Katika kesi hii, reverse kuongeza (kuongeza) - kuondoa nodi kutoka kwa nguzo ni ngumu zaidi kutekeleza. Fikiria kuwa una ganda la kifahari (na hifadhi inayoendelea imeunganishwa). Kiasi cha kudumu kawaida ni ya eneo maalum la upatikanaji na hazijaigwa katika kanda. Kwa hivyo, ikiwa kidhibiti otomatiki cha nje kitafuta nodi iliyo na ganda hili, mpangaji ratiba hataweza kupanga ganda hili kwenye nodi nyingine, kwa kuwa hii inaweza kufanyika tu katika eneo la upatikanaji ambapo hifadhi inayoendelea iko. Pod itakwama katika hali Pending.

Maarufu sana katika jamii ya Kubernetes nguzo-autoscaler. Inaendesha kwenye kundi, inasaidia API kutoka kwa watoa huduma wakuu wa wingu, inazingatia vikwazo vyote na inaweza kuongeza katika kesi zilizo hapo juu. Pia ina uwezo wa kuongeza kasi huku ikidumisha vikomo vyote vilivyowekwa, na hivyo kuokoa pesa (ambazo zingetumika kwa uwezo ambao haujatumika).

5. Kupuuza uwezo wa IAM/RBAC

Jihadhari na kutumia watumiaji wa IAM wenye siri zinazoendelea kwa mashine na maombi. Panga ufikiaji wa muda kwa kutumia majukumu na akaunti za huduma (akaunti za huduma).

Mara nyingi tunakumbana na ukweli kwamba funguo za ufikiaji (na siri) zimewekwa misimbo ngumu katika usanidi wa programu, na pia kupuuza kuzunguka kwa siri licha ya kuwa na ufikiaji wa Cloud IAM. Tumia majukumu ya IAM na akaunti za huduma badala ya watumiaji inapofaa.

Sahau kuhusu kube2iam na uende moja kwa moja kwa majukumu ya IAM kwa akaunti za huduma (kama ilivyofafanuliwa katika noti ya jina moja Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Dokezo moja. Sio ngumu sana, sivyo?

Pia, usitoe akaunti za huduma na mapendeleo ya wasifu wa mfano admin и cluster-adminikiwa hawahitaji. Hii ni ngumu zaidi kutekeleza, haswa katika RBAC K8s, lakini inafaa juhudi.

6. Usitegemee mshikamano wa kiotomatiki kwa maganda

Fikiria kuwa una nakala tatu za uwekaji kwenye nodi. Node huanguka, na pamoja na hayo nakala zote. Hali isiyofurahisha, sawa? Lakini kwa nini nakala zote zilikuwa kwenye nodi moja? Je! Kubernetes haifai kutoa upatikanaji wa juu (HA)?!

Kwa bahati mbaya, mpangilio wa Kubernetes, kwa hiari yake mwenyewe, hauzingatii sheria za kuwepo tofauti (kupinga mshikamano) kwa maganda. Lazima zielezwe kwa uwazi:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Ni hayo tu. Sasa maganda yatapangwa kwenye nodi tofauti (hali hii inaangaliwa tu wakati wa kuratibu, lakini sio wakati wa operesheni yao - kwa hivyo. requiredDuringSchedulingIgnoredDuringExecution).

Hapa tunazungumzia podAntiAffinity kwenye nodi tofauti: topologyKey: "kubernetes.io/hostname", - na sio kuhusu maeneo tofauti ya upatikanaji. Ili kutekeleza HA kamili, itabidi uchimbe zaidi katika mada hii.

7. Kupuuza PodDisruptionBudgets

Fikiria kuwa una mzigo wa uzalishaji kwenye nguzo ya Kubernetes. Mara kwa mara, nodi na nguzo yenyewe zinapaswa kusasishwa (au kufutwa kazi). PodDisruptionBudget (PDB) ni kitu kama makubaliano ya dhamana ya huduma kati ya wasimamizi wa nguzo na watumiaji.

PDB hukuruhusu kuzuia usumbufu wa huduma unaosababishwa na ukosefu wa nodi:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Katika mfano huu, wewe, kama mtumiaji wa kundi hili, unasema kwa wasimamizi: "Halo, nina huduma ya mlinda bustani, na haijalishi unafanya nini, ningependa angalau nakala 2 za huduma hii zipatikane kila wakati. .”

Unaweza kusoma zaidi kuhusu hili hapa.

8. Watumiaji wengi au mazingira katika kundi la pamoja

Majina ya Kubernetes (nafasi za majina) usipe insulation kali.

Dhana potofu ya kawaida ni kwamba ikiwa utapeleka mzigo usio wa uzalishaji kwenye nafasi moja ya jina na mzigo wa prod kwenda mwingine, basi wao. haitaathiriana kwa njia yoyote ile... Hata hivyo, kiwango fulani cha kutengwa kinaweza kufikiwa kwa kutumia maombi/vizuizi vya rasilimali, kuweka sehemu za upendeleo, na kuweka Madarasa ya kipaumbele. Kutengwa kwa "kimwili" katika ndege ya data hutolewa na washirika, uvumilivu, uchafu (au nodeselectors), lakini utengano kama huo ni sawa. ngumu kutekeleza.

Wale ambao wanahitaji kuchanganya aina zote mbili za mzigo wa kazi katika nguzo moja watalazimika kukabiliana na utata. Ikiwa hakuna haja hiyo, na unaweza kumudu kuwa na moja nguzo moja zaidi (sema, katika wingu la umma), basi ni bora kufanya hivyo. Hii itafikia kiwango cha juu zaidi cha insulation.

9.Sera ya Trafiki ya nje: Kundi

Mara nyingi tunaona kuwa trafiki yote ndani ya nguzo huja kupitia huduma kama NodePort, ambayo sera chaguo-msingi imewekwa. externalTrafficPolicy: Cluster... Ina maana kwamba NodePort imefunguliwa kwenye kila nodi kwenye nguzo, na unaweza kutumia yoyote kati yao kuingiliana na huduma inayotaka (seti ya maganda).

Wakati huo huo, maganda halisi yanayohusiana na huduma iliyotajwa hapo juu ya NodePort kawaida hupatikana tu kwenye fulani sehemu ndogo ya nodi hizi. Kwa maneno mengine, ikiwa nitaunganisha kwa nodi ambayo haina ganda linalohitajika, itasambaza trafiki kwa nodi nyingine, kuongeza hop na muda wa kusubiri unaoongezeka (ikiwa nodi ziko katika maeneo tofauti ya upatikanaji/vituo vya data, muda wa kusubiri unaweza kuwa wa juu kabisa; kwa kuongeza, gharama za trafiki za egress zitaongezeka).

Kwa upande mwingine, ikiwa huduma fulani ya Kubernetes ina seti ya sera externalTrafficPolicy: Local, kisha NodePort inafungua tu kwenye nodi hizo ambapo maganda yanayohitajika yanaendesha. Wakati wa kutumia usawazishaji wa mzigo wa nje unaoangalia hali (kukagua afya) endpoints (inafanyaje AWS ELB), Yeye itatuma trafiki tu kwa nodi muhimu, ambayo itakuwa na athari ya manufaa kwa ucheleweshaji, mahitaji ya kompyuta, bili za egress (na akili ya kawaida inaamuru sawa).

Kuna uwezekano mkubwa kuwa tayari unatumia kitu kama hicho traefik au kidhibiti-nginx-ingress kama sehemu ya mwisho ya NodePort (au LoadBalancer, ambayo pia hutumia NodePort) kuelekeza trafiki ya kuingia kwa HTTP, na kuweka chaguo hili kunaweza kupunguza sana muda wa kusubiri kwa maombi kama haya.

В uchapishaji huu Unaweza kujifunza zaidi kuhusu externalTrafficPolicy, faida na hasara zake.

10. Usijifunge kwa makundi na usitumie vibaya ndege ya udhibiti

Hapo awali, ilikuwa kawaida kuita seva kwa majina sahihi: Anton, HAL9000 na Colossus... Leo zimebadilishwa na vitambulishi vinavyozalishwa bila mpangilio. Walakini, tabia hiyo ilibaki, na sasa majina sahihi huenda kwenye vikundi.

Hadithi ya kawaida (kulingana na matukio halisi): yote yalianza na uthibitisho wa dhana, kwa hivyo nguzo ilikuwa na jina la kiburi. kupima… Miaka imepita na BADO inatumika katika uzalishaji, na kila mtu anaogopa kuigusa.

Hakuna kitu cha kufurahisha kuhusu vikundi kugeuka kuwa wanyama vipenzi, kwa hivyo tunapendekeza kuwaondoa mara kwa mara wakati wa kufanya mazoezi kupona maafa (hii itasaidia uhandisi wa machafuko - takriban. tafsiri.). Kwa kuongeza, haitakuwa na madhara kufanya kazi kwenye safu ya udhibiti (ndege ya kudhibiti). Kuogopa kumgusa sio ishara nzuri. Nk amekufa? Jamani, mna matatizo kweli!

Kwa upande mwingine, haupaswi kubebwa na kuidanganya. Pamoja na wakati safu ya udhibiti inaweza kuwa polepole. Uwezekano mkubwa zaidi, hii ni kwa sababu ya idadi kubwa ya vitu vilivyoundwa bila kuzunguka kwao (hali ya kawaida wakati wa kutumia Helm na mipangilio ya msingi, ndiyo sababu hali yake katika usanidi / siri haijasasishwa - kwa sababu hiyo, maelfu ya vitu hujilimbikiza ndani. safu ya udhibiti) au kwa uhariri wa mara kwa mara wa vitu vya kube-api (kwa kuongeza kiotomatiki, kwa CI/CD, kwa ufuatiliaji, kumbukumbu za matukio, vidhibiti, n.k.).

Zaidi ya hayo, tunapendekeza uangalie mikataba ya SLA/SLO na mtoa huduma anayesimamiwa wa Kubernetes na kuzingatia dhamana. Muuzaji anaweza kuhakikisha kudhibiti upatikanaji wa safu (au sehemu zake ndogo), lakini sio kucheleweshwa kwa p99 kwa maombi unayotuma kwake. Kwa maneno mengine, unaweza kuingia kubectl get nodes, na kupokea jibu tu baada ya dakika 10, na hii haitakuwa ukiukaji wa masharti ya mkataba wa huduma.

11. Bonasi: kwa kutumia lebo mpya zaidi

Lakini hii tayari ni classic. Hivi majuzi tumepata mbinu hii mara chache, kwani wengi, wamejifunza kutoka kwa uzoefu wa uchungu, wameacha kutumia lebo. :latest na kuanza kubandika matoleo. Hooray!

ECR hudumisha kutoweza kubadilika kwa vitambulisho vya picha; Tunapendekeza ujifahamishe na kipengele hiki cha ajabu.

Muhtasari

Usitarajie kila kitu kufanya kazi mara moja: Kubernetes sio tiba. Programu mbaya itabaki hivi hata Kubernetes (na pengine itakuwa mbaya zaidi). Uzembe utasababisha ugumu mwingi, kazi ya polepole na yenye mkazo ya safu ya udhibiti. Zaidi ya hayo, una hatari ya kuachwa bila mkakati wa kurejesha maafa. Usitarajie Kubernetes kutoa kutengwa na upatikanaji wa juu nje ya boksi. Tumia muda kufanya programu yako iwe asili ya wingu.

Unaweza kufahamiana na uzoefu ambao haukufanikiwa wa timu mbali mbali mkusanyiko huu wa hadithi na Henning Jacobs.

Wale wanaotaka kuongeza kwenye orodha ya makosa yaliyotolewa katika nakala hii wanaweza kuwasiliana nasi kwenye Twitter (@MarekBartik, @MstrsObserver).

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

«Kubuni Nguzo za Kubernetes: Je!";
«ABC ya Usalama katika Kubernetes: Uthibitishaji, Uidhinishaji, Ukaguzi";
«Kuongeza kasi kiotomatiki na usimamizi wa rasilimali katika Kubernetes"(hakiki na ripoti ya video);
«ConfigMaps katika Kubernetes: nuances muhimu kujua kuhusu'.

Chanzo: mapenzi.com

Makosa 10 ya Kawaida Unapotumia Kubernetes