🥇Kupanua na kuongeza Kubernetes (ripoti ya hakiki na video)

Aprili 8 kwenye mkutano huo Saint HighLoad++ 2019, kama sehemu ya sehemu ya "DevOps na Operesheni", ripoti "Kupanua na Kukamilisha Kubernetes" ilitolewa, katika uundaji ambao wafanyikazi watatu wa kampuni ya Flant walishiriki. Ndani yake, tunazungumza juu ya hali nyingi ambazo tulitaka kupanua na kukamilisha uwezo wa Kubernetes, lakini ambayo hatukupata suluhisho lililotengenezwa tayari na rahisi. Tuna suluhu zinazohitajika katika mfumo wa miradi ya Open Source, na hotuba hii pia imejitolea kwao.

Kwa jadi, tunafurahi kuwasilisha video ya ripoti hiyo (Dakika 50, taarifa zaidi kuliko makala) na muhtasari kuu katika fomu ya maandishi. Nenda!

Msingi na nyongeza katika K8s

Kubernetes inabadilisha tasnia na mbinu za utawala ambazo zimeanzishwa kwa muda mrefu:

Shukrani kwake vifupisho, hatufanyi kazi tena na dhana kama vile kusanidi usanidi au kuendesha amri (Mpikaji, Anayeweza Kuwajibika...), lakini tunatumia kupanga vyombo, huduma, n.k.
Tunaweza kuandaa maombi bila kufikiria juu ya nuances ya tovuti maalum, ambayo itazinduliwa: chuma tupu, wingu la mmoja wa watoa huduma, nk.
Ukiwa na K8 hujawahi kufikiwa zaidi mazoea bora juu ya miundombinu ya kuandaa: mbinu za kuongeza, kujiponya, uvumilivu wa makosa, nk.

Walakini, kwa kweli, kila kitu sio laini sana: Kubernetes pia ilileta changamoto zake mpya.

Mabernet hakuna ni mchanganyiko unaotatua matatizo yote ya watumiaji wote. Cha msingi Kubernetes inawajibika tu kwa seti ya vitendaji vya chini vya lazima ambavyo vipo ndani kila mtu nguzo:

Msingi wa Kubernetes hufafanua seti ya msingi ya malighafi za kupanga vyombo, kudhibiti trafiki, na kadhalika. Tulizungumza juu yao kwa undani zaidi ripoti miaka 2 iliyopita.

Kwa upande mwingine, K8s hutoa fursa nzuri za kupanua kazi zinazopatikana, ambazo husaidia kufunga wengine - maalum - mahitaji ya mtumiaji. Nyongeza kwa Kubernetes ni wajibu wa wasimamizi wa nguzo, ambao lazima wasakinishe na kusanidi kila kitu muhimu ili kupata nguzo yao "katika umbo linalofaa" [kusuluhisha matatizo yao mahususi]. Hizi ni nyongeza za aina gani? Hebu tuangalie mifano fulani.

Mifano ya nyongeza

Baada ya kusakinisha Kubernetes, tunaweza kushangaa kwamba mtandao ambao ni muhimu sana kwa mwingiliano wa maganda ndani ya nodi na kati ya nodi haufanyi kazi peke yake. Kernel ya Kubernetes haihakikishii miunganisho inayohitajika; badala yake, huamua mtandao kiolesura (CNI) kwa programu jalizi za wahusika wengine. Lazima tusakinishe moja ya nyongeza hizi, ambayo itawajibika kwa usanidi wa mtandao.

Mfano wa karibu ni ufumbuzi wa kuhifadhi data (diski ya ndani, kifaa cha kuzuia mtandao, Ceph ...). Hapo awali walikuwa katika msingi, lakini pamoja na ujio CSI hali inabadilika kuwa kitu sawa na kile kilichoelezwa tayari: interface iko katika Kubernetes, na utekelezaji wake ni katika moduli za tatu.

Mifano mingine ni pamoja na:

Ingress-watawala (tazama mapitio yao katika makala yetu ya hivi karibuni).
meneja mkuu:
Waendeshaji ni darasa zima la programu-jalizi (ambazo ni pamoja na meneja wa cert aliyetajwa), zinafafanua primitive(za) na kidhibiti. Mantiki ya kazi yao ni mdogo tu kwa mawazo yetu na inaruhusu sisi kugeuza vipengele vya miundombinu vilivyotengenezwa tayari (kwa mfano, DBMS) kwenye primitives, ambayo ni rahisi zaidi kufanya kazi nayo (kuliko kwa seti ya vyombo na mipangilio yao). Idadi kubwa ya waendeshaji imeandikwa - hata kama wengi wao bado hawajawa tayari kwa uzalishaji, ni suala la muda tu:
Vipimo - kielelezo kingine cha jinsi Kubernetes ilivyotenganisha kiolesura (Metrics API) kutoka kwa utekelezaji (viongezo vya wahusika wengine kama vile adapta ya Prometheus, wakala wa nguzo ya Datadog...).
Kwa ufuatiliaji na takwimu, ambapo katika mazoezi hatuhitaji tu Prometheus na Grafana, lakini pia kube-state-metrics, nodi-exporter, nk.

Na hii sio orodha kamili ya nyongeza ... Kwa mfano, katika kampuni ya Flant tunayoweka sasa 29 nyongeza (vyote hivi huunda jumla ya vitu 249 vya Kubernetes). Kwa ufupi, hatuwezi kuona maisha ya nguzo bila nyongeza.

Operesheni

Waendeshaji wameundwa ili kugeuza shughuli za kawaida ambazo tunakutana nazo kila siku kiotomatiki. Hapa kuna mifano ya maisha halisi ambayo kuandika opereta itakuwa suluhisho bora:

Kuna usajili wa kibinafsi (yaani unaohitaji kuingia) na picha za programu. Inachukuliwa kuwa kila pod imepewa siri maalum ambayo inaruhusu uthibitishaji katika Usajili. Kazi yetu ni kuhakikisha kuwa siri hii inapatikana katika nafasi ya majina ili maganda yaweze kupakua picha. Kunaweza kuwa na maombi mengi (kila ambayo inahitaji siri), na ni muhimu kusasisha siri wenyewe mara kwa mara, hivyo chaguo la kuweka siri kwa mkono huondolewa. Hapa ndipo opereta anakuja kuwaokoa: tunaunda kidhibiti ambacho kitasubiri nafasi ya majina kuonekana na, kulingana na tukio hili, itaongeza siri kwenye nafasi ya majina.
Ruhusu kwa chaguo-msingi ufikiaji kutoka kwa maganda hadi kwa Mtandao ni marufuku. Lakini wakati mwingine inaweza kuhitajika: ni mantiki kwa utaratibu wa ruhusa ya kufikia kufanya kazi kwa urahisi, bila kuhitaji ujuzi maalum, kwa mfano, kwa kuwepo kwa lebo fulani katika nafasi ya jina. Opereta anawezaje kutusaidia hapa? Kidhibiti kimeundwa ambacho husubiri lebo kuonekana kwenye nafasi ya majina na kuongeza sera inayofaa kwa ufikiaji wa Mtandao.
Hali sawa: tuseme tulihitaji kuongeza fulani uchafu, ikiwa ina lebo inayofanana (yenye aina fulani ya kiambishi awali). Vitendo na opereta ni dhahiri ...

Katika nguzo yoyote, kazi za kawaida lazima zitatuliwe, na usahihi hii inaweza kufanyika kwa kutumia waendeshaji.

Kwa muhtasari wa hadithi zote zilizoelezewa, tulifikia hitimisho kwamba kwa kazi ya starehe katika Kubernetes unahitaji: A) sakinisha nyongeza, b) kuendeleza waendeshaji (kwa kutatua kazi za kila siku za msimamizi).

Jinsi ya kuandika taarifa kwa Kubernetes?

Kwa ujumla, mpango ni rahisi:

... lakini basi inageuka kuwa:

API ya Kubernetes ni jambo lisilo la maana ambalo huchukua muda mwingi kulifahamu;
upangaji programu pia sio kwa kila mtu (lugha ya Go ilichaguliwa kama lugha inayopendelewa kwa sababu kuna mfumo maalum kwa hiyo - Opereta SDK);
Hali ni sawa na mfumo yenyewe.

line ya chini: kuandika kidhibiti (mendeshaji) lazima kutumia rasilimali muhimu kusoma nyenzo. Hii inaweza kuhesabiwa haki kwa waendeshaji "wakubwa" - sema, kwa DBMS ya MySQL. Lakini ikiwa tunakumbuka mifano iliyoelezwa hapo juu (kufunua siri, kufikia pods kwenye mtandao ...), ambayo tunataka pia kufanya kwa usahihi, basi tutaelewa kuwa jitihada zilizotumiwa zitazidi matokeo tunayohitaji sasa:

Kwa ujumla, shida hutokea: kutumia rasilimali nyingi na kupata chombo sahihi cha kuandika taarifa, au kufanya hivyo kwa njia ya zamani (lakini haraka). Ili kuitatua - kupata maelewano kati ya hali hizi kali - tuliunda mradi wetu wenyewe: shell-operator (tazama pia yake tangazo la hivi karibuni kwenye kitovu).

Shell-operator

Anafanyaje kazi? Kundi hili lina ganda lililo na mfumo wa jozi wa Go na kiendesha ganda. Karibu nayo ni seti ya kulabu (maelezo zaidi juu yao - tazama hapa chini). Shell-operator yenyewe inajiandikisha kwa fulani maendeleo katika Kubernetes API, inapotokea inazindua ndoano zinazolingana.

Je, mwendeshaji ganda anajua vipi ndoano za kutaja matukio gani? Habari hii hupitishwa kwa mendeshaji wa ganda na ndoano zenyewe, na hufanya hivyo kwa urahisi sana.

Ndoano ni hati ya Bash au faili nyingine yoyote inayoweza kutekelezwa ambayo inakubali hoja moja --config na hujibu na JSON. Mwisho huamua ni vitu gani vya kupendeza kwake na ni matukio gani (kwa vitu hivi) yanapaswa kujibiwa:

Nitaonyesha utekelezaji kwenye ganda-opereta wa moja ya mifano yetu - siri za kuoza kwa kupata Usajili wa kibinafsi na picha za programu. Inajumuisha hatua mbili.

Mazoezi: 1. Andika ndoano

Kwanza kabisa, katika ndoano tutasindika --config, ikionyesha kuwa tunavutiwa na nafasi za majina, na haswa, wakati wa kuundwa kwao:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Mantiki ingeonekanaje? Pia rahisi sana:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Hatua ya kwanza ni kujua ni nafasi gani ya majina iliundwa, na ya pili ni kuunda kwa kutumia kubectl siri ya nafasi hii ya majina.

Mazoezi: 2. Kukusanya picha

Kinachobaki ni kupitisha ndoano iliyoundwa kwa opereta-ganda - jinsi ya kufanya hivyo? Opereta-ganda yenyewe inakuja kama picha ya Docker, kwa hivyo kazi yetu ni kuongeza ndoano kwenye saraka maalum kwenye picha hii:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Kilichobaki ni kuikusanya na kuisukuma:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Mguso wa mwisho ni kupeleka picha kwenye nguzo. Ili kufanya hivyo, hebu tuandike Kuhamishwa:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Kuna mambo mawili ya kuzingatia:

dalili ya picha mpya iliyoundwa;
Hiki ni kipengee cha mfumo ambacho (kwa uchache) kinahitaji haki za kujisajili kwa matukio katika Kubernetes na kutoa siri kwa nafasi za majina, kwa hivyo tunaunda ServiceAccount (na seti ya sheria) za ndoano.

Matokeo - tulitatua shida yetu jamaa kwa Kubernetes kwa njia inayounda opereta kwa ajili ya kutengua siri.

Vipengele vingine vya uendeshaji wa shell

Ili kupunguza vitu vya aina uliyochagua ambayo ndoano itafanya kazi nayo, zinaweza kuchujwa, kuchagua kulingana na lebo fulani (au kutumia matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Zinazotolewa utaratibu wa kupunguza, ambayo - kwa kutumia kichungi cha jq - hukuruhusu kubadilisha vitu vikubwa vya JSON kuwa vidogo, ambapo vigezo hivyo tu vinabaki ambavyo tunataka kufuatilia kwa mabadiliko.

Wakati ndoano inaitwa, ganda-operator hupita data ya kitu, ambayo inaweza kutumika kwa mahitaji yoyote.

Matukio ambayo huanzisha ndoano hayazuiliwi kwa matukio ya Kubernetes: kiendesha ganda hutoa usaidizi kwa kuita ndoano kwa wakati (sawa na crontab katika mpangilio wa jadi), pamoja na tukio maalum onStartup. Matukio haya yote yanaweza kuunganishwa na kupewa ndoano sawa.

Na sifa mbili zaidi za kiendesha ganda:

Inafanya kazi kwa usawa. Kwa kuwa tukio la Kubernetes (kama vile kitu kinachoundwa) lilipokewa, matukio mengine (kama vile kitu kimoja kufutwa) yangeweza kutokea kwenye nguzo, na ndoano zinahitaji kuwajibika kwa hili. Ikiwa ndoano ilitekelezwa na kosa, basi kwa default itakuwa piga tena simu hadi kukamilika kwa mafanikio (tabia hii inaweza kubadilishwa).
Inasafirisha nje vipimo kwa Prometheus, ambayo unaweza kuelewa ikiwa kiendesha ganda kinafanya kazi, tafuta idadi ya makosa kwa kila ndoano na saizi ya foleni ya sasa.

Kwa muhtasari wa sehemu hii ya ripoti:

Inasakinisha programu jalizi

Kwa kufanya kazi vizuri na Kubernetes, hitaji la kusanikisha nyongeza pia lilitajwa. Nitakuambia juu yake kwa kutumia mfano wa njia ya kampuni yetu jinsi tunavyofanya sasa.

Tulianza kufanya kazi na Kubernetes na vikundi kadhaa, nyongeza pekee ambayo ilikuwa Ingress. Ilihitaji kusakinishwa tofauti katika kila nguzo, na tulifanya usanidi kadhaa wa YAML kwa mazingira tofauti: chuma tupu, AWS...

Kwa kuwa kulikuwa na vikundi zaidi, kulikuwa na usanidi zaidi. Kwa kuongezea, tuliboresha usanidi huu wenyewe, kama matokeo ambayo ikawa tofauti kabisa:

Ili kuweka kila kitu kwa mpangilio, tulianza na hati (install-ingress.sh), ambayo ilichukua kama hoja aina ya nguzo ambayo tutatumia, ilizalisha usanidi muhimu wa YAML na kuisambaza kwa Kubernetes.

Kwa kifupi, njia yetu zaidi na hoja zinazohusiana nayo zilikuwa kama ifuatavyo:

kufanya kazi na usanidi wa YAML, injini ya kiolezo inahitajika (katika hatua za kwanza hii ni sed rahisi);
na kuongezeka kwa idadi ya nguzo, hitaji la kusasisha kiotomatiki lilikuja (suluhisho la mapema lilikuwa kuweka hati kwenye Git, kuisasisha kwa kutumia cron na kuiendesha);
hati kama hiyo ilihitajika kwa Prometheus (install-prometheus.sh), hata hivyo, inajulikana kwa ukweli kwamba inahitaji data zaidi ya ingizo, na vile vile uhifadhi wao (kwa njia nzuri - katikati na kwenye nguzo), na data fulani (nenosiri) inaweza kuzalishwa kiotomatiki:
hatari ya kusambaza kitu kibaya kwa idadi inayoongezeka ya vikundi ilikuwa ikiongezeka kila mara, kwa hivyo tuligundua kuwa wasakinishaji (yaani maandishi mawili: ya Ingress na Prometheus) staging ilihitajika (matawi kadhaa katika Git, crons kadhaa ili kusasisha katika sambamba: nguzo imara au mtihani);
с kubectl apply imekuwa ngumu kufanya kazi nayo kwa sababu sio ya kutangaza na inaweza kuunda vitu tu, lakini sio kufanya maamuzi juu ya hali yao / kufuta;
Tulikuwa tunakosa baadhi ya vipengele ambavyo hatukutekeleza kabisa wakati huo:
- udhibiti kamili juu ya matokeo ya sasisho za nguzo,
- uamuzi otomatiki wa baadhi ya vigezo (pembejeo kwa hati za usakinishaji) kulingana na data inayoweza kupatikana kutoka kwa nguzo (ugunduzi),
- maendeleo yake ya kimantiki katika mfumo wa ugunduzi unaoendelea.

Tulitekeleza uzoefu huu wote uliokusanywa ndani ya mfumo wa mradi wetu mwingine - kiendeshaji cha kuongeza.

Mendeshaji wa nyongeza

Inategemea kiendesha-ganda kilichotajwa tayari. Mfumo mzima unaonekana kama hii:

Ifuatayo inaongezwa kwa ndoano za waendeshaji ganda:

uhifadhi wa maadili,
Chati ya usukani,
sehemu hiyo inafuatilia hifadhi ya maadili na - ikiwa kuna mabadiliko yoyote - anauliza Helm kukunja tena chati.

Kwa hivyo, tunaweza kuguswa na tukio huko Kubernetes, kuzindua ndoano, na kutoka kwa ndoano hii tunaweza kufanya mabadiliko kwenye hifadhi, baada ya hapo chati itapakuliwa tena. Katika mchoro unaosababisha, tunatenganisha seti ya ndoano na chati katika sehemu moja, ambayo tunaita moduli:

Kunaweza kuwa na moduli nyingi, na kwao tunaongeza ndoano za kimataifa, duka la maadili ya kimataifa, na sehemu inayofuatilia duka hili la kimataifa.

Sasa, jambo linapotokea katika Kubernetes, tunaweza kuitikia kwa kutumia ndoano ya kimataifa na kubadilisha kitu katika duka la kimataifa. Mabadiliko haya yatatambuliwa na yatasababisha moduli zote kwenye nguzo kutekelezwa:

Mpango huu unakidhi mahitaji yote ya kusakinisha programu jalizi ambayo yamesemwa hapo juu:

Helm inawajibika kwa kuiga na kutangaza.
Suala la kusasisha kiotomatiki lilitatuliwa kwa kutumia ndoano ya kimataifa, ambayo huenda kwenye Usajili kwa ratiba na, ikiwa itaona picha ya mfumo mpya huko, inaifungua (yaani "yenyewe").
Mipangilio ya kuhifadhi kwenye nguzo inatekelezwa kwa kutumia ConfigMap, ambayo ina data ya msingi ya hifadhi (wakati wa kuanza hupakiwa kwenye hifadhi).
Matatizo ya kutengeneza nenosiri, ugunduzi na ugunduzi endelevu yalitatuliwa kwa kutumia ndoano.
Uwekaji picha hupatikana shukrani kwa vitambulisho, ambavyo Docker inasaidia nje ya boksi.
Matokeo hufuatiliwa kwa kutumia vipimo ambavyo tunaweza kuelewa hali.

Mfumo huu wote unatekelezwa kwa njia ya binary moja katika Go, ambayo inaitwa addon-operator. Hii inafanya mchoro uonekane rahisi:

Sehemu kuu katika mchoro huu ni seti ya moduli (imeangaziwa kwa kijivu hapa chini). Sasa tunaweza kuandika moduli ya nyongeza inayohitajika kwa juhudi kidogo na kuwa na uhakika kwamba itasakinishwa katika kila nguzo, itasasishwa na kujibu matukio inayohitaji kwenye nguzo.

Matumizi ya "Flant". kiendeshaji cha kuongeza kwenye vikundi 70+ vya Kubernetes. Hali ya sasa - toleo la alpha. Sasa tunatayarisha hati ili kutolewa beta, lakini kwa sasa kwenye ghala mifano inapatikana, kwa misingi ambayo unaweza kuunda addon yako mwenyewe.

Ninaweza kupata wapi moduli za opereta ya addon? Kuchapisha maktaba yetu ni hatua inayofuata kwetu; tunapanga kufanya hivi katika msimu wa joto.

Video na slaidi

Video kutoka kwa utendakazi (~dakika 50):

Uwasilishaji wa ripoti:

PS

Ripoti zingine kwenye blogi yetu:

«Hifadhidata na Kubernetes"; (Dmitry Stolyarov; Novemba 8, 2018 kwenye HighLoad++);
«Ufuatiliaji na Kubernetes"; (Dmitry Stolyarov; Mei 28, 2018 katika RootConf);
«Mbinu Bora za CI/CD na Kubernetes na GitLab"; (Dmitry Stolyarov; Novemba 7, 2017 kwenye HighLoad++);
«Uzoefu wetu na Kubernetes katika miradi midogo"; (Dmitry Stolyarov; Juni 6, 2017 katika RootConf).

Unaweza pia kupendezwa na machapisho yafuatayo:

«Tunakuletea kiendesha ganda: kuunda waendeshaji kwa Kubernetes imekuwa rahisi'.

Chanzo: mapenzi.com

Kupanua na kukamilisha Kubernetes (hakiki na ripoti ya video)