Platforma umožňuje zefektívniť vytváranie , vrátane infraštruktúry poskytovateľov cloudových služieb, na virtualizačných platformách alebo v systémoch bare-metal. Aby sme vytvorili skutočne cloudovú platformu, museli sme prísne kontrolovať všetky používané prvky a tým zvýšiť spoľahlivosť zložitých procesov automatizácie.
Očividným riešením sa stalo použitie ako štandardu Red Hat Enterprise Linux CoreOS (varianta Red Hat Enterprise Linux) a CRI-O, a to z týchto dôvodov …
Keďže téma námorníctva je veľmi vhodná pre hľadanie analógií pri vysvetľovaní fungovania Kubernetes a kontajnerov, pokúsime sa rozprávať o tých obchodných problémoch, ktoré riešia CoreOS a CRI-O, na príklade . V roku 1803 stál pred Markom Brunelom úloha vyrobiť 100 tisíc kladiek pre potreby rastúceho námorného loďstva Británie. Kladka je typ výstroja, ktorý sa používa na upevnenie lán na plachtách. Až do začiatku 19. storočia sa tieto kladky vyrábali ručne, ale Brunelovi sa podarilo automatizovať výrobu a začať vyrábať štandardizované kladky pomocou strojov. Automatizácia tohto procesu znamenala, že výsledkom bolo, že všetky kladky boli prakticky rovnaké, mohli byť ľahko nahradené v prípade poruchy a mohli sa vyrábať vo veľkých množstvách.
A teraz si predstavte, že Brunel by musel vykonať túto prácu pre 20 rôznych modelov lodí (verzií Kubernetes) a pre päť rôznych planét s úplne odlišnými morskými prúdmi a vetrami (cloudoví poskytovatelia). Navyše bolo potrebné, aby sa všetky lode (klastre OpenShift), bez ohľadu na planéty, po ktorých sa naviguje, z pohľadu kapitánov (operátorov riadiacich prácu klastrov) správali rovnako. Pokračujúc v námornej analógii, kapitánom lodí je úplne jedno, aké kladky (CRI-O) sa používajú na ich lodiach – pre nich je dôležité, aby tieto kladky boli pevné a spoľahlivé.
Pred OpenShift 4, ako cloudová platforma, stojí veľmi podobná obchodná úloha. Nové uzly by sa mali vytvárať v momente vytvárania klastru, v prípade zlyhania jedného z uzlov alebo pri škálovaní klastru. Pri vytváraní a inicializácii nového uzla musia byť zodpovedajúcim spôsobom nakonfigurované aj kritické komponenty hostiteľa, vrátane CRI-O. Rovnako ako v akomkoľvek inom výrobnom prostredí, na začiatku je potrebné dodať „suroviny“. V prípade lodí slúžia ako suroviny kov a drevo. Avšak pri vytváraní hostiteľa na nasadenie kontajnerov v klastru OpenShift 4 je potrebné mať vstupy v podobe konfiguračných súborov a poskytovaných API serverov. Po tom OpenShift zabezpečí potrebnú úroveň automatizácie počas celého životného cyklu, ponúkajúc potrebnú produktovú podporu pre koncových užívateľov a tak splácajúc investície do platformy.
OpenShift 4 bola vytvorená tak, aby umožnila pohodlné aktualizácie systému počas celého životného cyklu platformy (pre verzie 4.X) pre všetkých hlavných poskytovateľov cloudových výpočtov, virtualizačných platforiem a dokonca aj bare metal systémov. Na tento účel musia byť uzly vytvorené na báze vzájomne zameniteľných prvkov. Keď klaster vyžaduje novú verziu Kubernetes, dostane aj príslušnú verziu CRI-O na CoreOS. Pretože je verzia CRI-O priamo viazaná na Kubernetes, to všetko do značnej miery zjednodušuje akékoľvek preusporiadania na testovanie, odstraňovanie problémov alebo podporu. Okrem toho tento prístup umožňuje znížiť náklady pre koncových užívateľov a Red Hat.
Toto je zásadne nový pohľad na klastre Kubernetes, ktorý kladie základy pre plánovanie nových veľmi užitočných a atraktívnych funkcií. CRI-O (projekt otvoreného kontajnera Container Runtime Interface — Open Container Initiative, skrátene CRI-OCI) sa ukázal ako najvýhodnejšia voľba pre masovú produkciu uzlov, ktorá je potrebná pre prevádzku OpenShift. CRI-O nahradí predtým použitý engin Docker a ponúkne užívateľom OpenShift – áno,počuli ste správne – nudný kontajnerový engin, vytvorený špeciálne na prácu s Kubernetes.
Svet otvorených kontajnerov
Svet sa už dávno posúva smerom k otvoreným kontajnerom. Nech už ide o Kubernetes, alebo na nižších úrovniach, prispieva k vzniku ekosystému inovácií na každej úrovni.
Všetko sa začalo vytvorením iniciatívy Open Containers Initiative . V tomto rannom štádiu práce boli vytvorené špecifikácie kontajnerového a . To umožnilo zaručiť, že nástroje môžu používať jednotný štandard a jednotný formát na ich spracovanie. Následne boli pridané špecifikácie , čo umožnilo používateľom s ľahkosťou zdieľať .
Potom komunita Kubernetes vyvinula jednotný štandard pripojiteľného rozhrania (pluggable interface), nazvaného . Vďaka tomu mohli používatelia Kubernetes pripojiť rôzne motory na prácu s kontajnermi okrem Dockeru.
Inžinieri spoločností Red Hat a Google zistili existujúcu potrebu na trhu po kontajnerovom motore, ktorý by mohol prijímať požiadavky od Kubelet prostredníctvom protokolu CRI a predstavili kontajnery, ktoré boli kompatibilné s uvedenými špecifikáciami OCI. Tak Ale chvíľu, veď sme povedali, že tento materiál bude venovaný CRI-O? Naozaj, tak to je, jednoducho s vydaním bol projekt premenovaný na CRI-O.
Obr. 1.
Inovácie s CRI-O a CoreOS
S uvedením platformy OpenShift 4 sa zmenil používaný na platforme ako predvolený, a namiesto Dockeru nastúpil CRI-O, ktorý ponúkol ekonomické, stabilné, jednoduché a nudné prostredie na spúšťanie kontajnerov, ktoré sa rozvíja súbežne s Kubernetes. To výrazne zjednodušuje podporu a konfiguráciu klasteru. Konfigurovanie kontajnerového motora a hostiteľa, ako aj ich správa sa stáva automatizovanou v rámci OpenShift 4.
Počkajte, ako to?
Presne tak, s príchodom OpenShift 4 už nie je potrebné pripájať sa k samostatným hostiteľom a inštalovať kontajnerový motor, konfigurovať úložisko, nastavovať servery na hľadanie alebo konfigurovať sieť. Platforma OpenShift 4 bola úplne prepracovaná pre využitie the nielen z pohľadu aplikácií koncových používateľov, ale aj z pohľadu základných operácií na úrovni platformy, ako sú nasadzovanie obrazov, konfigurácia systému alebo inštalácia aktualizácií.
Kubernetes vždy umožňoval používateľom spravovať aplikácie určením požadovaného stavu a použitím , aby zabezpečil, že aktuálny stav je maximálne v súlade s požadovaným stavom. Tento otvára veľké možnosti ako z pohľadu vývoja, tak z pohľadu prevádzky. Vývojári môžu určiť požadovaný stav, operátorovi vo forme súboru YAML alebo JSON, a potom operátor môže vytvoriť v prevádzkovom prostredí potrebný inštanciu aplikácie, pričom pracovný stav tejto inštancie bude úplne zodpovedať požadovanému.
Pomocou operátorov (Operators) na platforme, OpenShift 4 prináša túto novú paradigmu (s využitím konceptu požadovaného a aktuálneho stavu) do správy RHEL CoreOS a CRI-O. Úlohy konfigurovania a správy verzií operačného systému a kontajnerového enginu sú automatizované pomocou tzv. . MCO výrazne zjednodušuje prácu administrátora klastru, v podstate automatizuje posledné fázy inštalácie, ako aj následné operácie po inštalácii (day two operations). To všetko robí z OpenShift 4 skutočnú cloudovú platformu. Na tomto sa zastavíme neskôr.
Spúšťanie kontajnerov
Používatelia mali možnosť používať engin CRI-O na platforme OpenShift od verzie 3.7 v statuse Tech Preview a od verzie 3.9 v statuse Generally Available (aktuálne podporované). Okrem toho, Red Hat masívne využíva v OpenShift Online od verzie 3.10. To všetko umožnilo tímu pracujúcemu na CRI-O získať obrovské skúsenosti s hromadným spúšťaním kontajnerov na veľkých klastroch Kubernetes. Aby sme získali základné predstavy o tom, ako Kubernetes využíva CRI-O, pozrime sa na nasledujúcu ilustráciu, na ktorej je znázornený princíp fungovania architektúry.
Obr. 2. Ako fungujú kontajnery v klastri Kubernetes
CRI-O zjednodušuje vytváranie nových kontajnerových hostiteľov synchronizovaním všetkých prevádzkových vrcholov pri inicializácii nových uzlov a pri vydávaní nových verzií platformy OpenShift. Revizia celej platformy umožňuje vykonávať transakčné aktualizácie / vrátenia, a tiež zabraňuje vzájomným blokovaniam závislostí medzi jadrom kontajnerového hostiteľa, kontajnerovým motorom, uzlami (Kubelets) a hlavným uzlom Kubernetes Master. Pri centralizovanej správe všetkých komponentov platformy, s kontrolou a riadením verzií, je vždy možné sledovať jasnú cestu zo stavu A do stavu B. To zjednodušuje proces aktualizácií, zvyšuje bezpečnosť, zlepšuje reportovanie výkonnosti a pomáha znížiť náklady na aktualizácie a inštaláciu nových verzií.
Demonštrácia sily modulárnych prvkov
Ako bolo uvedené skôr, používanie Machine Config Operator na správu kontajnerového hostiteľa a kontajnerového motora v OpenShift 4 zabezpečuje novú úroveň automatizácie, ktorá nebola na platforme Kubernetes predtým možná. Aby sme predviedli nové možnosti, ukážeme, ako by ste mohli vykonať zmeny v súbore crio.conf. Aby sme sa nezamotali v terminológii, snažte sa sústrediť na výsledky.
Najprv vytvorme to, čomu hovoríme konfiguračný súbor prostredia kontajnerov – Container Runtime Config. Považujte to za určitý zdroj Kubernetes, ktorý predstavuje konfiguráciu pre CRI-O. V skutočnosti je to špecializovaná verzia toho, čo sa nazýva MachineConfig, ktorá predstavuje akúkoľvek konfiguráciu nasadenú na stroji RHEL CoreOS v rámci klastrov OpenShift.
Tento prispôsobený zdroj, nazývaný ContainerRuntimeConfig, bol navrhnutý tak, aby zjednodušil administrátorom klastrov konfiguráciu CRI-O. Je to dosť silný nástroj, ktorý sa dá aplikovať len na určité uzly v závislosti od nastavení MachineConfigPool. Považujte to za skupinu strojov, ktoré slúžia na rovnaký účel.
Všimnite si dve posledné riadky, ktoré plánujeme zmeniť v súbore /etc/crio/crio.conf. Tieto dva riadky sú veľmi podobné riadkom v súbore crio.conf, to sú:
vi ContainerRuntimeConfig.yaml
Výstup:
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
Teraz odošleme tento súbor do klastru Kubernetes a skontrolujeme, či bol skutočne vytvorený. Všimnite si, že práca prebieha presne tak, ako s akýmkoľvek iným zdrojom Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Výstup:
NÁZOV VEK
set-log-and-pid 22h
Po vytvorení ContainerRuntimeConfig musíme upraviť jeden z MachineConfigPools, aby sme dali najavo Kubernetes, že chceme aplikovať túto konfiguráciu na určitú skupinu strojov v klastri. V tomto prípade upravíme MachineConfigPool pre master uzly:
oc edit MachineConfigPool/master
Výstup (pre prehľadnosť je zachovaná základná esencia):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
V tomto momente MCO začína vytvárať nový súbor crio.conf pre klaster. Pri tom je možné celý pripravený konfiguračný súbor zobraziť prostredníctvom Kubernetes API. Pamätajte, ContainerRuntimeConfig je iba špecializovaná verzia MachineConfig, takže môžeme vidieť výsledok, keď sa pozrieme na potrebné riadky v MachineConfigs:
oc get MachineConfigs | grep rendered
Výstup:
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
Všimnite si, že získaný konfiguračný súbor pre master uzly je novšou verziou než pôvodné konfigurácie. Ak chcete zobraziť jeho obsah, spustite nasledujúci príkaz. Mimochodom, to je možno jeden z najlepších jednorázových skriptov v histórii 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
Výstup:
pids_limit = 2048
Teraz sa uistíme, že konfigurácia bola aplikovaná na všetky master uzly. Najprv získame zoznam uzlov v klastri:
oc get node | grep master
Výstup:
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
Teraz si pozrieme nainštalovaný súbor. Uvidíte, že súbor bol aktualizovaný s novými hodnotami direktív pid a debug, ktoré sme uviedli v zdroji ContainerRuntimeConfig. Samotná elegancia:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Výstup:
...
pids_limit = 2048
...
log_level = "debug"
...
Všetky tieto zmeny v klastri boli vykonané aj bez spustenia SSH. Celá práca bola vykonaná prostredníctvom volania na hlavný uzol Kubernetes. To znamená, že tieto nové parametre boli konfigurované iba na hlavných uzloch. Pracovné uzly pritom ostali nezmenené, čo dokazuje výhody metodológie Kubernetes pomocou definovaných a aktuálnych stavov vzhľadom na hostiteľské kontajnery a kontajnerové motory s vzájomne zameniteľnými prvkami.
Uvedený príklad ukazuje možnosť vykonávať zmeny v malom klastri OpenShift Container Platform 4 so tromi pracovnými uzlami alebo v obrovskom výrobném klastri so 3000 uzlami. V každom prípade objem práce bude rovnaký – a veľmi malý – stačí nakonfigurovať súbor ContainerRuntimeConfig a zmeniť jednu etiketu (label) v MachineConfigPool. A môžete to spraviť s ktoroukoľvek verziou používanou na platforme Kubernetes OpenShift Container Platform 4.X počas celého jej životného cyklu.
Technologické spoločnosti sa často vyvíjajú tak rýchlo, že nie sme schopní vysvetliť, prečo si vyberáme určité technológie pre základné komponenty. Kontajnerové motory boli historicky tým komponentom, s ktorým používatelia priamo interagovali. Keďže popularita kontajnerov prirodzene začínala s príchodom kontajnerových motorov, používatelia sa často o ne zaujímajú. To je ďalší dôvod, prečo sa Red Hat rozhodla pre CRI-O. Kontajnery sa vyvíjajú, pričom dnes sa primárna pozornosť zameriava na orchestráciu, a dospeli sme k záveru, že CRI-O poskytuje najlepší zážitok pri práci s OpenShift 4.
Zdroj: habr.com
