Платформа позволява да се оптимизира създаването на , включително в инфраструктурата на доставчици на облачни услуги, на виртуализационни платформи или в bare-metal системи. За да създадем истинска облачна платформа, трябваше да поставим под строг контрол всички използвани елементи и по този начин да увеличим надеждността на сложния автоматизационен процес.
Очевидното решение беше да се използва като стандарт Red Hat Enterprise Linux CoreOS (вариант на Red Hat Enterprise Linux) и CRI-O, и ето защо...
Тъй като темата за мореплаването е много подходяща за намиране на аналогии при обяснението на работата на Kubernetes и контейнерите, ще се опитаме да разкажем за бизнес-проблемите, които решават CoreOS и CRI-O, на примера на . През 1803 година пред Марк Брюнел беше поставена задача да изготви 100 хиляди такелажни блока за нуждите на нарастващия морски флот на Великобритания. Такелажният блок е тип оснастка, която се използва за прикрепване на въжета към платна. До самото начало на 19-ти век тези блокове се произвеждали ръчно, но Брюнел успява да автоматизира производството и да започне производството на стандартизирани блокове с помощта на машини. Автоматизацията на този процес означаваше, че в резултат всички блокове получаваха практически еднакъв вид, можеха да се заменят лесно в случай на повреда и да се произвеждат в големи количества.
А сега си представете, че Брюнел трябваше да извърши тази работа за 20 различни модела кораби (версии на Kubernetes) и за пет различни планети с напълно различни морски течения и ветрове (облачни доставчици). Освен това беше необходимо всички кораби (кластери OpenShift), независимо от планетите, по които се навигира, от гледна точка на капитаните (операторите, управляващи работата на кластерите), да се държат по един и същи начин. Продължавайки морската аналогия, капитаните на корабите изобщо не се интересуват какви такелажни блокове (CRI-O) се използват на техните кораби – за тях е важно тези блокове да са здрави и надеждни.
Преди OpenShift 4, като облачна платформа, стои много подобна бизнес задача. Новите нодове трябва да се създават в момента на създаването на клъстера, при повреда в един от възлите или при мащабиране на клъстера. При създаването и инициализацията на нов възел е необходимо съответно да се конфигурират и критичните компоненти на хоста, включително CRI-O. Както и в всяко друго производство, в началото е необходимо да се подаде "суровина". В случая на корабите, суровината са металът и дървесината. Но при създаването на хост за разгръщане на контейнери в клъстера OpenShift 4, на входа трябва да имате конфигурационни файлове и предоставяни API сървъри. След това OpenShift ще осигури необходимото ниво на автоматизация през целия жизнен цикъл, предлагайки нужното продуктово поддържане за крайни потребители и по този начин възвръщайки инвестициите в платформата.
OpenShift 4 е създадена така, че да осигури възможност за удобно обновление на системата през целия жизнен цикъл на платформата (за версии 4.X) за всички основни доставчици на облачни изчисления, платформи за виртуализация и дори bare metal системи. За това възлите трябва да се изградят на база взаимозаменяеми елементи. Когато клъстерът изисква нова версия на Kubernetes, той също получава съответната версия на CRI-O на CoreOS. Тъй като версията на CRI-O е пряко свързана с Kubernetes, всичко това значително опростява всякакви пренареждания с цел тестване, отстраняване на неизправности или поддръжка. Освен това, подобен подход позволява да се намалят разходите за крайните потребители и Red Hat.
Това е принципно нов поглед върху клъстерите Kubernetes, който полага основите за планиране на нови много полезни и привлекателни функции. CRI-O (проект на отворения контейнер Container Runtime Interface — Open Container Initiative, накратко CRI-OCI) се оказа най-удачният избор за масово създаване на възли, което е необходимо за работа с OpenShift. CRI-O заменя използвания преди това Docker engine, предлагайки на потребителите на OpenShift – да, не сте се объркали – скучен контейнерен двигател, създаден специално за работа с Kubernetes.
Светът на отворените контейнери
Светът отдавна се движи към отворените контейнери. Независимо дали става въпрос за Kubernetes или на по-ниски нива, води до появата на екосистема от иновации на всяко ниво.
Всичко започна със създаването на инициативата Open Containers Initiative . На този ранен етап бяха формулирани спецификациите на контейнерния и . Това позволи да се гарантира, че инструментите могат да използват единен стандарт и единен формат за работа с тях. По-късно бяха добавени спецификациите , което позволи на потребителите да обменят .
След това общността на Kubernetes разработи единен стандарт за свързващ интерфейс (pluggable interface), наречен . Благодарение на това потребителите на Kubernetes можеха да свързват различни движещи механизми за работа с контейнери в допълнение към Docker.
Инженерите на Red Hat и Google забелязаха съществуващото на пазара търсене за контейнерен двигател, който да може да приема заявки от Kubelet по протокола CRI и представиха контейнери, които бяха съвместими с гореспоменатите спецификации на OCI. Така Но извинете, ние казахме, че този материал ще бъде посветен на CRI-O? Всъщност е така, просто с пускането на проектът беше преименуван на CRI-O.
Рис. 1.
Иновации с CRI-O и CoreOS
С пускането на платформата OpenShift 4, беше променен , използван в платформата по подразбиране, и на мястото на Docker дойде CRI-O, който предложи икономична, стабилна, проста и скучна среда за стартиране на контейнери, която се развива паралелно с Kubernetes. Това значително улеснява поддръжката и конфигурацията на клъстера. Конфигурирането на контейнерния двигател и хоста, както и управлението им, става автоматизирано в рамките на OpenShift 4.
Стоп, какво?
Точно така, с появата на OpenShift 4, вече няма нужда да се свързвате с отделни хостове и да инсталирате контейнерния двигател, да конфигурирате хранилището, да настройвате сървъри за търсене или да конфигурирате мрежата. Платформата OpenShift 4 е изцяло преработена, за да използва не само от гледна точка на приложенията на крайните потребители, но и от гледна точка на основните операции на платформата, като разгръщане на образи, конфигуриране на системата или инсталиране на актуализации.
Kubernetes винаги е позволявал на потребителите да управляват приложения, определяйки желаното състояние и използвайки , за да гарантира, че фактическото състояние максимално отговаря на зададеното състояние. Този открива большие възможности както от гледна точка на разработка, така и от гледна точка на операции. Разработчиците могат да определят необходимото състояние, на оператора под формата на YAML или JSON файл, а след това операторът може да създаде в експлоатационната среда необходимия екземпляр на приложението, като работното състояние на този екземпляр ще съответства изцяло на зададеното.
Използвайки оператори (Operators) в платформата, OpenShift 4 внася тази нова парадигма (чрез концепцията за зададено и фактическо състояние) в управлението на RHEL CoreOS и CRI-O. Задачите по конфигуриране и управление на версиите на операционната система и контейнерния двигател се автоматизират с помощта на така наречения . MCO значително улеснява работата на администратора на кластера, като автоматизира последните етапи на инсталацията, както и последващите операции след инсталацията (day two operations). Всичко това прави OpenShift 4 истинска облачна платформа. Ще се спрем на това малко по-късно.
Стартиране на контейнери
Потребителите имаха възможност да използват двигателя CRI-O в платформата OpenShift, започвайки от версия 3.7 в статус Tech Preview и от версия 3.9 в статус Generally Available (в момента се поддържа). Освен това, Red Hat масово използва в OpenShift Online от версия 3.10. Всичко това позволи на екипа, работещ над CRI-O, да получи огромен опит в масовото стартиране на контейнери на големи клъстери Kubernetes. За да получим основни представа за това как Kubernetes използва CRI-O, да разгледаме следната илюстрация, която показва принципа на работа на архитектурата.
Рис. 2. Как работят контейнерите в клъстера Kubernetes
CRI-O опростява създаването на нови контейнерни хостове, като синхронизира целия слой при инициализация на нови възли, а също и при пускане на нови версии на платформата OpenShift. Ревизията на цялата платформа позволява извършването на транзакционни актуализации / откати и предотвратява взаимни блокировки в зависимостите между ядрото на контейнерния хост, контейнерния двигател, възлите (Kubelets) и главния възел на Kubernetes Master. При централизиран контрол над всички компоненти на платформата, с управление на версиите, можем винаги да проследим ясния път от състояние A до състояние B. Това опростява процеса на актуализации, увеличава сигурността, подобрява отчетността за производителността и помага за намаляване разходите за актуализации и инсталиране на нови версии.
Демонстрация на мощността на сменяеми елементи
Както беше споменато по-рано, използването на Machine Config Operator за управление на контейнерния хост и контейнерния двигател в OpenShift 4 осигурява ново ниво на автоматизация, което не беше възможно на платформата Kubernetes преди. За да демонстрираме новите възможности, ще покажа как можете да направите промени в файла crio.conf. За да не се объркате с терминологията, опитайте се да се концентрирате върху резултатите.
Първо, нека създадем това, което се нарича конфигурация на контейнерната среда – Container Runtime Config. Можете да го смятате за ресурс Kubernetes, който представлява конфигурацията за CRI-O. Всъщност, това е специализирана версия на т.нар. MachineConfig, която представлява всяка конфигурация, внедрена на машина RHEL CoreOS в рамките на клъстера OpenShift.
Тази персонализирана структура, наречена ContainerRuntimeConfig, е измислена, за да улесни администраторите на клъстера при настройването на CRI-O. Това е достатъчно мощен инструмент, който може да се прилага само за определени възли в зависимост от настройките на MachineConfigPool. Можете да го смятате за група машини, които служат за една и съща цел.
Обърнете внимание на последните две реда, които ще променим в файла /etc/crio/crio.conf. Тези две реда много приличат на редовете в файла crio.conf, а именно:
vi ContainerRuntimeConfig.yaml
Изход:
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
Сега ще изпратим този файл в клъстера Kubernetes и ще проверим дали наистина е създаден. Обърнете внимание, че работата се извършва точно както с всякакъв друг ресурс на Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Изход:
ИМЕ ВЪЗРАСТ
set-log-and-pid 22ч
След като създадохме ContainerRuntimeConfig, трябва да променим един от MachineConfigPools, за да уведомим Kubernetes, че искаме да приложим тази конфигурация към определена група машини в клъстера. В този случай ще променим MachineConfigPool за главните възли:
oc edit MachineConfigPool/master
Изход (за илюстрация основната същност е оставена):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
В този момент MCO започва да създава нов файл crio.conf за клъстера. Докато това се случва, напълно готовият файл за конфигурация може да бъде прегледан чрез API на Kubernetes. Запомнете, ContainerRuntimeConfig е просто специализирана версия на MachineConfig, затова можем да видим резултата, като погледнем нужните редове в MachineConfigs:
oc get MachineConfigs | grep rendered
Изход:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16ч
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4м
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16ч
Обърнете внимание, че получените конфигурации за главните възли са по-нова версия от оригиналните конфигурации. За да го видите, изпълнете следната команда. Между другото, отбелязваме, че това е, възможно, един от най-добрите еднострочни скриптове в историята на 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
Изход:
pids_limit = 2048
Сега да се уверим, че конфигурацията е приложена към всички главни възли. Първо, ще получим списък с възли в клъстера:
oc get node | grep master
Изход:
ip-10-0-135-153.us-east-2.compute.internal Готов master 23ч v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Готов master 23ч v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Готов master 23ч v1.12.4+509916ce1
Сега да прегледаме инсталирания файл. Ще видите, че файлът е актуализиран с новите стойности на директивите pid и debug, които посочихме в ресурса ContainerRuntimeConfig. Самата елегантност:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Изход:
...
pids_limit = 2048
...
log_level = "debug"
...
Всички тези промени в кластера бяха направени дори без стартиране на SSH. Цялата работа беше извършена, като се обърнахме към мастер-узела на Kuberentes. Тоест, тези нови параметри бяха конфигурирани само на мастер-узлите. Работните узли не бяха променяни, което демонстрира предимствата на методологията Kubernetes, използвайки зададени и актуални състояния, съобразени с контейнерните хостове и контейнерните двигатели с взаимозаменяеми елементи.
Примерът по-горе показва възможността да се правят промени в малък кластер на OpenShift Container Platform 4 с три работни нодове или в огромен производствен кластер с 3000 нода. Във всеки случай обемът на работата ще бъде идентичен – и много малък – достатъчно е да се настрои файлът ContainerRuntimeConfig и да се промени една етикет (label) в MachineConfigPool. И можете да направите това с всяка версия на използваната платформа Kubernetes OpenShift Container Platform 4.X в течение на целия ѝ жизнен цикъл.
Често технологичните компании се развиват толкова бързо, че не можем да обясним защо избираме определени технологии за основните компоненти. Контейнерните двигатели исторически са били компонентът, с който потребителите взаимодействат директно. Поради естествената популярност на контейнерите, която започна с появата на контейнерните двигатели, потребителите често проявяват интерес към тях. Това е още една причина, поради която Red Hat избра CRI-O. Контейнерите се развиват, като днес основното внимание е върху оркестрацията, и стигаме до извода, че CRI-O предлага най-доброто преживяване при работа с OpenShift 4.
Източник: habr.com
