Jukwaa hukuruhusu kurahisisha uumbaji , ikiwa ni pamoja na katika miundombinu ya watoa huduma za wingu, kwenye majukwaa ya utangazaji au katika mifumo isiyo na chuma. Ili kuunda jukwaa la msingi la wingu, tulipaswa kuchukua udhibiti mkali wa vipengele vyote vilivyotumiwa na hivyo kuongeza uaminifu wa mchakato wa automatisering tata.
Suluhisho dhahiri lilikuwa kutumia Red Hat Enterprise Linux CoreOS (lahaja ya Red Hat Enterprise Linux) na CRI-O kama kiwango, na hii ndio sababu ...
Kwa kuwa mada ya kusafiri kwa meli ni nzuri sana kwa kutafuta mlinganisho wakati wa kuelezea kazi ya Kubernetes na vyombo, hebu jaribu kuzungumza juu ya shida za biashara ambazo CoreOS na CRI-O hutatua, kwa kutumia mfano. . Mnamo 1803, Marc Brunel alipewa jukumu la kutengeneza vizuizi 100 kwa mahitaji ya jeshi la wanamaji la Uingereza linalokua. Kizuizi cha wizi ni aina ya wizi ambao hutumika kuunganisha kamba kwenye matanga. Hadi mwanzoni mwa karne ya 19, vizuizi hivi vilitengenezwa kwa mikono, lakini Brunel iliweza kubinafsisha uzalishaji na kuanza kutoa vizuizi vya kawaida kwa kutumia zana za mashine. Uwekaji otomatiki wa mchakato huu ulimaanisha kuwa vizuizi vilivyotokana vilifanana kimsingi, vinaweza kubadilishwa kwa urahisi ikiwa vimevunjwa, na vinaweza kuzalishwa kwa idadi kubwa.
Sasa fikiria ikiwa Brunel alipaswa kufanya kazi hii kwa mifano 20 tofauti ya meli (matoleo ya Kubernetes) na kwa sayari tano tofauti na mikondo ya bahari tofauti kabisa na upepo (watoa huduma za wingu). Kwa kuongezea, ilihitajika kwamba meli zote (vikundi vya OpenShift), bila kujali sayari ambazo urambazaji unafanywa, kutoka kwa mtazamo wa wakuu (waendeshaji wanaosimamia uendeshaji wa vikundi) wafanye sawa. Ili kuendelea na mlinganisho wa baharini, wakuu wa meli hawajali kabisa ni aina gani ya vitalu vya wizi (CRI-O) hutumiwa kwenye meli zao - jambo kuu kwao ni kwamba vitalu hivi vina nguvu na vya kuaminika.
OpenShift 4, kama jukwaa la wingu, inakabiliwa na changamoto sawa ya biashara. Nodi mpya lazima ziundwe wakati wa uundaji wa nguzo, katika tukio la kutofaulu katika moja ya nodi, au wakati wa kuongeza nguzo. Wakati nodi mpya inapoundwa na kuanzishwa, vipengele muhimu vya seva pangishi, ikiwa ni pamoja na CRI-O, lazima visanidiwe ipasavyo. Kama ilivyo katika uzalishaji mwingine wowote, "malighafi" lazima itolewe mwanzoni. Kwa upande wa meli, malighafi ni chuma na mbao. Walakini, katika kesi ya kuunda mwenyeji kwa kupeleka kontena kwenye nguzo ya OpenShift 4, unahitaji kuwa na faili za usanidi na seva zinazotolewa na API kama ingizo. OpenShift kisha itatoa kiwango kinachohitajika cha uwekaji kiotomatiki katika kipindi chote cha maisha, ikitoa usaidizi unaohitajika wa bidhaa kwa watumiaji wa mwisho na hivyo kurejesha uwekezaji kwenye mfumo.
OpenShift 4 iliundwa kwa njia ya kutoa uwezo wa kusasisha mfumo kwa urahisi katika kipindi chote cha maisha ya jukwaa (kwa matoleo ya 4.X) kwa watoa huduma wakuu wote wa kompyuta ya wingu, majukwaa ya uboreshaji na hata mifumo ya chuma tupu. Kwa kufanya hivyo, nodes lazima ziundwe kwa misingi ya vipengele vinavyoweza kubadilishwa. Wakati kikundi kinahitaji toleo jipya la Kubernetes, pia hupokea toleo linalolingana la CRI-O kwenye CoreOS. Kwa kuwa toleo la CRI-O limefungamanishwa moja kwa moja na Kubernetes, hii hurahisisha vibali vyovyote vya majaribio, utatuzi au madhumuni ya usaidizi. Kwa kuongeza, mbinu hii inapunguza gharama kwa watumiaji wa mwisho na Red Hat.
Hii ni njia mpya kimsingi ya kufikiria kuhusu nguzo za Kubernetes na inaweka msingi wa kupanga baadhi ya vipengele vipya muhimu na vya kuvutia. CRI-O (Kiolesura cha Muda wa Kontena - Fungua Mpango wa Chombo, kwa kifupi CRI-OCI) iligeuka kuwa chaguo la mafanikio zaidi kwa uundaji wa wingi wa nodi ambazo ni muhimu kufanya kazi na OpenShift. CRI-O itachukua nafasi ya injini ya Docker iliyotumika hapo awali, ikitoa watumiaji wa OpenShift - ndio, umesikia sawa - injini ya kontena ya boring iliyoundwa mahsusi kwa kufanya kazi na Kubernetes.
Ulimwengu wa vyombo wazi
Ulimwengu umekuwa ukielekea kwenye vyombo vilivyo wazi kwa muda mrefu. Iwe katika Kubernetes, au katika viwango vya chini, matokeo katika mfumo ikolojia wa uvumbuzi katika kila ngazi.
Yote ilianza na uundaji wa Mpango wa Vyombo vya Open . Katika hatua hii ya awali ya kazi, vipimo vya chombo viliundwa ΠΈ . Hii ilihakikisha kuwa zana zinaweza kutumia kiwango kimoja na umbizo la umoja la kufanya kazi nao. Vipimo viliongezwa baadaye , kuruhusu watumiaji kushiriki kwa urahisi .
Jumuiya ya Kubernetes kisha ikatengeneza kiwango kimoja cha kiolesura kinachoweza kuunganishwa, kinachoitwa . Shukrani kwa hili, watumiaji wa Kubernetes waliweza kuunganisha injini mbalimbali kufanya kazi na vyombo pamoja na Docker.
Wahandisi katika Red Hat na Google waliona hitaji la soko la injini ya kontena ambayo inaweza kukubali maombi ya Kubelet kupitia itifaki ya CRI na wakaanzisha vyombo ambavyo vilioana na vipimo vya OCI vilivyotajwa hapo juu. Hivyo . Lakini nisamehe, hatukusema kwamba nyenzo hii itawekwa wakfu kwa CRI-O? Kweli ni, tu na kutolewa mradi huo ulipewa jina la CRI-O.
Mtini. 1.
Ubunifu na CRI-O na CoreOS
Kwa uzinduzi wa jukwaa la OpenShift 4, lilibadilishwa , iliyotumiwa na chaguo-msingi kwenye jukwaa, na nafasi yake kuchukuliwa na Docker na CRI-O, ikitoa mazingira ya gharama nafuu, thabiti, rahisi na ya kuchosha kwa kuendesha kontena ambalo hukua sambamba na Kubernetes. Hii hurahisisha sana usaidizi wa nguzo na usanidi. Usanidi wa injini ya kontena na seva pangishi, pamoja na usimamizi wao, huwa otomatiki ndani ya OpenShift 4.
Subiri, hii ikoje?
Hiyo ni kweli, pamoja na ujio wa OpenShift 4, hakuna tena haja ya kuunganisha kwa wapangishi binafsi na kusakinisha injini ya kontena, kusanidi hifadhi, kusanidi seva za utafutaji au kusanidi mtandao. Jukwaa la OpenShift 4 limeundwa upya kabisa ili kutumia sio tu kwa masharti ya programu za mtumiaji wa mwisho, lakini pia katika suala la shughuli za msingi za kiwango cha jukwaa kama vile kupeleka picha, kusanidi mfumo, au kusakinisha masasisho.
Kubernetes imekuwa ikiruhusu watumiaji kudhibiti programu kwa kufafanua hali inayotakiwa na kutumia , ili kuhakikisha kuwa hali halisi inalingana na hali inayolengwa kwa karibu iwezekanavyo. Hii hufungua fursa kubwa kutoka kwa mtazamo wa maendeleo na uendeshaji. Watengenezaji wanaweza kufafanua hali inayohitajika kwa kwa opereta katika mfumo wa faili ya YAML au JSON, na kisha opereta anaweza kuunda mfano wa maombi unaohitajika katika mazingira ya utayarishaji, na hali ya uendeshaji ya mfano huu italingana kikamilifu na ile iliyobainishwa.
Kwa kutumia Operators kwenye jukwaa, OpenShift 4 huleta dhana hii mpya (kwa kutumia dhana ya kuweka na hali halisi) kwa usimamizi wa RHEL CoreOS na CRI-O. Kazi za kusanidi na kusimamia matoleo ya mfumo wa uendeshaji na injini ya chombo ni otomatiki kwa kutumia kinachojulikana. . MCO hurahisisha sana kazi ya msimamizi wa nguzo, kimsingi inaendesha kiotomatiki hatua za mwisho za usakinishaji, pamoja na shughuli zinazofuata za usakinishaji (siku ya pili ya shughuli). Haya yote hufanya OpenShift 4 kuwa jukwaa la kweli la wingu. Tutaingia katika hili baadaye kidogo.
Vyombo vya kukimbia
Watumiaji wamepata fursa ya kutumia injini ya CRI-O katika jukwaa la OpenShift tangu toleo la 3.7 katika hali ya Muhtasari wa Tech na kutoka toleo la 3.9 katika hali Inayopatikana kwa Ujumla (inatumika kwa sasa). Kwa kuongeza, Red Hat hutumia sana katika OpenShift Online tangu toleo la 3.10. Haya yote yaliruhusu timu inayofanya kazi kwenye CRI-O kupata uzoefu wa kina katika kurusha makontena kwenye makundi makubwa ya Kubernetes. Ili kupata ufahamu wa kimsingi wa jinsi Kubernetes hutumia CRI-O, hebu tuangalie kielelezo kifuatacho, ambacho kinaonyesha jinsi usanifu unavyofanya kazi.
Mchele. 2. Jinsi vyombo hufanya kazi katika kundi la Kubernetes
CRI-O hurahisisha uundaji wa seva pangishi mpya za kontena kwa kusawazisha kiwango kizima cha juu wakati wa kuanzisha nodi mpya, na wakati wa kutoa matoleo mapya ya jukwaa la OpenShift. Marekebisho ya jukwaa zima huruhusu masasisho/urudishaji nyuma wa shughuli, na pia huzuia mikwamo katika utegemezi kati ya msingi wa chombo, injini ya kontena, nodi (Kubelets) na nodi ya Kubernetes Master. Kwa kudhibiti vipengee vyote vya jukwaa, kwa udhibiti na matoleo, daima kuna njia wazi kutoka jimbo A hadi jimbo la B. Hii hurahisisha mchakato wa kusasisha, kuboresha usalama, kuboresha kuripoti utendakazi, na kusaidia kupunguza gharama ya masasisho na usakinishaji wa matoleo mapya. .
Kuonyesha nguvu ya vipengele vya uingizwaji
Kama ilivyotajwa hapo awali, kutumia Kiendeshaji cha Usanidi wa Mashine kudhibiti kipangishi cha kontena na injini ya kontena katika OpenShift 4 hutoa kiwango kipya cha otomatiki ambacho hakikuwezekana hapo awali kwenye jukwaa la Kubernetes. Ili kuonyesha vipengele vipya, tutaonyesha jinsi unavyoweza kufanya mabadiliko kwenye faili ya crio.conf. Ili kuepuka kuchanganyikiwa na istilahi, jaribu kuzingatia matokeo.
Kwanza, hebu tuunde kile kinachoitwa usanidi wa wakati wa kukimbia wa kontena - Usanidi wa Muda wa Kontena. Ifikirie kama rasilimali ya Kubernetes inayowakilisha usanidi wa CRI-O. Kwa kweli, ni toleo maalum la kitu kinachoitwa MachineConfig, ambayo ni usanidi wowote unaotumwa kwa mashine ya RHEL CoreOS kama sehemu ya nguzo ya OpenShift.
Nyenzo hii maalum, inayoitwa ContainerRuntimeConfig, iliundwa ili kurahisisha kwa wasimamizi wa nguzo kusanidi CRI-O. Zana hii ina nguvu ya kutosha kwamba inaweza tu kutumika kwa nodi fulani kulingana na mipangilio ya MachineConfigPool. Ifikirie kama kikundi cha mashine zinazotumikia kusudi moja.
Angalia mistari miwili ya mwisho ambayo tutabadilisha katika faili ya /etc/crio/crio.conf. Mistari hii miwili inafanana sana na mistari katika faili ya crio.conf, ni:
vi ContainerRuntimeConfig.yaml
Hitimisho:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Sasa hebu tusukuma faili hii kwenye nguzo ya Kubernetes na tuhakikishe kwamba iliundwa. Tafadhali kumbuka kuwa operesheni ni sawa kabisa na rasilimali nyingine yoyote ya Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Hitimisho:
NAME AGE
set-log-and-pid 22h
Mara tu tunapounda ContainerRuntimeConfig, tunahitaji kurekebisha mojawapo ya MachineConfigPools ili kutoa ishara kwa Kubernetes kwamba tunataka kutumia usanidi huu kwa kundi maalum la mashine kwenye nguzo. Katika kesi hii tutabadilisha MachineConfigPool kwa nodi kuu:
oc edit MachineConfigPool/master
Hitimisho (kwa uwazi, kiini kikuu kimesalia):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Katika hatua hii, MCO huanza kuunda faili mpya ya crio.conf kwa nguzo. Katika kesi hii, faili ya usanidi iliyokamilishwa kabisa inaweza kutazamwa kwa kutumia Kubernetes API. Kumbuka, ContainerRuntimeConfig ni toleo maalum la MachineConfig, kwa hivyo tunaweza kuona matokeo kwa kuangalia mistari husika katika MachineConfigs:
oc get MachineConfigs | grep rendered
Hitimisho:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Tafadhali kumbuka kuwa faili ya usanidi iliyotokana ya nodi kuu ilikuwa toleo jipya zaidi kuliko usanidi wa asili. Ili kuiona, endesha amri ifuatayo. Kwa kupita, tunaona kuwa hii labda ni moja ya safu bora zaidi katika historia ya Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Hitimisho:
pids_limit = 2048
Sasa hebu tuhakikishe kuwa usanidi umetumika kwa nodi zote kuu. Kwanza tunapata orodha ya nodi kwenye nguzo:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Sasa hebu tuangalie faili iliyowekwa. Utaona kwamba faili imesasishwa na maadili mapya ya maelekezo ya pid na utatuzi ambayo tulibainisha katika rasilimali ya ContainerRuntimeConfig. Urembo wenyewe:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal β cat /host/etc/crio/crio.conf | egrep 'debug||pidβ
Hitimisho:
...
pids_limit = 2048
...
log_level = "debug"
...
Mabadiliko haya yote kwenye nguzo yalifanywa bila hata kuendesha SSH. Kazi yote ilifanywa kwa kupata nodi kuu ya Kuberentes. Hiyo ni, vigezo hivi vipya vilisanidiwa tu kwenye nodi kuu. Nodi za wafanyikazi hazikubadilika, ambayo inaonyesha faida za mbinu ya Kubernetes ya kutumia hali maalum na halisi kuhusiana na mwenyeji wa vyombo na injini za kontena zilizo na vitu vinavyoweza kubadilishwa.
Mfano hapo juu unaonyesha uwezo wa kufanya mabadiliko kwenye nguzo ndogo ya OpenShift Container Platform 4 yenye nodi tatu za uzalishaji au nguzo kubwa ya uzalishaji yenye nodi 3000. Kwa vyovyote vile, kiasi cha kazi kitakuwa sawa - na kidogo sana - sanidi tu faili ya ContainerRuntimeConfig, na ubadilishe lebo moja katika MachineConfigPool. Na unaweza kufanya hivi kwa toleo lolote la OpenShift Container Platform 4.X inayoendesha Kubernetes katika kipindi chote cha maisha yake.
Mara nyingi kampuni za teknolojia hubadilika haraka sana hivi kwamba hatuwezi kueleza kwa nini tunachagua teknolojia fulani kwa vipengele vya msingi. Injini za kontena zimekuwa sehemu ya kihistoria ambayo watumiaji huingiliana nayo moja kwa moja. Kwa kuwa umaarufu wa vyombo kwa asili ulianza na ujio wa injini za kontena, watumiaji mara nyingi huonyesha kupendezwa nazo. Hii ni sababu nyingine kwa nini Red Hat ilichagua CRI-O. Makontena yanabadilika kwa kuzingatia uimbaji, na tumegundua kuwa CRI-O hutoa matumizi bora zaidi unapofanya kazi na OpenShift 4.
Chanzo: mapenzi.com