Platforma umožňuje zefektivnit tvorbu , a to i v infrastruktuře poskytovatelů cloudových služeb, na virtualizačních platformách nebo v bare-metal systémech. Abychom vytvořili skutečně cloudovou platformu, museli jsme převzít přísnou kontrolu nad všemi použitými prvky a zvýšit tak spolehlivost složitého automatizačního procesu.
Zřejmým řešením bylo použít Red Hat Enterprise Linux CoreOS (varianta Red Hat Enterprise Linux) a CRI-O jako standard, a zde je důvod, proč...
Protože téma plachtění je velmi dobré pro hledání analogií při vysvětlování práce Kubernetes a kontejnerů, zkusme si na příkladu promluvit o obchodních problémech, které CoreOS a CRI-O řeší. . V roce 1803 dostal Marc Brunel za úkol vyrobit 100 19 bloků lanoví pro potřeby rostoucího britského námořnictva. Takelážový blok je druh takeláže, která se používá k připevnění lan k plachtám. Až do samého počátku XNUMX. století se tyto bloky vyráběly ručně, Brunelovi se však podařilo zautomatizovat výrobu a začal vyrábět standardizované bloky pomocí obráběcích strojů. Automatizace tohoto procesu znamenala, že výsledné bloky byly prakticky identické, v případě rozbití se daly snadno vyměnit a mohly se vyrábět ve velkém množství.
Nyní si představte, že by Brunel musel tuto práci dělat pro 20 různých modelů lodí (verze Kubernetes) a pro pět různých planet se zcela odlišnými mořskými proudy a větry (poskytovatelé cloudu). Kromě toho bylo požadováno, aby se všechny lodě (klastry OpenShift) bez ohledu na planety, na kterých se provádí navigace, z pohledu kapitánů (operátorů, kteří řídí provoz shluků) chovaly stejně. Abychom pokračovali v námořní analogii, kapitány lodí vůbec nezajímá, jaké bloky lanoví (CRI-O) se na jejich lodích používají – jde jim především o to, aby tyto bloky byly pevné a spolehlivé.
OpenShift 4 jako cloudová platforma čelí velmi podobné obchodní výzvě. Nové uzly musí být vytvořeny při vytváření clusteru, v případě selhání jednoho z uzlů nebo při škálování clusteru. Když je vytvořen a inicializován nový uzel, musí být odpovídajícím způsobem nakonfigurovány kritické hostitelské komponenty, včetně CRI-O. Stejně jako v každé jiné výrobě musí být na začátku dodány „suroviny“. V případě lodí jsou surovinami kov a dřevo. V případě vytváření hostitele pro nasazení kontejnerů v clusteru OpenShift 4 však potřebujete jako vstup konfigurační soubory a servery poskytované rozhraním API. OpenShift pak poskytne požadovanou úroveň automatizace v průběhu celého životního cyklu, nabídne koncovým uživatelům potřebnou produktovou podporu a vrátí tak investici do platformy.
OpenShift 4 byl vytvořen tak, aby poskytoval možnost pohodlné aktualizace systému v průběhu celého životního cyklu platformy (pro verze 4.X) pro všechny hlavní poskytovatele cloud computingu, virtualizační platformy a dokonce i bare metal systémy. K tomu musí být uzly vytvořeny na základě zaměnitelných prvků. Když cluster vyžaduje novou verzi Kubernetes, obdrží také odpovídající verzi CRI-O na CoreOS. Vzhledem k tomu, že verze CRI-O je vázána přímo na Kubernetes, výrazně to zjednodušuje jakékoli permutace pro účely testování, odstraňování problémů nebo podpory. Tento přístup navíc snižuje náklady pro koncové uživatele a Red Hat.
Toto je zásadně nový způsob uvažování o clusterech Kubernetes a pokládá základ pro plánování některých velmi užitečných a působivých nových funkcí. CRI-O (Container Runtime Interface - Open Container Initiative, zkráceně CRI-OCI) se ukázalo jako nejúspěšnější volba pro hromadné vytváření uzlů, které jsou nutné pro práci s OpenShift. CRI-O nahradí dříve používaný engine Docker a nabídne uživatelům OpenShift – ano, slyšeli jste dobře – nudný kontejnerový engine vytvořený speciálně pro práci s Kubernetes.
Svět otevřených kontejnerů
Svět již dlouhou dobu směřuje k otevřeným kontejnerům. Ať už v Kubernetes nebo na nižších úrovních, výsledkem je ekosystém inovací na všech úrovních.
Vše začalo vytvořením iniciativy Open Containers Initiative . V této rané fázi práce byly vytvořeny specifikace kontejnerů и . To zajistilo, že nástroje mohly používat jeden standard a jednotný formát pro práci s nimi. Specifikace byly přidány později , což uživatelům umožňuje snadné sdílení .
Komunita Kubernetes poté vyvinula jednotný standard pro zásuvné rozhraní, tzv . Díky tomu mohli uživatelé Kubernetes kromě Dockeru připojit různé enginy pro práci s kontejnery.
Inženýři ze společností Red Hat a Google viděli na trhu potřebu kontejnerového motoru, který by mohl přijímat požadavky Kubelet přes protokol CRI, a představili kontejnery, které byly kompatibilní s výše uvedenými specifikacemi OCI. Tak . Ale promiňte, neřekli jsme, že tento materiál bude věnován CRI-O? Ve skutečnosti je, až s vydáním projekt byl přejmenován na CRI-O.
Obr. 1.
Inovace s CRI-O a CoreOS
S uvedením platformy OpenShift 4 došlo ke změně , který se v platformě standardně používá, a Docker byl nahrazen CRI-O, který nabízí cenově výhodné, stabilní, jednoduché a nudné prostředí pro provoz kontejneru, který se vyvíjí paralelně s Kubernetes. To výrazně zjednodušuje podporu a konfiguraci clusteru. Konfigurace kontejnerového enginu a hostitele, stejně jako jejich správa, se v rámci OpenShift 4 zautomatizují.
Počkej, jak to je?
Správně, s příchodem OpenShift 4 již není potřeba připojovat se k jednotlivým hostitelům a instalovat kontejnerový engine, konfigurovat úložiště, konfigurovat vyhledávací servery nebo konfigurovat síť. Platforma OpenShift 4 byla zcela přepracována pro použití nejen z hlediska aplikací pro koncové uživatele, ale také z hlediska základních operací na úrovni platformy, jako je nasazení bitových kopií, konfigurace systému nebo instalace aktualizací.
Kubernetes vždy umožňoval uživatelům spravovat aplikace definováním požadovaného stavu a používáním , aby se zajistilo, že se skutečný stav co nejvíce shoduje s cílovým stavem. Tento otevírá skvělé příležitosti jak z hlediska vývoje, tak z hlediska provozu. Vývojáři mohou definovat požadovaný stav pomocí operátorovi ve formě YAML nebo JSON souboru a následně může operátor vytvořit požadovanou instanci aplikace v produkčním prostředí a provozní stav této instance bude plně odpovídat zadanému.
Díky použití operátorů v platformě přináší OpenShift 4 toto nové paradigma (využívající koncept nastaveného a skutečného stavu) do správy RHEL CoreOS a CRI-O. Úlohy konfigurace a správy verzí operačního systému a kontejnerového enginu jsou automatizovány pomocí tzv . MCO výrazně zjednodušuje práci správci clusteru, v podstatě automatizuje poslední fáze instalace i následné operace po instalaci (operace den dva). To vše dělá z OpenShift 4 skutečnou cloudovou platformu. K tomu se dostaneme o něco později.
Běžící kontejnery
Uživatelé měli možnost využívat engine CRI-O v platformě OpenShift od verze 3.7 ve stavu Tech Preview a od verze 3.9 ve stavu Generally Available (aktuálně podporováno). Red Hat navíc masivně využívá v OpenShift Online od verze 3.10. To vše umožnilo týmu pracujícímu na CRI-O získat rozsáhlé zkušenosti s hromadným spouštěním kontejnerů na velkých clusterech Kubernetes. Abychom získali základní představu o tom, jak Kubernetes používá CRI-O, podívejme se na následující obrázek, který ukazuje, jak architektura funguje.
Rýže. 2. Jak fungují kontejnery v clusteru Kubernetes
CRI-O zjednodušuje vytváření nových hostitelů kontejnerů synchronizací celé nejvyšší úrovně při inicializaci nových uzlů a při vydávání nových verzí platformy OpenShift. Revize celé platformy umožňuje transakční aktualizace/rollbacky a také zabraňuje uváznutí v závislostech mezi jádrem kontejneru, kontejnerovým enginem, uzly (Kubelets) a uzlem Kubernetes Master. Díky centrální správě všech komponent platformy s kontrolou a verzováním je vždy jasná cesta ze stavu A do stavu B. To zjednodušuje proces aktualizace, zlepšuje zabezpečení, zlepšuje reporting výkonu a pomáhá snížit náklady na aktualizace a instalace nových verzí. .
Ukázka síly náhradních prvků
Jak již bylo zmíněno dříve, použití Machine Config Operator ke správě kontejnerového hostitele a kontejnerového enginu v OpenShift 4 poskytuje novou úroveň automatizace, která dříve na platformě Kubernetes nebyla možná. Abychom demonstrovali nové funkce, ukážeme si, jak můžete provést změny v souboru crio.conf. Abyste se nenechali zmást terminologií, zkuste se zaměřit na výsledky.
Nejprve vytvoříme to, čemu se říká konfigurace runtime kontejneru – Container Runtime Config. Představte si to jako prostředek Kubernetes, který představuje konfiguraci pro CRI-O. Ve skutečnosti se jedná o specializovanou verzi něčeho, co se nazývá MachineConfig, což je jakákoli konfigurace, která je nasazena na stroj RHEL CoreOS jako součást clusteru OpenShift.
Tento vlastní prostředek s názvem ContainerRuntimeConfig byl vytvořen, aby správcům clusteru usnadnil konfiguraci CRI-O. Tento nástroj je dostatečně výkonný, že jej lze použít pouze na určité uzly v závislosti na nastavení MachineConfigPool. Představte si to jako skupinu strojů, které slouží stejnému účelu.
Všimněte si posledních dvou řádků, které se chystáme změnit v souboru /etc/crio/crio.conf. Tyto dva řádky jsou velmi podobné řádkům v souboru crio.conf, jsou to:
vi ContainerRuntimeConfig.yaml
Závěr:
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
Nyní tento soubor vložíme do clusteru Kubernetes a zkontrolujeme, že byl skutečně vytvořen. Upozorňujeme, že operace je přesně stejná jako u jakéhokoli jiného zdroje Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Závěr:
NAME AGE
set-log-and-pid 22h
Jakmile vytvoříme ContainerRuntimeConfig, musíme upravit jeden z MachineConfigPools, aby signalizoval Kubernetes, že chceme tuto konfiguraci použít na konkrétní skupinu počítačů v clusteru. V tomto případě změníme MachineConfigPool pro hlavní uzly:
oc edit MachineConfigPool/master
Závěr (pro přehlednost je ponechána hlavní podstata):
...
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 okamžiku MCO začne vytvářet nový soubor crio.conf pro cluster. V tomto případě lze kompletně hotový konfigurační soubor zobrazit pomocí Kubernetes API. Pamatujte, že ContainerRuntimeConfig je pouze specializovaná verze MachineConfig, takže výsledek můžeme vidět pohledem na příslušné řádky v MachineConfigs:
oc get MachineConfigs | grep rendered
Závěr:
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
Upozorňujeme, že výsledný konfigurační soubor pro hlavní uzly byl novější verzí než původní konfigurace. Chcete-li jej zobrazit, spusťte následující příkaz. Mimochodem, poznamenáváme, že je to možná jeden z nejlepších jednořádkových linií v historii 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
Závěr:
pids_limit = 2048
Nyní se ujistíme, že konfigurace byla aplikována na všechny hlavní uzly. Nejprve získáme seznam uzlů v clusteru:
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
Nyní se podíváme na nainstalovaný soubor. Uvidíte, že soubor byl aktualizován o nové hodnoty pro direktivy pid a ladění, které jsme zadali v prostředku ContainerRuntimeConfig. Elegance sama o sobě:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Závěr:
...
pids_limit = 2048
...
log_level = "debug"
...
Všechny tyto změny v clusteru byly provedeny bez spuštění SSH. Veškerá práce byla provedena přístupem k hlavnímu uzlu Kuberentes. To znamená, že tyto nové parametry byly nakonfigurovány pouze na hlavních uzlech. Pracovní uzly se nezměnily, což demonstruje výhody metodiky Kubernetes používání specifikovaných a skutečných stavů ve vztahu ke kontejnerovým hostitelům a kontejnerovým enginům s vyměnitelnými prvky.
Výše uvedený příklad ukazuje možnost provádět změny v malém clusteru OpenShift Container Platform 4 se třemi produkčními uzly nebo v obrovském produkčním clusteru s 3000 4 uzly. V každém případě bude množství práce stejné – a velmi malé – stačí nakonfigurovat soubor ContainerRuntimeConfig a změnit jeden štítek v MachineConfigPool. A můžete to udělat s libovolnou verzí OpenShift Container Platform XNUMX.X, na které běží Kubernetes během celého životního cyklu.
Technologické společnosti se často vyvíjejí tak rychle, že nejsme schopni vysvětlit, proč volíme určité technologie pro základní komponenty. Kontejnerové motory byly historicky komponentou, se kterou uživatelé přímo komunikují. Protože popularita kontejnerů přirozeně začala s příchodem kontejnerových motorů, uživatelé o ně často projevovali zájem. To je další důvod, proč si Red Hat vybral CRI-O. Kontejnery se vyvíjejí se zaměřením na orchestraci a zjistili jsme, že CRI-O poskytuje nejlepší zkušenosti při práci s OpenShift 4.
Zdroj: www.habr.com