ProHoster > Blogs > Administrācija > Konteiners uz konveijeru: OpenShift Container Platform 4 tagad ir noklusējuma vērtÄ«ba CRI-O

Konteiners uz konveijeru: OpenShift Container Platform 4 tagad ir noklusējuma vērtÄ«ba CRI-O

Platforma Red Hat OpenShift konteineru platforma 4 ļauj racionalizēt izveidi resursdatori konteineru izvietoÅ”anai, tostarp mākoņpakalpojumu sniedzēju infrastruktÅ«rā, virtualizācijas platformās vai plikmetāla sistēmās. Lai izveidotu patiesi uz mākoņiem balstÄ«tu platformu, mums bija stingri jākontrolē visi izmantotie elementi un tādējādi jāpalielina sarežģītā automatizācijas procesa uzticamÄ«ba.

Konteiners uz konveijeru: OpenShift Container Platform 4 tagad ir noklusējuma vērtÄ«ba CRI-O

Acīmredzamais risinājums bija izmantot Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux variantu) un CRI-O kā standartu, un lūk, kāpēc...

Tā kā burāŔanas tēma ir ļoti laba, lai atrastu analoÄ£ijas, skaidrojot Kubernetes un konteineru darbu, mēģināsim runāt par biznesa problēmām, kuras risina CoreOS un CRI-O, izmantojot piemēru Brunela izgudrojumi takelāžas bloku ražoÅ”anā. 1803. gadā Markam Brunelam tika uzdots saražot 100 19 takelāžas bloku augoŔās Lielbritānijas flotes vajadzÄ«bām. Takelāžas bloks ir takelāžas veids, ko izmanto, lai burām piestiprinātu virves. LÄ«dz paÅ”am XNUMX. gadsimta sākumam Å”ie bloki tika izgatavoti ar rokām, taču Brunelam izdevās automatizēt ražoÅ”anu un viņŔ sāka ražot standartizētus blokus, izmantojot darbgaldus. Å Ä« procesa automatizācija nozÄ«mēja, ka iegÅ«tie bloki bÅ«tÄ«bā bija identiski, tos varēja viegli nomainÄ«t, ja tie saplÄ«st, un tos varēja ražot lielos daudzumos.

Tagad iedomājieties, ja Brunelam Å”is darbs bÅ«tu jāveic 20 dažādiem kuÄ£u modeļiem (Kubernetes versijas) un piecām dažādām planētām ar pilnÄ«gi atŔķirÄ«gām jÅ«ras straumēm un vējiem (mākoņu nodroÅ”inātājiem). Turklāt tika noteikts, ka visiem kuÄ£iem (OpenShift klasteriem) neatkarÄ«gi no planētām, uz kurām tiek veikta navigācija, no kapteiņu (operatoru, kas pārvalda kopu darbÄ«bu) viedokļa uzvesties vienādi. Turpinot jÅ«rniecÄ«bas analoÄ£iju, kuÄ£u kapteiņiem ir pilnÄ«gi vienalga, kādi takelāžas bloki (CRI-O) tiek izmantoti uz viņu kuÄ£iem - viņiem galvenais, lai Å”ie bloki bÅ«tu spēcÄ«gi un uzticami.

OpenShift 4 kā mākoņa platforma saskaras ar ļoti lÄ«dzÄ«gu biznesa izaicinājumu. Jauni mezgli ir jāizveido klastera izveides laikā, kļūmes gadÄ«jumā kādā no mezgliem vai klastera mērogoÅ”anas laikā. Kad tiek izveidots un inicializēts jauns mezgls, attiecÄ«gi jākonfigurē kritiskie resursdatora komponenti, tostarp CRI-O. Tāpat kā jebkurā citā ražoÅ”anā, ā€œizejvielasā€ ir jāpiegādā sākumā. AttiecÄ«bā uz kuÄ£iem izejvielas ir metāls un koks. Tomēr, ja izveidojat resursdatoru konteineru izvietoÅ”anai OpenShift 4 klasterÄ«, kā ievadei ir jābÅ«t konfigurācijas failiem un API nodroÅ”inātiem serveriem. Pēc tam OpenShift nodroÅ”inās nepiecieÅ”amo automatizācijas lÄ«meni visā dzÄ«ves ciklā, piedāvājot galalietotājiem nepiecieÅ”amo produktu atbalstu un tādējādi atmaksājot investÄ«cijas platformā.

OpenShift 4 tika izveidots tā, lai nodroÅ”inātu iespēju ērti atjaunināt sistēmu visā platformas dzÄ«ves ciklā (versijai 4.X) visiem lielākajiem mākoņdatoÅ”anas pakalpojumu sniedzējiem, virtualizācijas platformām un pat tukÅ”a metāla sistēmām. Lai to izdarÄ«tu, mezgli ir jāizveido, pamatojoties uz savstarpēji aizvietojamiem elementiem. Ja klasterim ir nepiecieÅ”ama jauna Kubernetes versija, tā saņem arÄ« atbilstoÅ”o CRI-O versiju operētājsistēmā CoreOS. Tā kā CRI-O versija ir tieÅ”i saistÄ«ta ar Kubernetes, tas ievērojami vienkārÅ”o visas permutācijas testÄ“Å”anas, problēmu novērÅ”anas vai atbalsta nolÅ«kos. Turklāt Ŕī pieeja samazina galalietotāju un Red Hat izmaksas.

Å is ir principiāli jauns domāŔanas veids par Kubernetes klasteriem, un tas ir pamats dažu ļoti noderÄ«gu un pārliecinoÅ”u jaunu funkciju plānoÅ”anai. CRI-O (Container Runtime Interface - Open Container Initiative, saÄ«sināti CRI-OCI) izrādÄ«jās veiksmÄ«gākā izvēle mezglu masveida izveidei, kas nepiecieÅ”ama darbam ar OpenShift. CRI-O aizstās iepriekÅ” izmantoto Docker dzinēju, piedāvājot OpenShift lietotājiem ekonomisks, stabils, vienkārÅ”s un garlaicÄ«gs ā€“ jā, pareizi dzirdējāt ā€“ garlaicÄ«gs konteinera dzinējs, kas radÄ«ts speciāli darbam ar Kubernetes.

Atvērto konteineru pasaule

Pasaule jau ilgu laiku virzās uz atvērtiem konteineriem. Vai Kubernetes, vai zemākos līmeņos, konteineru standartu izstrāde rada inovāciju ekosistēmu visos līmeņos.

Viss sākās ar Open Containers Initiative izveidi 2015. gada jÅ«nijā. Å ajā agrÄ«najā darba posmā tika izveidotas konteineru specifikācijas attēlu Šø izpildlaika vide. Tas nodroÅ”ināja, ka rÄ«ki var izmantot vienotu standartu konteineru attēli un vienots formāts darbam ar tiem. Specifikācijas tika pievienotas vēlāk izplatÄ«Å”ana, ļaujot lietotājiem ērti koplietot konteineru attēli.

Pēc tam Kubernetes kopiena izstrādāja vienotu standartu pievienojamam interfeisam, ko sauc Konteinera izpildlaika saskarne (CRI). Pateicoties tam, Kubernetes lietotāji papildus Docker varēja savienot dažādus dzinējus darbam ar konteineriem.

Red Hat un Google inženieri saskatÄ«ja tirgus nepiecieÅ”amÄ«bu pēc konteinera dzinēja, kas varētu pieņemt Kubelet pieprasÄ«jumus, izmantojot CRI protokolu, un ieviesa konteinerus, kas bija saderÄ«gi ar iepriekÅ” minētajām OCI specifikācijām. Tātad ParādÄ«jās OCID. Bet atvainojiet, vai mēs neteicām, ka Å”is materiāls bÅ«s veltÄ«ts CRI-O? PatiesÄ«bā tā ir, tikai ar atbrÄ«voÅ”anu 1.0. versija projekts tika pārdēvēts par CRI-O.

Att. 1.

Konteiners uz konveijeru: OpenShift Container Platform 4 tagad ir noklusējuma vērtÄ«ba CRI-O

Inovācija ar CRI-O un CoreOS

LÄ«dz ar OpenShift 4 platformas palaiÅ”anu tā tika mainÄ«ta konteinera dzinējs, kas platformā tiek izmantots pēc noklusējuma, un Docker tika aizstāts ar CRI-O, piedāvājot rentablu, stabilu, vienkārÅ”u un garlaicÄ«gu vidi konteinera darbināŔanai, kas tiek izstrādāts paralēli Kubernetes. Tas ievērojami vienkārÅ”o klasteru atbalstu un konfigurÄ“Å”anu. Konteinera dzinēja un saimniekdatora konfigurācija, kā arÄ« to pārvaldÄ«ba OpenShift 4 ietvaros kļūst automatizēta.

Pagaidiet, kā tas ir?

TieÅ”i tā, lÄ«dz ar OpenShift 4 parādÄ«Å”anos vairs nav nepiecieÅ”ams izveidot savienojumu ar atseviŔķiem resursdatoriem un instalēt konteineru dzinēju, konfigurēt krātuvi, konfigurēt meklÄ“Å”anas serverus vai konfigurēt tÄ«klu. OpenShift 4 platforma ir pilnÄ«bā pārveidota, lai izmantotu Operatora sistēma ne tikai attiecÄ«bā uz galalietotāju lietojumprogrammām, bet arÄ« attiecÄ«bā uz pamata platformas lÄ«meņa darbÄ«bām, piemēram, attēlu izvietoÅ”anu, sistēmas konfigurÄ“Å”anu vai atjauninājumu instalÄ“Å”anu.

Kubernetes vienmēr ir ļāvis lietotājiem pārvaldÄ«t lietojumprogrammas, definējot vēlamo stāvokli un izmantojot kontrolieri, lai nodroÅ”inātu, ka faktiskais stāvoklis pēc iespējas tuvāk atbilst mērÄ·a stāvoklim. Å is mērÄ·a stāvoklis un faktiskā stāvokļa pieeja paver lielas iespējas gan no attÄ«stÄ«bas, gan darbÄ«bas viedokļa. Izstrādātāji var definēt nepiecieÅ”amo stāvokli ar padod tālāk operatoram YAML vai JSON faila veidā, un pēc tam operators var izveidot nepiecieÅ”amo lietojumprogrammas gadÄ«jumu ražoÅ”anas vidē, un Ŕīs instances darbÄ«bas stāvoklis pilnÄ«bā atbildÄ«s norādÄ«tajam.

Izmantojot platformā Operatorus, OpenShift 4 nodroÅ”ina Å”o jauno paradigmu (izmantojot kopas un faktiskā stāvokļa jēdzienu) RHEL CoreOS un CRI-O pārvaldÄ«bā. Operētājsistēmas un konteinera dzinēja versiju konfigurÄ“Å”anas un pārvaldÄ«bas uzdevumi tiek automatizēti, izmantojot t.s Iekārtas konfigurācijas operators (MCO). MCO ievērojami vienkārÅ”o klastera administratora darbu, bÅ«tÄ«bā automatizējot pēdējos instalÄ“Å”anas posmus, kā arÄ« turpmākās pēcinstalÄ“Å”anas darbÄ«bas (otrās dienas darbÄ«bas). Tas viss padara OpenShift 4 par Ä«stu mākoņa platformu. Mēs par to pievērsÄ«simies nedaudz vēlāk.

DarbojoŔie konteineri

Lietotājiem ir bijusi iespēja izmantot CRI-O dzinēju OpenShift platformā kopÅ” versijas 3.7 tehniskā priekÅ”skatÄ«juma statusā un no versijas 3.9 statusā VispārÄ«gi pieejams (paÅ”laik tiek atbalstÄ«ts). Turklāt Red Hat masveidā izmanto CRI-O ražoÅ”anas slodzes palaiÅ”anai pakalpojumā OpenShift Online kopÅ” versijas 3.10. Tas viss ļāva komandai, kas strādā pie CRI-O, iegÅ«t plaÅ”u pieredzi konteineru masveida palaiÅ”anā lielos Kubernetes klasteros. Lai iegÅ«tu pamata izpratni par to, kā Kubernetes izmanto CRI-O, apskatÄ«sim tālāk redzamo ilustrāciju, kas parāda, kā darbojas arhitektÅ«ra.

Rīsi. 2. Kā konteineri darbojas Kubernetes klasterī

Konteiners uz konveijeru: OpenShift Container Platform 4 tagad ir noklusējuma vērtÄ«ba CRI-O

CRI-O vienkārÅ”o jaunu konteineru saimniekdatoru izveidi, sinhronizējot visu augstāko lÄ«meni, inicializējot jaunus mezglus un izlaižot jaunas OpenShift platformas versijas. Visas platformas pārskatÄ«Å”ana ļauj veikt darÄ«jumu atjauninājumus/atcelÅ”anu, kā arÄ« novērÅ” strupceļu atkarÄ«bas starp konteinera astes kodolu, konteinera dzinēju, mezgliem (Kubelets) un Kubernetes Master mezglu. Centralizēti pārvaldot visus platformas komponentus ar vadÄ«bu un versiju veidoÅ”anu, vienmēr ir skaidrs ceļŔ no stāvokļa A uz stāvokli B. Tas vienkārÅ”o atjaunināŔanas procesu, uzlabo droŔību, uzlabo veiktspējas pārskatus un palÄ«dz samazināt izmaksas par atjauninājumiem un jaunu versiju instalÄ“Å”anu. .

AizvietojoŔo elementu jaudas demonstrēŔana

Kā minēts iepriekÅ”, izmantojot Machine Config Operator, lai pārvaldÄ«tu konteinera resursdatoru un konteinera dzinēju OpenShift 4, tiek nodroÅ”ināts jauns automatizācijas lÄ«menis, kas iepriekÅ” nebija iespējams Kubernetes platformā. Lai demonstrētu jaunās funkcijas, mēs parādÄ«sim, kā jÅ«s varat veikt izmaiņas failā crio.conf. Lai nemulsinātu terminoloÄ£iju, mēģiniet koncentrēties uz rezultātiem.

Vispirms izveidosim tā saukto konteinera izpildlaika konfigurāciju ā€” Container Runtime Config. Padomājiet par to kā par Kubernetes resursu, kas atspoguļo CRI-O konfigurāciju. PatiesÄ«bā tā ir specializēta versija tam, ko sauc par MachineConfig, kas ir jebkura konfigurācija, kas tiek izvietota RHEL CoreOS maŔīnā kā daļa no OpenShift klastera.

Å is pielāgotais resurss ar nosaukumu ContainerRuntimeConfig tika izveidots, lai klasteru administratoriem bÅ«tu vieglāk konfigurēt CRI-O. Å is rÄ«ks ir pietiekami jaudÄ«gs, lai to varētu lietot tikai noteiktiem mezgliem atkarÄ«bā no MachineConfigPool iestatÄ«jumiem. Uztveriet to kā maŔīnu grupu, kas kalpo vienam un tam paÅ”am mērÄ·im.

Ievērojiet pēdējās divas rindiņas, kuras mēs mainīsim /etc/crio/crio.conf failā. Šīs divas rindas ir ļoti līdzīgas rindām failā crio.conf, tās ir:

vi ContainerRuntimeConfig.yaml

Secinājums:

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

Tagad virzÄ«sim Å”o failu uz Kubernetes klasteru un pārbaudÄ«sim, vai tas tieŔām ir izveidots. LÅ«dzu, ņemiet vērā, ka darbÄ«ba ir tieÅ”i tāda pati kā ar jebkuru citu Kubernetes resursu:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

Secinājums: 

NAME              AGE
set-log-and-pid   22h

Kad esam izveidojuÅ”i ContainerRuntimeConfig, mums ir jāmaina viens no MachineConfigPools, lai ziņotu Kubernetes, ka vēlamies lietot Å”o konfigurāciju noteiktai klastera maŔīnu grupai. Å ajā gadÄ«jumā mēs mainÄ«sim galveno mezglu MachineConfigPool: 

oc edit MachineConfigPool/master

Secinājums (skaidrības labad galvenā būtība ir atstāta): 

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

Šajā brīdī MCO sāk klasterim izveidot jaunu crio.conf failu. Šajā gadījumā pilnībā pabeigto konfigurācijas failu var apskatīt, izmantojot Kubernetes API. Atcerieties, ka ContainerRuntimeConfig ir tikai specializēta MachineConfig versija, tāpēc mēs varam redzēt rezultātu, aplūkojot attiecīgās rindiņas rīkā MachineConfig: 

oc get MachineConfigs | grep rendered

Secinājums: 

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

LÅ«dzu, ņemiet vērā, ka iegÅ«tais galveno mezglu konfigurācijas fails bija jaunāka versija nekā sākotnējās konfigurācijas. Lai to apskatÄ«tu, palaidiet Ŕādu komandu. Garāmejot, mēs atzÄ«mējam, ka Å”is, iespējams, ir viens no labākajiem vienas lÄ«nijas materiāliem Kubernetes vēsturē: 

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

Secinājums: 

pids_limit = 2048

Tagad pārliecināsimies, ka konfigurācija ir piemērota visiem galvenajiem mezgliem. Vispirms mēs iegūstam klastera mezglu sarakstu: 

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

Tagad apskatÄ«sim instalēto failu. JÅ«s redzēsit, ka fails ir atjaunināts ar jaunajām vērtÄ«bām pid un atkļūdoÅ”anas direktÄ«vām, kuras norādÄ«jām resursā ContainerRuntimeConfig. Pati elegance: 

oc debug node/ip-10-0-135-153.us-east-2.compute.internal ā€” cat /host/etc/crio/crio.conf | egrep 'debug||pidā€™

Secinājums: 

...
pids_limit = 2048
...
log_level = "debug"
...

Visas Ŕīs klastera izmaiņas tika veiktas, pat nepalaižot SSH. Viss darbs tika veikts, piekļūstot Kuberentes galvenajam mezglam. Tas nozÄ«mē, ka Å”ie jaunie parametri tika konfigurēti tikai galvenajos mezglos. Darbinieku mezgli nemainÄ«jās, kas parāda Kubernetes metodoloÄ£ijas priekÅ”rocÄ«bas, izmantojot norādÄ«tos un faktiskos stāvokļus saistÄ«bā ar konteineru saimniekiem un konteineru dzinējiem ar maināmiem elementiem.

IepriekÅ” minētais piemērs parāda iespēju veikt izmaiņas nelielā OpenShift Container Platform 4 klasterÄ« ar trim ražoÅ”anas mezgliem vai milzÄ«gā ražoÅ”anas klasterÄ« ar 3000 mezgliem. Jebkurā gadÄ«jumā darba apjoms bÅ«s tāds pats ā€” un ļoti mazs ā€” vienkārÅ”i konfigurējiet ContainerRuntimeConfig failu un nomainiet vienu etiÄ·eti programmā MachineConfigPool. To var izdarÄ«t ar jebkuru OpenShift Container Platform 4.X versiju, kurā darbojas Kubernetes visā tā dzÄ«ves ciklā.

Bieži vien tehnoloÄ£iju uzņēmumi attÄ«stās tik ātri, ka mēs nevaram izskaidrot, kāpēc mēs izvēlamies noteiktas tehnoloÄ£ijas pamatā esoÅ”ajiem komponentiem. Konteineru dzinēji vēsturiski ir bijuÅ”i komponenti, ar kuriem lietotāji mijiedarbojas tieÅ”i. Tā kā konteineru popularitāte dabiski sākās lÄ«dz ar konteineru dzinēju parādÄ«Å”anos, lietotāji bieži izrāda interesi par tiem. Tas ir vēl viens iemesls, kāpēc Red Hat izvēlējās CRI-O. Konteineri attÄ«stās, tagad koncentrējoties uz orÄ·estrÄ“Å”anu, un mēs esam noskaidrojuÅ”i, ka CRI-O nodroÅ”ina vislabāko pieredzi darbā ar OpenShift 4.

Avots: www.habr.com

Pievieno komentāru