Mahitaji ya kuunda programu katika Kubernetes

Leo ninapanga kuzungumza juu ya jinsi ya kuandika maombi na ni nini mahitaji ya maombi yako kufanya kazi vizuri katika Kubernetes. Ili hakuna maumivu ya kichwa na programu, ili usilazimike kuvumbua na kuunda "mikono" yoyote karibu nayo - na kila kitu hufanya kazi kama Kubernetes yenyewe ilivyokusudia.

Mhadhara huu ni sehemu ya "Shule ya Usiku ya Slurm kwenye Kubernetes" Unaweza kutazama mihadhara ya wazi ya kinadharia ya Shule ya Jioni kwenye Youtube, iliyopangwa katika orodha ya kucheza. Kwa wale wanaopendelea maandishi badala ya video, tumeandaa nakala hii.

Jina langu ni Pavel Selivanov, kwa sasa mimi ni mhandisi anayeongoza wa DevOps katika Mail.ru Cloud Solutions, tunatengeneza mawingu, tunafanya usimamizi kubernetes na kadhalika. Majukumu yangu sasa yanajumuisha usaidizi katika usanidi, kusambaza mawingu haya, kusambaza programu ambazo tunaandika na kutengeneza zana moja kwa moja tunazotoa kwa watumiaji wetu.

Nimekuwa nikifanya DevOps, nadhani kwa mwisho, pengine, miaka mitatu. Lakini, kimsingi, nimekuwa nikifanya kile DevOps hufanya kwa karibu miaka mitano sasa. Kabla ya hapo, nilihusika zaidi na mambo ya admin. Nilianza kufanya kazi na Kubernetes muda mrefu uliopita - labda kama miaka minne imepita tangu nianze kufanya kazi nayo.

Kwa ujumla, nilianza wakati Kubernetes ilikuwa toleo la 1.3, pengine, na labda 1.2 - wakati ilikuwa bado changa. Sasa si changa tena - na ni dhahiri kwamba kuna mahitaji makubwa sokoni kwa wahandisi ambao wangependa kuwa na uwezo wa kufanya Kubernetes. Na makampuni yana mahitaji makubwa sana kwa watu kama hao. Kwa hiyo, kwa kweli, hotuba hii ilionekana.

Ikiwa tutazungumza kulingana na mpango wa kile nitakachozungumza, inaonekana hivi, kwenye mabano imeandikwa (TL;DR) - "nde sana; usisome". Wasilisho langu leo ​​litajumuisha orodha zisizo na mwisho.

Kwa kweli, mimi mwenyewe sipendi mawasilisho kama haya yanapofanywa, lakini hii ni mada ambayo nilipokuwa nikitayarisha uwasilishaji huu, sikujua jinsi ya kupanga habari hii tofauti.

Kwa sababu, kwa ujumla, maelezo haya ni “ctrl+c, ctrl+v”, kutoka, miongoni mwa mambo mengine, Wiki yetu katika sehemu ya DevOps, ambapo tumeandika mahitaji ya wasanidi programu: “jamani, ili tuzindua programu yako katika Kubernetes, inapaswa kuwa hivi."

Ndiyo sababu uwasilishaji uligeuka kuwa orodha kubwa sana. Pole. Nitajaribu kusema kadri niwezavyo ili isichoshe ikiwezekana.

Tutaangalia nini sasa:

• hizi ni, kwanza, magogo (magogo ya maombi?), nini cha kufanya nao katika Kubernetes, nini cha kufanya nao, nini wanapaswa kuwa;
• nini cha kufanya na usanidi katika Kubernetes, ni njia gani bora na mbaya zaidi za kusanidi programu ya Kubernetes;
• Wacha tuzungumze juu ya hundi za ufikiaji zilivyo kwa ujumla, zinapaswa kuonekanaje;
• hebu tuzungumze juu ya nini kuzima kwa neema ni;
• tuzungumze tena kuhusu rasilimali;
• Hebu tuguse mada ya kuhifadhi data kwa mara nyingine tena;
• na mwisho nitakuambia neno hili la ajabu la asili ya utumiaji wa wingu ni nini. Cloudnativeness, kama kivumishi cha neno hili.

Kumbukumbu

Ninapendekeza kuanza na magogo - ambapo magogo haya yanahitaji kusukumwa huko Kubernetes. Sasa umezindua programu katika Kubernetes. Kulingana na classics, maombi ya awali daima aliandika kumbukumbu mahali fulani katika faili. Programu mbaya ziliandika kumbukumbu kwa faili katika saraka ya nyumbani ya msanidi programu ambaye alizindua programu. Programu nzuri ziliandika kumbukumbu kwa faili mahali fulani ndani /var/log.

Ipasavyo, zaidi, wasimamizi wazuri walikuwa na vitu kadhaa vilivyosanidiwa katika miundombinu yao ambayo magogo haya yanaweza kuzunguka - rsyslog sawa, ambayo huangalia magogo haya na wakati kitu kinatokea kwao, kuna mengi yao, huunda nakala za chelezo , huweka kumbukumbu hapo. , hufuta faili za zamani, zaidi ya wiki, miezi sita na nyingine zaidi. Kwa nadharia, tunapaswa kuwa na vifungu ili kwa sababu tu programu inaandika kumbukumbu, nafasi kwenye seva za uzalishaji (seva za kupigana?) haiisha. Na, ipasavyo, uzalishaji wote haukuacha kwa sababu ya magogo.

Tunapohamia ulimwengu wa Kubernetes na kukimbia kitu kimoja huko, jambo la kwanza unaweza kulipa kipaumbele ni ukweli kwamba watu, kama walivyoandika kumbukumbu kwenye faili, wanaendelea kuziandika.

Inabadilika kuwa ikiwa tunazungumza juu ya Kubernetes, mahali pazuri pa kuandika kumbukumbu mahali fulani kutoka kwa chombo cha docker ni kuandika tu kutoka kwa programu kwenda kwa kinachojulikana kama Stdout/Stderr, ambayo ni, mito ya kawaida ya mfumo wa uendeshaji, pato la kawaida la makosa . Hii ndiyo njia sahihi zaidi, rahisi na yenye mantiki zaidi ya kuweka kumbukumbu katika kanuni katika Docker na hasa katika Kubernetis. Kwa sababu ikiwa programu yako itaandika kumbukumbu kwa Stdout/Stderr, basi ni juu ya Docker na programu jalizi ya Kubernetes kuamua cha kufanya na kumbukumbu hizi. Docker kwa chaguo-msingi itaunda faili zake maalum katika umbizo la JSON.

Hapa swali linatokea, utafanya nini baadaye na magogo haya? Njia rahisi ni wazi, tuna uwezo wa kufanya kubectl logs na angalia magogo haya ya "maganda" haya. Lakini, pengine, hii sio chaguo nzuri sana - kitu kingine kinahitajika kufanywa na magogo.

Kwa sasa, hebu tuzungumze wakati huo huo, tangu tuligusa juu ya mada ya magogo, kuhusu kitu kama magogo inapaswa kuonekana kama. Hiyo ni, hii haitumiki moja kwa moja kwa Kubernetes, lakini tunapoanza kufikiri juu ya nini cha kufanya na magogo, itakuwa vizuri kufikiri juu ya hili pia.

Tunahitaji aina fulani ya zana, kwa njia ya kirafiki, ambayo itachukua kumbukumbu hizi ambazo docker yetu huweka kwenye faili zake na kuzituma mahali fulani. Kwa ujumla, sisi huwa tunazindua aina fulani ya wakala ndani ya Kubernetes katika mfumo wa DaemonSet - mkusanyaji wa kumbukumbu, ambayo inaelezwa kwa urahisi ambapo kumbukumbu ambazo Docker hukusanya ziko. Na wakala huyu wa kukusanya huzichukua tu, labda hata kuzichanganua njiani, labda kuziboresha na maelezo ya ziada ya meta na, hatimaye, kuzituma kwa hifadhi mahali fulani. Tofauti tayari zinawezekana huko. Inayojulikana zaidi labda ni Elasticsearch, ambapo unaweza kuhifadhi kumbukumbu na unaweza kuzipata kwa urahisi kutoka hapo. Kisha, kwa kutumia ombi, kwa kutumia Kibana, kwa mfano, jenga grafu kulingana nao, jenga tahadhari kulingana nao, na kadhalika.

Wazo muhimu zaidi, nataka kulirudia tena, ni kwamba ndani ya Docker, haswa ndani ya Kubernetes, kuhifadhi kumbukumbu zako kwenye faili ni wazo mbaya sana.

Kwa sababu kwanza, ni ngumu kupata kumbukumbu ndani ya kontena kwenye faili. Lazima kwanza uingie kwenye chombo, utekeleze hapo, na kisha uangalie magogo. Jambo linalofuata ni kwamba ikiwa una kumbukumbu kwenye faili, basi vyombo kawaida huwa na mazingira ya chini na hakuna huduma ambazo zinahitajika kwa kazi ya kawaida na magogo. Wazike, waangalie, wafungue kwenye hariri ya maandishi. Wakati unaofuata ni wakati tuna magogo kwenye faili ndani ya chombo, ikiwa chombo hiki kinafutwa, unaelewa, magogo yatakufa pamoja nayo. Ipasavyo, kuanza tena kwa chombo kunamaanisha kuwa hakuna kumbukumbu tena. Tena, chaguo mbaya.

Na jambo la mwisho ni kwamba ndani ya vyombo kawaida huwa na programu yako na ndivyo hivyo - kawaida ni mchakato pekee unaoendelea. Hakuna mazungumzo hata kidogo juu ya mchakato wowote ambao unaweza kuzungusha faili na kumbukumbu zako. Mara tu kumbukumbu zinapoanza kuandikwa kwa faili, hii inamaanisha kwamba, samahani, tutaanza kupoteza seva ya uzalishaji. Kwa sababu, kwanza, ni ngumu kupata, hakuna anayezifuatilia, na hakuna anayezidhibiti - ipasavyo, faili inakua bila mwisho hadi nafasi kwenye seva itaisha. Kwa hivyo, nasema tena kwamba kuingia kwenye Docker, haswa katika Kubernetes, kwa faili ni wazo mbaya.

Jambo linalofuata, hapa nataka kuzungumza juu ya hili tena - kwa kuwa tunagusa mada ya magogo, itakuwa nzuri kuzungumza juu ya jinsi magogo yanapaswa kuonekana ili iwe rahisi kufanya kazi nao. Kama nilivyosema, mada haihusiani moja kwa moja na Kubernetes, lakini inahusiana vizuri na mada ya DevOps. Juu ya mada ya utamaduni wa maendeleo na urafiki kati ya idara hizi mbili tofauti - Dev na Ops, ili kila mtu awe vizuri.

Hii inamaanisha kuwa kwa kweli, leo, kumbukumbu zinapaswa kuandikwa katika umbizo la JSON. Ikiwa una programu isiyoeleweka yako mwenyewe, ambayo huandika kumbukumbu katika muundo usioeleweka kwa sababu unaingiza aina fulani ya uchapishaji au kitu kama hicho, basi ni wakati wa google aina fulani ya mfumo, aina fulani ya wrapper ambayo inakuwezesha kutekeleza ukataji wa kawaida; wezesha vigezo vya ukataji miti katika JSON hapo, kwa sababu JSON ni umbizo rahisi, kuichanganua ni rahisi.

Ikiwa JSON yako haifanyi kazi kulingana na vigezo fulani, hakuna anayejua nini, basi angalau andika kumbukumbu katika umbizo ambalo linaweza kuchanganuliwa. Hapa, badala yake, inafaa kufikiria juu ya ukweli kwamba, kwa mfano, ikiwa unaendesha rundo la vyombo au michakato tu na nginx, na kila moja ina mipangilio yake ya ukataji miti, basi labda inaonekana kuwa itakuwa ngumu kwako. wachanganue. Kwa sababu kwa kila mfano mpya wa nginx unahitaji kuandika kichanganuzi chako mwenyewe, kwa sababu wanaandika kumbukumbu tofauti. Tena, labda ilifaa kufikiria juu ya kuhakikisha kuwa visa hivi vyote vya nginx vina usanidi sawa wa ukataji miti, na waliandika magogo yao yote kwa usawa. Vile vile hutumika kwa maombi yote kabisa.

Mwishowe, ninataka pia kuongeza mafuta kwenye moto ambayo, kwa kweli, kumbukumbu za muundo wa safu nyingi zinapaswa kuepukwa. Hapa ni jambo, ikiwa umewahi kufanya kazi na watoza wa logi, basi uwezekano mkubwa umeona kile wanachokuahidi, kwamba wanaweza kufanya kazi na magogo ya mstari mbalimbali, kujua jinsi ya kukusanya, na kadhalika. Kwa kweli, kwa maoni yangu, sio mtoza mmoja leo anayeweza kukusanya magogo ya safu nyingi kwa kawaida, kikamilifu na bila makosa. Kwa njia ya kibinadamu, ili iwe rahisi na isiyo na makosa.

Lakini ufuatiliaji wa rafu daima ni kumbukumbu za safu nyingi na jinsi ya kuziepuka. Swali hapa ni kwamba logi ni rekodi ya tukio, na stactrace sio logi. Ikiwa tutakusanya kumbukumbu na kuziweka mahali fulani katika Elasticsearch na kisha kuchora grafu kutoka kwao, kuunda baadhi ya ripoti za shughuli za mtumiaji kwenye tovuti yako, basi unapopata ufuatiliaji wa rafu, inamaanisha kuwa kuna jambo lisilotarajiwa linatokea. hali ambayo haijashughulikiwa katika programu yako. Na inaleta maana kupakia kiotomatiki ufuatiliaji wa rafu mahali fulani kwenye mfumo unaoweza kuwafuatilia.

Hii ni programu (Sentry sawa) ambayo imeundwa mahsusi kufanya kazi na ufuatiliaji wa stack. Inaweza kuunda mara moja kazi za kiotomatiki, kuzikabidhi kwa mtu, tahadhari wakati stacttraces zinapotokea, kupanga safu hizi kwa aina moja, na kadhalika. Kimsingi, haina maana sana kuzungumza juu ya stactraces tunapozungumzia magogo, kwa sababu haya ni, baada ya yote, mambo tofauti na madhumuni tofauti.

Usanidi

Ifuatayo tunazungumza juu ya usanidi katika Kubernetes: nini cha kufanya nayo na jinsi programu za Kubernetes zinapaswa kusanidiwa. Kwa ujumla, mimi husema kwamba Docker sio juu ya vyombo. Kila mtu anajua kuwa Docker ni juu ya vyombo, hata wale ambao hawajafanya kazi na Docker sana. Narudia, Docker sio juu ya vyombo.

Docker, kwa maoni yangu, ni juu ya viwango. Na kuna viwango vya karibu kila kitu: viwango vya kuunda programu yako, viwango vya kusanikisha programu yako.

Na jambo hili - tuliitumia hapo awali, ilijulikana sana na ujio wa vyombo - jambo hili linaitwa vigezo vya ENV (mazingira), yaani, vigezo vya mazingira ambavyo viko kwenye mfumo wako wa uendeshaji. Kwa ujumla hii ni njia bora ya kusanidi programu yako, kwa sababu ikiwa una programu katika JAVA, Python, Go, Perl, Mungu apishe mbali, na wote wanaweza kusoma mwenyeji wa hifadhidata, mtumiaji wa hifadhidata, vigezo vya nenosiri vya hifadhidata, basi ni bora. Una programu katika lugha nne tofauti zilizosanidiwa katika mpango wa hifadhidata kwa njia ile ile. Hakuna usanidi tofauti zaidi.

Kila kitu kinaweza kusanidiwa kwa kutumia vigezo vya ENV. Tunapozungumza juu ya Kubernetes, kuna njia nzuri ya kutangaza anuwai za ENV ndani ya Usambazaji. Ipasavyo, ikiwa tunazungumza juu ya data ya siri, basi tunaweza kusukuma data ya siri mara moja kutoka kwa vigeu vya ENV (nenosiri hadi hifadhidata, n.k.) hadi kwa siri, kuunda nguzo ya siri na kuonyesha katika maelezo ya ENV katika Usambazaji ambayo hatutangazi moja kwa moja. thamani ya kigezo hiki, na thamani ya kigezo hiki cha nenosiri la hifadhidata itasomwa kutoka kwa siri. Hii ni tabia ya kawaida ya Kubernetes. Na hii ndiyo chaguo bora zaidi ya kusanidi programu zako. Katika kiwango cha msimbo, hii inatumika tena kwa watengenezaji. Ikiwa wewe ni DevOps, unaweza kuuliza: “Jamani, tafadhali fundisheni programu yako kusoma vigeu vya mazingira. Na sote tutakuwa na furaha."

Ikiwa kila mtu katika kampuni anasoma vigezo sawa vya mazingira, basi hiyo ni nzuri. Ili isije ikawa kwamba wengine wanasubiri database ya postgres, wengine wanasubiri jina la database, wengine wanasubiri kitu kingine, wengine wanasubiri dbn ya aina fulani, ili, ipasavyo, kuna sare.

Shida inakuja unapokuwa na anuwai nyingi za mazingira hivi kwamba unafungua Upelekaji - na kuna mistari mia tano ya anuwai ya mazingira. Katika kesi hii, una anuwai za mazingira - na hauitaji tena kujitesa. Katika kesi hii, itakuwa na maana kuanza kutumia configs. Hiyo ni, fundisha programu yako kutumia usanidi.

Swali la pekee ni kwamba usanidi sio vile unavyofikiria. Config.pi sio usanidi ambao ni rahisi kutumia. Au usanidi fulani katika umbizo lako mwenyewe, ukiwa na vipawa vingine - huu pia sio usanidi ninaomaanisha.

Ninachozungumzia ni usanidi katika umbizo linalokubalika, yaani, kiwango maarufu zaidi ni kiwango cha .yaml. Ni wazi jinsi ya kuisoma, inasomeka na binadamu, ni wazi jinsi ya kuisoma kutoka kwa maombi.

Ipasavyo, pamoja na YAML, unaweza pia, kwa mfano, kutumia JSON, uchanganuzi ni rahisi kama YAML katika suala la kusoma usanidi wa programu kutoka hapo. Ni dhahiri zaidi usumbufu kwa watu kusoma. Unaweza kujaribu umbizo, a la ini. Ni rahisi sana kusoma, kutoka kwa mtazamo wa kibinadamu, lakini inaweza kuwa ngumu kuichakata kiotomatiki, kwa maana kwamba ikiwa ungependa kuunda usanidi wako mwenyewe, umbizo la ini linaweza kuwa lisilofaa kutengeneza.

Lakini kwa hali yoyote, muundo wowote unaochagua, uhakika ni kwamba kutoka kwa mtazamo wa Kubernetes ni rahisi sana. Unaweza kuweka usanidi wako wote ndani ya Kubernetes, kwenye ConfigMap. Na kisha chukua usanidi huu na uombe iwekwe ndani ya ganda lako katika saraka fulani maalum, ambapo programu yako itasoma usanidi kutoka kwa usanidi huu kana kwamba ni faili tu. Hili, kwa kweli, ndilo linalofaa kufanya wakati una chaguo nyingi za usanidi katika programu yako. Au ni aina fulani tu ya muundo tata, kuna kiota.

Ikiwa una usanidi, basi unaweza kufundisha programu yako vizuri sana, kwa mfano, kufuatilia kiotomatiki mabadiliko katika faili ambapo usanidi umewekwa, na pia upakie upya programu yako kiotomatiki usanidi unapobadilika. Hii kwa ujumla itakuwa chaguo bora.

Tena, tayari nilizungumza juu ya hii - habari ya siri haiko kwenye usanidi, habari ya siri haiko katika anuwai, habari ya siri sio siri. Kutoka hapo, unganisha habari hii ya siri kwa diplomasia. Kawaida sisi huhifadhi maelezo yote ya vitu vya Kubernetes, uwekaji, usanidi, huduma kwenye git. Ipasavyo, kuweka nenosiri kwenye hifadhidata katika git, hata ikiwa ni git yako, ambayo unayo ndani ya kampuni, ni wazo mbaya. Kwa sababu, kwa kiwango cha chini, git inakumbuka kila kitu na kuondoa nywila kutoka hapo sio rahisi sana.

Uchunguzi wa afya

Jambo linalofuata ni hili linaloitwa Health check. Kwa ujumla, ukaguzi wa Afya ni kuangalia tu kwamba ombi lako linafanya kazi. Wakati huo huo, mara nyingi tunazungumza juu ya programu fulani za wavuti, ambazo, ipasavyo, kutoka kwa mtazamo wa ukaguzi wa afya (ni bora sio kutafsiri hapa na zaidi) hii itakuwa URL maalum, ambayo wanashughulikia kama. kiwango, wao kwa kawaida kufanya /health.

Wakati wa kufikia URL hii, ipasavyo, maombi yetu yanasema "ndiyo, sawa, kila kitu kiko sawa kwangu, 200" au "hapana, kila kitu si sawa kwangu, baadhi ya 500." Ipasavyo, ikiwa programu yetu sio http, sio programu ya wavuti, sasa tunazungumza juu ya aina fulani ya daemon, tunaweza kujua jinsi ya kufanya ukaguzi wa afya. Hiyo ni, sio lazima, ikiwa maombi sio http, basi kila kitu hufanya kazi bila hundi ya afya na hii haiwezi kufanywa kwa njia yoyote. Unaweza kusasisha mara kwa mara habari fulani kwenye faili, unaweza kuja na amri maalum ya daemon yako, kama, daemon status, ambayo itasema "ndio, kila kitu kiko sawa, daemon inafanya kazi, iko hai."

Ni ya nini? Jambo la kwanza na dhahiri zaidi labda ni kwa nini ukaguzi wa afya unahitajika - kuelewa kuwa programu inafanya kazi. Namaanisha, ni ujinga tu, wakati iko juu sasa, inaonekana kama inafanya kazi, kwa hivyo unaweza kuwa na uhakika kuwa inafanya kazi. Na ikawa kwamba programu inaendesha, chombo kinaendelea, mfano unafanya kazi, kila kitu kiko sawa - halafu watumiaji tayari wamekata nambari zote za simu kutoka kwa usaidizi wa kiufundi na kusema "wewe ni nini ..., wewe nililala, hakuna kinachofanya kazi."

Ukaguzi wa afya ni njia tu ya kuona kutoka kwa mtazamo wa mtumiaji kwamba inafanya kazi. Moja ya mbinu. Hebu tuweke hivi. Kutoka kwa mtazamo wa Kubernetes, hii pia ni njia ya kuelewa wakati programu inapoanza, kwa sababu tunaelewa kuwa kuna tofauti kati ya wakati chombo kilipozinduliwa, kuundwa na kuanza, na wakati programu ilizinduliwa moja kwa moja kwenye chombo hiki. Kwa sababu ikiwa tutachukua programu ya wastani ya java na kujaribu kuizindua kwenye kizimbani, basi kwa sekunde arobaini, au hata dakika, au hata kumi, inaweza kuanza vizuri. Katika kesi hii, unaweza kubisha angalau kwenye bandari zake, haitajibu hapo, yaani, bado haijawa tayari kupokea trafiki.

Tena, kwa msaada wa ukaguzi wa afya na kwa msaada wa ukweli kwamba tunageuka hapa, tunaweza kuelewa katika Kubernetes kwamba sio tu chombo kimeongezeka kwenye programu, lakini programu yenyewe imeanza, tayari inajibu. kuangalia afya, ambayo ina maana tunaweza kutuma trafiki huko.

Ninachozungumza sasa kinaitwa majaribio ya Utayari/Uhai ndani ya Kubernetes; ipasavyo, majaribio yetu ya utayari yanawajibika kwa kupatikana kwa programu katika kusawazisha. Hiyo ni, ikiwa vipimo vya utayari vinafanywa katika programu, basi kila kitu ni sawa, trafiki ya mteja inaenda kwenye programu. Ikiwa majaribio ya utayari hayafanyiki, basi programu haishiriki tu, mfano huu haushiriki katika kusawazisha, huondolewa kutoka kwa kusawazisha, trafiki ya mteja haitiririki. Ipasavyo, majaribio ya Liveness ndani ya Kubernetes yanahitajika ili ikiwa programu itakwama, iweze kuanzishwa upya. Ikiwa jaribio la uhai halifanyi kazi kwa programu ambayo imetangazwa katika Kubernetes, basi programu haiondolewi tu kwenye kusawazisha, inaanzishwa upya.

Na hapa kuna jambo muhimu ambalo ningependa kutaja: kutoka kwa mtazamo wa vitendo, mtihani wa utayari hutumiwa mara nyingi zaidi na unahitajika zaidi kuliko mtihani wa uhai. Hiyo ni, kutangaza bila kufikiria majaribio ya utayari na uchangamfu, kwa sababu Kubernetes inaweza kufanya hivyo, na tutumie kila kitu inachoweza kufanya, sio wazo zuri sana. Nitaeleza kwa nini. Kwa sababu hatua ya pili katika upimaji ni kwamba itakuwa ni wazo nzuri kuangalia huduma ya msingi katika ukaguzi wa afya yako. Hii ina maana kwamba ikiwa una programu ya wavuti ambayo inatoa taarifa fulani, ambayo kwa upande wake, kwa kawaida, lazima ichukue kutoka mahali fulani. Katika hifadhidata, kwa mfano. Kweli, inahifadhi habari inayokuja kwenye API hii ya REST kwenye hifadhidata sawa. Halafu, ipasavyo, ikiwa ukaguzi wako wa afya unajibu kama vile slashhealth uliyowasiliana nayo, programu inasema "200, sawa, kila kitu kiko sawa," na wakati huo huo hifadhidata ya programu yako haipatikani, na programu ya ukaguzi wa afya inasema "200, sawa, kila kitu ni sawa. ” - Huu ni uchunguzi mbaya wa afya. Hii sio jinsi inapaswa kufanya kazi.

Hiyo ni, maombi yako, wakati ombi linakuja kwake /health, haijibu tu, "200, sawa", kwanza huenda, kwa mfano, kwenye hifadhidata, inajaribu kuunganishwa nayo, hufanya jambo la msingi sana hapo, kama vile chagua moja, hukagua tu kuwa kuna muunganisho kwenye hifadhidata na unaweza kuuliza hifadhidata. Ikiwa haya yote yalifanikiwa, basi jibu ni "200, sawa." Ikiwa haijafanikiwa, inasema kwamba kuna kosa, hifadhidata haipatikani.

Kwa hivyo, katika suala hili, ninarudi tena kwenye majaribio ya Utayari / Uhai - kwa nini uwezekano mkubwa unahitaji mtihani wa utayari, lakini mtihani wa uhai unahojiwa. Kwa sababu ukielezea ukaguzi wa afya kama nilivyosema hivi punde, basi itabainika kuwa haipatikani katika sehemu ya mfanoв или со всех instancekatika hifadhidata, kwa mfano. Ulipotangaza mtihani wa utayari, ukaguzi wetu wa afya ulianza kushindwa, na ipasavyo maombi yote ambayo hifadhidata haipatikani, zimezimwa tu kutoka kwa kusawazisha na kwa kweli "hutegemea" tu katika hali iliyopuuzwa na kungojea hifadhidata zao. kazi.

Ikiwa tumetangaza jaribio la uhai, basi fikiria, hifadhidata yetu imeharibika, na katika Kubernetes yako nusu ya kila kitu inaanza upya kwa sababu jaribio la uhai halifaulu. Hii ina maana unahitaji kuanzisha upya. Hii sio kabisa unayotaka, hata nilikuwa na uzoefu wa kibinafsi katika mazoezi. Tulikuwa na programu ya gumzo ambayo iliandikwa kwa JS na kuingizwa kwenye hifadhidata ya Mongo. Na shida ilikuwa kwamba ilikuwa mwanzoni mwa kazi yangu na Kubernetes, tulielezea utayari, uhai wa vipimo kwa kanuni ambayo Kubernetes inaweza kuifanya, kwa hiyo tutaitumia. Ipasavyo, wakati fulani Mongo akawa "mwepesi" kidogo na sampuli ilianza kushindwa. Ipasavyo, kulingana na mtihani wa mvua, maganda yalianza "kuua".

Kama unavyoelewa, wakati "wameuawa", hii ni gumzo, ambayo ni, kuna miunganisho mingi kutoka kwa wateja inayoning'inia juu yake. Pia "wameuawa" - hapana, sio wateja, miunganisho tu - sio wote kwa wakati mmoja, na kwa sababu ya ukweli kwamba hawakuuawa kwa wakati mmoja, wengine mapema, wengine baadaye, hawaanzi sawa. wakati. Pamoja na nasibu ya kawaida, hatuwezi kutabiri kwa usahihi wa milisekunde wakati wa kuanza kwa programu kila wakati, kwa hivyo wanafanya tukio moja baada ya nyingine. Infospot moja huinuka, huongezwa kwa kusawazisha, wateja wote wanakuja huko, hawawezi kuhimili mzigo kama huo, kwa sababu iko peke yake, na, kwa kusema, kuna dazeni kati yao wanaofanya kazi huko, na huanguka. Anayefuata huinuka, mzigo wote uko juu yake, pia huanguka. Kweli, maporomoko haya yanaendelea kushuka. Mwishowe, jinsi hili lilivyotatuliwa - ilitubidi tu kusimamisha trafiki ya watumiaji kwa programu hii, wacha hali zote ziinuke na kuanza trafiki yote ya watumiaji mara moja ili iwe tayari kusambazwa kati ya matukio yote kumi.

Kama si jaribio hili la uhai lingetangazwa, ambalo lingelazimisha kuanza upya, programu tumizi ingeshughulikia vyema. Lakini kila kitu kutoka kwa kusawazisha kimezimwa kwa ajili yetu, kwa sababu hifadhidata hazipatikani na watumiaji wote "wameanguka". Kisha, wakati database hii inapatikana, kila kitu kinajumuishwa katika kusawazisha, lakini programu hazihitaji kuanza tena, na hakuna haja ya kupoteza muda na rasilimali juu ya hili. Wote tayari wako hapa, wako tayari kwa trafiki, hivyo trafiki inafungua tu, kila kitu ni sawa - maombi iko, kila kitu kinaendelea kufanya kazi.

Kwa hiyo, vipimo vya utayari na uhai ni tofauti, hata zaidi ya hayo, unaweza kinadharia kufanya ukaguzi tofauti wa afya, aina moja ya radii, aina moja ya liv, kwa mfano, na kuangalia mambo tofauti. Wakati wa majaribio ya utayari, angalia sehemu zako za nyuma. Na kwenye jaribio la uhai, kwa mfano, hutaangalia kutoka kwa mtazamo kwamba jaribio la uhai kwa ujumla ni kujibu maombi, ikiwa linaweza kujibu kabisa.

Kwa sababu mtihani wa uhai, kwa ujumla, ni wakati "tunakwama." Kitanzi kisichoisha kimeanza au kitu kingine - na hakuna maombi zaidi yanayochakatwa. Kwa hiyo, ni mantiki hata kuwatenganisha - na kutekeleza mantiki tofauti ndani yao.

Kuhusu kile unachohitaji kujibu unapopima, unapofanya ukaguzi wa afya. Ni maumivu tu kweli. Wale wanaofahamu hili labda watacheka - lakini kwa umakini, nimeona huduma katika maisha yangu ambazo zinajibu "200" katika XNUMX% ya kesi. Hiyo ni, ni nani aliyefanikiwa. Lakini wakati huo huo katika mwili wa majibu wanaandika "kosa kama hilo na kama hilo."

Hiyo ni, hali ya majibu inakuja kwako - kila kitu kinafanikiwa. Lakini wakati huo huo, lazima uchanganue mwili, kwa sababu mwili unasema "samahani, ombi lilimalizika na kosa" na hii ni ukweli tu. Niliona hii katika maisha halisi.

Na ili watu wengine wasione kuwa ni funny, na wengine wanaona kuwa chungu sana, bado ni thamani ya kuzingatia sheria rahisi. Katika ukaguzi wa afya, na kimsingi wakati wa kufanya kazi na programu za wavuti.

Ikiwa kila kitu kilikwenda vizuri, basi jibu kwa jibu la mia mbili. Kimsingi, jibu lolote la mia mbili litakufaa. Ikiwa unasoma ragsy vizuri sana na unajua kuwa hali zingine za majibu ni tofauti na zingine, jibu na zinazofaa: 204, 5, 10, 15, chochote. Ikiwa sio nzuri sana, basi "sifuri mbili" tu. Ikiwa kila kitu kinakwenda vibaya na hundi ya afya haijibu, basi jibu kwa mia tano yoyote. Tena, ikiwa unaelewa jinsi ya kujibu, jinsi hali tofauti za majibu zinavyotofautiana. Ikiwa huelewi, basi 502 ni chaguo lako la kujibu ukaguzi wa afya ikiwa kitu kitaenda vibaya.

Hili ni jambo lingine, nataka kurejea kidogo kuhusu kuangalia huduma za msingi. Ukianza, kwa mfano, kuangalia huduma zote za msingi ambazo zinasimama nyuma ya programu yako - kila kitu kwa ujumla. Tunachopata kutoka kwa mtazamo wa usanifu wa huduma ndogo, tuna wazo kama "uunganisho wa chini" - ambayo ni, wakati huduma zako zinategemeana kidogo. Ikiwa mmoja wao atashindwa, wengine wote bila utendakazi huu wataendelea kufanya kazi. Baadhi ya utendakazi haufanyi kazi. Ipasavyo, ukifunga vipimo vyote vya afya kwa kila mmoja, basi utaishia na kitu kimoja kuanguka kwenye miundombinu, na kwa sababu ilianguka, vipimo vyote vya afya vya huduma zote pia huanza kuharibika - na kuna miundombinu zaidi kwa ujumla kwa usanifu mzima wa huduma ndogo No. Kila kitu kilikuwa giza hapo.

Kwa hiyo, nataka kurudia hili tena kwamba unahitaji kuangalia huduma za msingi, wale bila ambayo maombi yako katika asilimia mia moja ya kesi haiwezi kufanya kazi yake. Hiyo ni, ni mantiki kwamba ikiwa una API ya REST ambayo mtumiaji huhifadhi kwenye hifadhidata au kupata kutoka kwa hifadhidata, basi kwa kukosekana kwa hifadhidata, huwezi kuhakikisha kazi na watumiaji wako.

Lakini ikiwa watumiaji wako, unapowatoa kwenye hifadhidata, wameboreshwa zaidi na metadata nyingine, kutoka kwa sehemu nyingine ya nyuma, ambayo unaingiza kabla ya kutuma jibu kwa sehemu ya mbele - na hali hii ya nyuma haipatikani, hii inamaanisha kuwa unatoa yako. jibu bila sehemu yoyote ya metadata.

Ifuatayo, pia tunayo moja ya maswala chungu wakati wa kuzindua programu.

Kwa kweli, hii haitumiki tu kwa Kubernetes kwa ujumla; ilifanyika tu kwamba utamaduni wa aina fulani ya maendeleo ya watu wengi na DevOps haswa ilianza kuenea wakati huo huo kama Kubernetes. Kwa hivyo, kwa ujumla, zinageuka kuwa unahitaji kuzima programu yako bila Kubernetes. Hata kabla ya Kubernetes, watu walifanya hivi, lakini kwa ujio wa Kubernetes, tulianza kuzungumza juu yake kwa wingi.

Kuzima kwa Neema

Kwa ujumla, Kuzima kwa Neema ni nini na kwa nini inahitajika? Hii ni kuhusu wakati programu yako inapoacha kufanya kazi kwa sababu fulani, unahitaji kufanya hivyo app stop - au unapokea, kwa mfano, ishara kutoka kwa mfumo wa uendeshaji, maombi yako lazima yaelewe na kufanya kitu kuhusu hilo. Hali mbaya zaidi, bila shaka, ni wakati ombi lako linapokea SIGTERM na ni kama "SIGTERM, tusubiri, tufanye kazi, tusifanye lolote." Hili ni chaguo mbaya kabisa.

Chaguo mbaya zaidi ni wakati ombi lako linapokea SIGTERM na ni kama "walisema segterm, hiyo inamaanisha tunamaliza, sijaona, sijui maombi yoyote ya mtumiaji, sijui ni aina gani ya maombi ninayoyafanyia kazi hivi sasa, walisema SIGTERM, hiyo inamaanisha tunamaliza " Hii pia ni chaguo mbaya.

Chaguo gani ni nzuri? Jambo la kwanza ni kuzingatia kukamilika kwa shughuli. Chaguo nzuri ni kwa seva yako bado kuzingatia kile inachofanya ikiwa inapokea SIGTERM.

SIGTERM ni kuzima laini, imeundwa mahsusi, inaweza kuingiliwa kwa kiwango cha kificho, inaweza kusindika, sema kwamba sasa, subiri, tutamaliza kwanza kazi ambayo tunayo, kisha tutatoka.

Kwa mtazamo wa Kubernetes, hii ndio inaonekana. Tunaposema kwa ganda linaloendesha kwenye nguzo ya Kubernetes, "tafadhali sima, nenda mbali," au tunawashwa upya, au sasisho hutokea wakati Kubernetes inaunda upya maganda, Kubernetes hutuma ujumbe ule ule wa SIGTERM kwenye ganda, na kusubiri. muda fulani, na , huu ndio wakati ambao anangoja, pia umesanidiwa, kuna parameta maalum katika diploma na inaitwa Graceful ShutdownTimeout. Kama unavyoelewa, haijaitwa bure, na sio bure kwamba tunazungumza juu yake sasa.

Hapo tunaweza kusema haswa ni muda gani tunahitaji kungoja kati ya wakati tunatuma SIGTERM kwa programu na tunapoelewa kuwa programu inaonekana kuwa imeenda wazimu kwa kitu au "imekwama" na haitaisha - na tunahitaji itume SIGKILL, yaani, kamilisha kazi yake kwa bidii. Hiyo ni, ipasavyo, tuna aina fulani ya daemon inayoendesha, inachakata shughuli. Tunaelewa kuwa kwa wastani shughuli zetu ambazo daemoni hufanya kazi hazidumu zaidi ya sekunde 30 kwa wakati mmoja. Kwa hivyo, SIGTERM inapowasili, tunaelewa kuwa daemon yetu inaweza, hata zaidi, kumaliza sekunde 30 baada ya SIGTERM. Tunaandika, kwa mfano, sekunde 45 ikiwa tu na kusema kwamba SIGTERM. Baada ya hayo, tunasubiri sekunde 45. Kwa nadharia, wakati huu pepo alipaswa kumaliza kazi yake na kujimaliza. Lakini ikiwa haikuweza ghafla, inamaanisha kuwa ina uwezekano mkubwa wa kukwama-haishughulikii maombi yetu kama kawaida. Na katika sekunde 45 unaweza salama, kwa kweli, kumtia msumari chini.

Na hapa, kwa kweli, hata vipengele 2 vinaweza kuzingatiwa. Kwanza, kuelewa kwamba ikiwa ulipokea ombi, ulianza kufanya kazi nayo kwa namna fulani na haukutoa jibu kwa mtumiaji, lakini ulipokea SIGTERM, kwa mfano. Inaleta maana kuiboresha na kutoa jibu kwa mtumiaji. Hii ni hatua ya kwanza katika suala hili. Hoja ya pili hapa ni kwamba ikiwa utaandika programu yako mwenyewe, kwa ujumla jenga usanifu kwa njia ambayo unapokea ombi la programu yako, kisha unaanza kazi fulani, anza kupakua faili kutoka mahali pengine, kupakua hifadhidata, na nini. Hiyo. Kwa ujumla, mtumiaji wako, ombi lako hutegemea kwa nusu saa na anasubiri wewe kumjibu - basi, uwezekano mkubwa, unahitaji kufanya kazi kwenye usanifu. Hiyo ni, tu kuzingatia hata akili ya kawaida kwamba kama shughuli zako ni fupi, basi ni mantiki kupuuza SIGTERM na kurekebisha. Ikiwa shughuli zako ni ndefu, basi haina maana kupuuza SIGTERM katika kesi hii. Ni mantiki kuunda upya usanifu ili kuzuia shughuli za muda mrefu. Ili watumiaji wasiingie tu na kusubiri. Sijui, tengeneza aina fulani ya soketi hapo, tengeneza ndoano za nyuma ambazo seva yako tayari itatuma kwa mteja, kitu kingine chochote, lakini usilazimishe mtumiaji kunyongwa kwa nusu saa na subiri kikao hadi utakapomaliza. mjibu. Kwa sababu haitabiriki ni wapi inaweza kuvunjika.

Wakati maombi yako yatakamilika, unapaswa kutoa msimbo unaofaa wa kutoka. Hiyo ni, ikiwa programu yako iliulizwa kufunga, kuacha, na iliweza kujizuia kwa kawaida, basi huna haja ya kurudisha aina fulani ya msimbo wa kutoka 1,5,255 na kadhalika. Kitu chochote ambacho sio msimbo wa sifuri, angalau katika mifumo ya Linux, nina hakika ya hii, inachukuliwa kuwa haijafanikiwa. Hiyo ni, inachukuliwa kuwa maombi yako katika kesi hii yalimalizika na hitilafu. Ipasavyo, kwa njia ya kupendeza, ikiwa programu yako imekamilika bila kosa, unasema 0 kwenye pato. Ikiwa programu yako itashindwa kwa sababu fulani, unasema isiyo ya 0 kwenye pato. Na unaweza kufanya kazi na habari hii.

Na chaguo la mwisho. Ni mbaya mtumiaji wako anapotuma ombi na kuning'inia kwa nusu saa huku ukilichakata. Lakini kwa ujumla, ningependa pia kusema juu ya kile kinachofaa kwa ujumla kutoka kwa upande wa mteja. Haijalishi ikiwa una programu ya rununu, mwisho wa mbele, nk. Ni muhimu kuzingatia kwamba kwa ujumla kikao cha mtumiaji kinaweza kusitishwa, chochote kinaweza kutokea. Ombi linaweza kutumwa, kwa mfano, kuchakatwa na hakuna jibu lililorejeshwa. Sehemu yako ya mbele au programu yako ya simu - sehemu yoyote ya mbele kwa ujumla, tuiweke hivyo - inapaswa kuzingatia hili. Ikiwa unafanya kazi na soketi za wavuti, kwa ujumla haya ndio maumivu mabaya zaidi ambayo nimewahi kuwa nayo.

Wakati watengenezaji wa baadhi ya mazungumzo ya kawaida hawajui kwamba, zinageuka, websocket inaweza kuvunja. Kwao, kitu kinapotokea kwa wakala, tunabadilisha tu usanidi, na hupakia tena. Kwa kawaida, vikao vyote vya muda mrefu vimevunjwa katika kesi hii. Wasanidi programu hutujia mbio na kusema: "Jamani, mnafanya nini, gumzo limevunjika kwa wateja wetu wote!" Tunawaambia: “Mnafanya nini? Je, wateja wako hawawezi kuunganisha tena? Wanasema: "Hapana, tunahitaji vikao visivunjwe." Kwa kifupi, huu ni ujinga. Upande wa mteja unahitaji kuzingatiwa. Hasa, kama ninavyosema, na vikao vya muda mrefu kama vile soketi za wavuti, inaweza kuvunjika na, bila kutambuliwa na mtumiaji, unahitaji kuweza kuweka tena vipindi kama hivyo. Na kisha kila kitu ni kamilifu.

Rasilimali

Kwa kweli, hapa nitakuambia hadithi moja kwa moja. Tena kutoka kwa maisha halisi. Kitu mgonjwa sana nimewahi kusikia kuhusu rasilimali.

Rasilimali katika kesi hii, ninamaanisha, aina fulani ya maombi, mipaka ambayo unaweza kuweka kwenye maganda katika makundi yako ya Kubernetes. Jambo la kuchekesha zaidi nililosikia kutoka kwa msanidi... Mmoja wa watengenezaji wenzangu katika sehemu ya awali ya kazi aliwahi kusema: "Maombi yangu hayataanza kwenye kundi." Niliangalia kuona kwamba haikuwa kuanzia, lakini ama haikuingia kwenye rasilimali, au walikuwa wameweka mipaka ndogo sana. Kwa kifupi, programu haiwezi kuanza kutokana na rasilimali. Ninasema: "Haitaanza kutokana na rasilimali, unaamua ni kiasi gani unahitaji na kuweka thamani ya kutosha." Anasema: "Ni rasilimali gani?" Nilianza kumweleza kuwa Kubernetes, mipaka ya maombi na blah, blah, blah inahitaji kuwekwa. Mwanamume huyo alisikiliza kwa dakika tano, akaitikia kwa kichwa na kusema: "Nilikuja hapa kufanya kazi kama msanidi programu, sitaki kujua chochote kuhusu rasilimali yoyote. Nilikuja hapa kuandika nambari na ndivyo hivyo." Inasikitisha. Hili ni wazo la kusikitisha sana kutoka kwa mtazamo wa msanidi programu. Hasa katika ulimwengu wa kisasa, kwa kusema, wa devops zinazoendelea.

Kwa nini rasilimali zinahitajika kabisa? Kuna aina 2 za rasilimali katika Kubernetes. Baadhi huitwa maombi, wengine huitwa mipaka. Kwa rasilimali tutaelewa kwamba kimsingi daima kuna vikwazo viwili tu vya msingi. Hiyo ni, vikomo vya muda vya CPU na vikomo vya RAM kwa kontena inayoendesha Kubernetes.

Kikomo kinaweka kikomo cha juu cha jinsi rasilimali inaweza kutumika katika programu yako. Hiyo ni, ipasavyo, ikiwa unasema 1GB ya RAM katika mipaka, basi programu yako haitaweza kutumia zaidi ya 1GB ya RAM. Na ikiwa ghafla anataka na kujaribu kufanya hivyo, basi mchakato unaoitwa oom killer, nje ya kumbukumbu, yaani, utakuja na kuua maombi yako - yaani, itaanza upya. Programu hazitaanza upya kulingana na CPU. Kwa upande wa CPU, ikiwa programu itajaribu kutumia sana, zaidi ya ilivyoainishwa katika mipaka, CPU itachaguliwa kwa ukali. Hii haiongoi kwa kuanza tena. Hii ni kikomo - hii ni kikomo cha juu.

Na kuna ombi. Ombi ni jinsi Kubernetes inaelewa jinsi nodi katika kundi lako la Kubernetes zinavyojazwa na programu. Hiyo ni, ombi ni aina ya ahadi ya maombi yako. Inasema kile ninachotaka kutumia: "Ningependa unihifadhie CPU nyingi na kumbukumbu hii." Ulinganisho rahisi kama huo. Nini ikiwa tuna nodi ambayo ina, sijui, CPU 8 kwa jumla. Na ganda linafika hapo, ambalo maombi yake yanasema 1 CPU, ambayo inamaanisha kuwa nodi ina CPU 7 zilizobaki. Hiyo ni, ipasavyo, mara tu maganda 8 yanapofika kwenye nodi hii, ambayo kila moja ina CPU 1 katika ombi lao, nodi, kana kwamba kutoka kwa mtazamo wa Kubernetes, imeisha kwa CPU na maganda zaidi na maombi hayawezi kutolewa. ilizinduliwa kwenye nodi hii. Ikiwa nodi zote zitaisha kwa CPU, basi Kubernetes itaanza kusema kwamba hakuna nodi zinazofaa kwenye nguzo za kuendesha maganda yako kwa sababu CPU imeisha.

Kwa nini maombi yanahitajika na kwa nini bila maombi, nadhani hakuna haja ya kuzindua chochote katika Kubernetes? Hebu fikiria hali ya dhahania. Unazindua programu yako bila maombi, Kubernetes hajui ni kiasi gani cha kile ulicho nacho, ni nodi gani unaweza kuisukuma. Naam, anasukuma, anasukuma, anapiga kwenye nodes. Wakati fulani, utaanza kupata trafiki kwa programu yako. Na moja ya maombi ghafla huanza kutumia rasilimali hadi mipaka ambayo ina kulingana na mipaka. Inageuka kuwa kuna programu nyingine karibu na inahitaji rasilimali. Nodi huanza kuishiwa na rasilimali, kwa mfano, OP. Nodi huanza kuishiwa na rasilimali, kwa mfano, kumbukumbu ya ufikiaji bila mpangilio (RAM). Wakati node inapoisha nguvu, kwanza kabisa docker itaacha kujibu, kisha cubelet, kisha OS. Watapoteza fahamu na kila kitu hakika kitaacha kufanya kazi kwa ajili yako. Hiyo ni, hii itasababisha nodi yako kukwama na utahitaji kuianzisha tena. Kwa kifupi, hali si nzuri sana.

Na unapokuwa na maombi, mipaka sio tofauti sana, angalau sio mara nyingi zaidi ya mipaka au maombi, basi unaweza kuwa na ujazo wa kawaida, wa busara wa maombi kwenye nodi za nguzo za Kubernetes. Wakati huo huo, Kubernetes anafahamu takriban ni kiasi gani inaweka wapi, ni kiasi gani cha kile kinachotumiwa mahali. Hiyo ni, ni wakati kama huo. Ni muhimu kuielewa. Na ni muhimu kudhibiti kwamba hii imeonyeshwa.

Uhifadhi wa data

Hoja yetu inayofuata ni juu ya uhifadhi wa data. Nini cha kufanya nao na kwa ujumla, nini cha kufanya na kuendelea katika Kubernetes?

Nadhani, tena, ndani yetu Shule ya jioni, kulikuwa na mada kuhusu hifadhidata katika Kubernetes. Na inaonekana kwangu kuwa ninajua hata kile wenzako walikuambia walipoulizwa: "Inawezekana kuendesha hifadhidata huko Kubernetes?" Kwa sababu fulani, inaonekana kwangu kwamba wenzako walipaswa kukuambia kwamba ikiwa unauliza swali ikiwa inawezekana kuendesha hifadhidata huko Kubernetes, basi haiwezekani.

Mantiki hapa ni rahisi. Ikiwezekana, nitaelezea kwa mara nyingine tena, ikiwa wewe ni mtu mzuri sana ambaye unaweza kuunda mfumo unaostahimili makosa wa uhifadhi wa mtandao uliosambazwa, elewa jinsi ya kutoshea hifadhidata katika kesi hii, jinsi wingu asili kwenye vyombo linapaswa kufanya kazi. katika hifadhidata kwa ujumla. Uwezekano mkubwa zaidi, huna swali kuhusu jinsi ya kuiendesha. Ikiwa una swali kama hilo, na unataka kuhakikisha kuwa yote yanajitokeza na inasimama sawa na kifo katika uzalishaji na kamwe haianguka, basi hii haifanyiki. Umehakikishiwa kujipiga risasi kwenye mguu kwa njia hii. Kwa hivyo ni bora sio.

Je, tunapaswa kufanya nini na data ambayo programu yetu ingependa kuhifadhi, baadhi ya picha ambazo watumiaji hupakia, baadhi ya mambo ambayo programu yetu hutoa wakati wa uendeshaji wake, kwa mfano, inapowashwa? Nini cha kufanya nao huko Kubernetes?

Kwa ujumla, kwa hakika, ndiyo, bila shaka, Kubernetes imeundwa vizuri sana na kwa ujumla iliundwa kwa ajili ya maombi yasiyo na uraia. Hiyo ni, kwa programu hizo ambazo hazihifadhi habari kabisa. Hii ni bora.

Lakini, bila shaka, chaguo bora haipo daima. Kwa hiyo? Jambo la kwanza na rahisi ni kuchukua aina fulani ya S3, sio tu iliyofanywa nyumbani, ambayo pia haijulikani jinsi inavyofanya kazi, lakini kutoka kwa mtoa huduma fulani. Mtoa huduma mzuri, wa kawaida - na ufundishe programu yako kutumia S3. Hiyo ni, mtumiaji wako anapotaka kupakia faili, sema "hapa, tafadhali, pakia kwenye S3." Anapotaka kuipokea, sema: "Hiki hapa ni kiungo cha kurudisha S3 na ukichukue kutoka hapa." Hii ni bora.

Ikiwa ghafla kwa sababu fulani chaguo hili bora haifai, una programu ambayo haukuandika, haukuza, au ni aina fulani ya urithi mbaya, haiwezi kutumia itifaki ya S3, lakini lazima ifanye kazi na saraka za ndani. folda za ndani. Chukua kitu rahisi zaidi au kidogo, tumia Kubernetes. Hiyo ni, kuifunga Ceph mara moja kwa kazi ndogo, inaonekana kwangu, ni wazo mbaya. Kwa sababu Ceph, bila shaka, ni nzuri na ya mtindo. Lakini ikiwa huelewi unachofanya, basi mara tu unapoweka kitu kwenye Ceph, unaweza kwa urahisi sana na usiwahi kukiondoa hapo tena. Kwa sababu, kama unavyojua, Ceph huhifadhi data katika nguzo yake katika fomu ya binary, na si katika mfumo wa faili rahisi. Kwa hiyo, ikiwa ghafla nguzo ya Ceph itavunjika, basi kuna uwezekano kamili na mkubwa kwamba huwezi kupata data yako kutoka huko tena.

Tutakuwa na kozi ya Ceph, unaweza jitambue na programu na utume maombi.

Kwa hivyo, ni bora kufanya kitu rahisi kama seva ya NFS. Kubernetes inaweza kufanya kazi nao, unaweza kuweka saraka chini ya seva ya NFS - programu yako ni kama saraka ya ndani. Wakati huo huo, kwa kawaida, unahitaji kuelewa kwamba, tena, unahitaji kufanya kitu na NFS yako, unahitaji kuelewa kwamba wakati mwingine inaweza kuwa haipatikani na kuzingatia swali la nini utafanya katika kesi hii. Labda inapaswa kuungwa mkono mahali fulani kwenye mashine tofauti.

Hoja inayofuata niliyozungumza ni nini cha kufanya ikiwa programu yako hutoa faili kadhaa wakati wa operesheni. Kwa mfano, inapoanza, hutoa faili fulani tuli, ambayo inategemea habari fulani ambayo programu hupokea tu wakati wa uzinduzi. Muda gani. Ikiwa hakuna data nyingi kama hizo, basi sio lazima kujisumbua hata kidogo, jisakinishe programu hii na ufanye kazi. Swali pekee hapa ni nini, angalia. Mara nyingi sana, kila aina ya mifumo ya urithi, kama vile WordPress na kadhalika, haswa na aina fulani ya programu jalizi zilizobadilishwa, watengenezaji wajanja wa PHP, mara nyingi wanajua jinsi ya kuifanya ili wajitengenezee aina fulani ya faili. Ipasavyo, mtu hutoa faili moja, ya pili hutoa faili ya pili. Wao ni tofauti. Kusawazisha hufanyika katika kundi la wateja la Kubernetes kwa bahati tu. Ipasavyo, zinageuka kuwa hawajui jinsi ya kufanya kazi pamoja kwa mfano. Mmoja hutoa habari moja, mwingine humpa mtumiaji habari nyingine. Hili ni jambo ambalo unapaswa kuepuka. Hiyo ni, katika Kubernetes, kila kitu unachozindua kimehakikishiwa kuwa na uwezo wa kufanya kazi katika matukio mengi. Kwa sababu Kubernetes ni jambo la kusonga mbele. Ipasavyo, anaweza kusonga chochote, wakati wowote anataka, bila kuuliza mtu yeyote. Kwa hiyo, unahitaji kuhesabu hii. Kila kitu kilichozinduliwa kwa mfano mmoja kitashindwa mapema au baadaye. Kadiri unavyohifadhi nafasi zaidi, ndivyo inavyokuwa bora zaidi. Lakini tena, nasema, ikiwa una faili chache kama hizo, basi unaweza kuziweka chini yako, zina uzito mdogo. Ikiwa kuna kidogo zaidi yao, labda hupaswi kusukuma ndani ya chombo.

Ningeshauri kwamba kuna jambo la ajabu sana katika Kubernetes, unaweza kutumia kiasi. Hasa, kuna kiasi cha aina tupu dir. Hiyo ni, ni kwamba Kubernetes itaunda kiotomati saraka katika saraka zake za huduma kwenye seva ambayo ulianza. Naye atakupa ili uweze kuitumia. Kuna jambo moja tu muhimu. Hiyo ni, data yako haitahifadhiwa ndani ya kontena, lakini kwa seva pangishi ambayo unaendesha. Kwa kuongezea, Kubernetes inaweza kudhibiti dirs tupu kama hizo chini ya usanidi wa kawaida na ina uwezo wa kudhibiti saizi yao ya juu na hairuhusu kuzidi. Jambo pekee ni kwamba kile ulichoandika kwenye dir tupu hakipotei wakati wa kuanza tena kwa pod. Hiyo ni, ikiwa pod yako itaanguka kwa makosa na kuinuka tena, habari katika dir tupu haitakwenda popote. Anaweza kuitumia tena katika mwanzo mpya - na hiyo ni nzuri. Ikiwa pod yako itaondoka mahali fulani, basi kwa kawaida ataondoka bila data. Hiyo ni, mara tu ganda kutoka kwa node ambapo ilizinduliwa na dir tupu kutoweka, dir tupu inafutwa.

Nini kingine ni nzuri kuhusu dir tupu? Kwa mfano, inaweza kutumika kama cache. Wacha tufikirie kuwa programu yetu hutoa kitu kwa kuruka, huwapa watumiaji, na kuifanya kwa muda mrefu. Kwa hiyo, maombi, kwa mfano, huzalisha na kuwapa watumiaji, na wakati huo huo huihifadhi mahali fulani, ili wakati ujao mtumiaji anakuja kwa kitu kimoja, itakuwa haraka kutoa mara moja kuzalishwa. Dir tupu inaweza kuulizwa Kubernetes kuunda katika kumbukumbu. Na kwa hivyo, kache zako zinaweza kufanya kazi kwa kasi ya umeme - kwa suala la kasi ya ufikiaji wa diski. Hiyo ni, una kumbukumbu tupu, kwenye OS imehifadhiwa kwenye kumbukumbu, lakini kwako, kwa mtumiaji ndani ya pod, inaonekana kama saraka ya ndani tu. Huhitaji programu kufundisha uchawi wowote mahususi. Unachukua tu moja kwa moja na kuweka faili yako kwenye saraka, lakini, kwa kweli, kwenye kumbukumbu kwenye OS. Hii pia ni kipengele rahisi sana katika suala la Kubernetes.

Je, Minio ana matatizo gani? Tatizo kuu la Minio ni kwamba ili jambo hili lifanye kazi, linahitaji kukimbia mahali fulani, na kuna lazima iwe na aina fulani ya mfumo wa faili, yaani, kuhifadhi. Na hapa tunakutana na matatizo yale yale ambayo Ceph anayo. Hiyo ni, Minio lazima ihifadhi faili zake mahali fulani. Ni kiolesura cha HTTP kwa faili zako. Kwa kuongezea, utendakazi ni duni zaidi kuliko ule wa S3 ya Amazon. Hapo awali, haikuweza kuidhinisha mtumiaji ipasavyo. Sasa, kwa kadiri ninavyojua, inaweza tayari kuunda ndoo na vibali tofauti, lakini tena, inaonekana kwangu kuwa tatizo kuu ni, kwa kusema, mfumo wa hifadhi ya msingi kwa kiwango cha chini.

Je, Empty dir kwenye kumbukumbu inaathiri vipi mipaka? Haiathiri mipaka kwa njia yoyote. Iko kwenye kumbukumbu ya mwenyeji, na sio kwenye kumbukumbu ya chombo chako. Hiyo ni, chombo chako hakioni dir tupu katika kumbukumbu kama sehemu ya kumbukumbu yake iliyochukuliwa. Mwenyeji anaona hili. Ipasavyo, ndio, kutoka kwa mtazamo wa kubernetes, unapoanza kutumia hii, itakuwa vizuri kuelewa kuwa unatoa sehemu ya kumbukumbu yako kwa dir tupu. Na ipasavyo, kuelewa kwamba kumbukumbu inaweza kuisha si tu kwa sababu ya maombi, lakini pia kwa sababu mtu anaandika kwa dirs hizi tupu.

Uwepo wa mawingu

Na mada ndogo ya mwisho ni nini Cloudnative ni. Kwa nini inahitajika? Cloudnativeness na kadhalika.

Hiyo ni, maombi hayo ambayo yana uwezo na yaliyoandikwa ili kufanya kazi katika miundombinu ya kisasa ya wingu. Lakini, kwa kweli, Cloudnative ina kipengele kingine kama hicho. Kwamba hii sio tu maombi ambayo inazingatia mahitaji yote ya miundombinu ya kisasa ya wingu, lakini pia anajua jinsi ya kufanya kazi na miundombinu hii ya kisasa ya wingu, kuchukua faida ya faida na hasara za ukweli kwamba inafanya kazi katika mawingu haya. Usiingie tu na kufanya kazi katika mawingu, lakini pata faida za kufanya kazi katika wingu.

Wacha tuchukue Kubernetes kama mfano. Ombi lako linaendeshwa katika Kubernetes. Ombi lako linaweza, au tuseme wasimamizi wa ombi lako, wanaweza kuunda akaunti ya huduma kila wakati. Hiyo ni, akaunti ya idhini katika Kubernetes yenyewe kwenye seva yake. Ongeza baadhi ya haki tunazohitaji hapo. Na unaweza kufikia Kubernetes kutoka ndani ya programu yako. Unaweza kufanya nini kwa njia hii? Kwa mfano, kutoka kwa programu, pokea data kuhusu mahali ambapo programu zako nyingine, matukio mengine yanayofanana yanapatikana, na pamoja kwa namna fulani nguzo juu ya Kubernetes, ikiwa kuna hitaji kama hilo.

Tena, tulikuwa na kesi hivi majuzi. Tuna mtawala mmoja anayefuatilia foleni. Na wakati baadhi ya majukumu mapya yanapoonekana kwenye foleni hii, huenda kwa Kubernetes - na ndani ya Kubernetes inaunda ganda jipya. Hutoa ganda hili kazi mpya na ndani ya mfumo wa ganda hili, ganda hufanya kazi, hutuma jibu kwa kidhibiti yenyewe, na mtawala kisha hufanya kitu na habari hii. Kwa mfano, inaongeza hifadhidata. Hiyo ni, tena, hii ni nyongeza ya ukweli kwamba maombi yetu yanaendeshwa katika Kubernetes. Tunaweza kutumia utendaji wa Kubernetes uliojengewa ndani yenyewe ili kupanua na kufanya utendakazi wa programu yetu iwe rahisi zaidi. Hiyo ni, usifiche aina fulani ya uchawi kuhusu jinsi ya kuzindua programu, jinsi ya kuzindua mfanyakazi. Katika Kubernetes, unatuma tu ombi katika programu ikiwa programu imeandikwa kwa Python.

Hali hiyo hiyo inatumika ikiwa tutavuka Kubernetes. Tuna Kubernetes zetu zinazoendesha mahali fulani - ni vizuri ikiwa iko katika aina fulani ya wingu. Tena, tunaweza kutumia, na hata tunapaswa, naamini, kutumia uwezo wa wingu yenyewe ambapo tunaendesha. Kutoka kwa mambo ya msingi ambayo wingu hutupatia. Kusawazisha, yaani, tunaweza kuunda mizani ya wingu na kuitumia. Hii ni faida ya moja kwa moja ya kile tunaweza kutumia. Kwa sababu kusawazisha kwa wingu, kwanza, kwa ujinga hutuondoa wajibu kwa jinsi inavyofanya kazi, jinsi inavyosanidiwa. Zaidi ni rahisi sana, kwa sababu Kubernetes ya kawaida inaweza kuunganisha na mawingu.

Vile vile huenda kwa kuongeza. Kubernetes ya kawaida inaweza kuunganishwa na watoa huduma za wingu. Anajua jinsi ya kuelewa kuwa ikiwa nguzo itaisha kwa nodi, ambayo ni, nafasi ya nodi imeisha, basi unahitaji kuongeza - Kubernetes yenyewe itaongeza nodi mpya kwenye nguzo yako na kuanza kuzindua maganda juu yao. Hiyo ni, wakati mzigo wako unakuja, idadi ya makaa huanza kuongezeka. Wakati nodi kwenye nguzo zinapoisha kwa maganda haya, Kubernetes huzindua nodi mpya na, ipasavyo, idadi ya maganda bado inaweza kuongezeka. Na ni rahisi sana. Hii ni fursa ya moja kwa moja ya kuongeza nguzo kwenye kuruka. Sio haraka sana, kwa maana kwamba sio sekunde, ni kama dakika ili kuongeza nodi mpya.

Lakini kutokana na uzoefu wangu, tena, ni jambo la baridi zaidi ambalo nimewahi kuona. Wakati nguzo ya Cloudnative iliongezeka kulingana na wakati wa siku. Ilikuwa huduma ya nyuma ambayo ilitumiwa na watu katika ofisi ya nyuma. Hiyo ni, wanakuja kufanya kazi saa 9 asubuhi, kuanza kuingia kwenye mfumo, na ipasavyo, nguzo ya Cloudnative, ambako yote inaendesha, huanza kuvimba, kuzindua pods mpya ili kila mtu anayekuja kufanya kazi afanye kazi na maombi. Wanapoondoka kazini saa 8 mchana au 6 jioni, vikundi vya Kubernetes hugundua kuwa hakuna mtu anayetumia programu tena na kuanza kusinyaa. Akiba ya hadi asilimia 30 imehakikishwa. Ilifanya kazi huko Amazon wakati huo; wakati huo hakukuwa na mtu huko Urusi ambaye angeweza kuifanya vizuri.

Nitakuambia moja kwa moja, akiba ni asilimia 30 kwa sababu tu tunatumia Kubernetes na kuchukua fursa ya uwezo wa wingu. Sasa hii inaweza kufanywa nchini Urusi. Sitatangaza kwa mtu yeyote, bila shaka, lakini hebu sema tu kwamba kuna watoa huduma ambao wanaweza kufanya hivyo, kutoa nje ya sanduku na kifungo.

Kuna jambo moja la mwisho ambalo ningependa pia kuteka mawazo yako. Ili maombi yako, miundombinu yako iwe ya Kiwingu, inaleta maana hatimaye kuanza kurekebisha mbinu inayoitwa Miundombinu kama Kanuni. Hiyo ni, hii ina maana kwamba maombi yako, au tuseme miundombinu yako, inahitajika kwa njia sawa kabisa na msimbo Eleza maombi yako, mantiki ya biashara yako kwa njia ya msimbo. Na ufanye kazi nayo kama nambari, ambayo ni, ijaribu, iondoe, ihifadhi kwenye git, weka CICD kwake.

Na hii ndiyo hasa hukuruhusu, kwanza, kuwa na udhibiti wa miundombinu yako kila wakati, kuelewa kila wakati iko katika hali gani. Pili, epuka shughuli za mwongozo zinazosababisha makosa. Tatu, epuka kile kinachoitwa mauzo, wakati unahitaji kila wakati kufanya kazi sawa za mwongozo. Nne, hukuruhusu kupona haraka sana katika tukio la kutofaulu. Huko Urusi, kila wakati ninapozungumza juu ya hili, kila wakati kuna idadi kubwa ya watu ambao husema: "Ndio, ni wazi, lakini unayo njia, kwa kifupi, hakuna haja ya kurekebisha chochote." Lakini ni kweli. Ikiwa kitu kimevunjwa katika miundombinu yako, basi kutoka kwa mtazamo wa mbinu ya Cloudnative na kutoka kwa mtazamo wa Miundombinu kama Kanuni, badala ya kuitengeneza, kwenda kwa seva, kutafakari ni nini kilichovunjika na kurekebisha, ni rahisi zaidi. kufuta seva na kuunda tena. Na haya yote yatarejeshwa.

Masuala haya yote yanajadiliwa kwa undani zaidi Kozi za video za Kubernetes: Junior, Basic, Mega. Kwa kufuata kiungo unaweza kujitambulisha na programu na masharti. Jambo rahisi ni kwamba unaweza kujua Kubernetes kwa kusoma kutoka nyumbani au kufanya kazi kwa masaa 1-2 kwa siku.

Chanzo: mapenzi.com