Платформа ви позволява да рационализирате създаването , включително в инфраструктурата на доставчици на облачни услуги, на платформи за виртуализация или в системи без метал. За да създадем една наистина базирана на облак платформа, трябваше да поемем строг контрол върху всички използвани елементи и по този начин да увеличим надеждността на сложен процес на автоматизация.
Очевидното решение беше да се използва Red Hat Enterprise Linux CoreOS (вариант на Red Hat Enterprise Linux) и CRI-O като стандарт и ето защо...
Тъй като темата за навигацията е много добра за намиране на аналогии при обясняване на работата на Kubernetes и контейнерите, нека се опитаме да поговорим за бизнес проблемите, които CoreOS и CRI-O решават, използвайки пример . През 1803 г. Марк Брунел получава задачата да направи 100 19 такелажни блока за нуждите на нарастващия британски флот. Такелажният блок е вид такелаж, който се използва за закрепване на въжета към платна. До самото начало на XNUMX-ти век тези блокове са правени на ръка, но Brunel успява да автоматизира производството и започва да прави стандартизирани блокове с помощта на машинни инструменти. Автоматизирането на този процес означава, че резултатът е, че всички блокове са почти еднакви, могат лесно да бъдат заменени в случай на повреда и могат да бъдат произведени в големи количества.
Сега си представете, че Брунел трябваше да свърши тази работа за 20 различни модела кораби (версии на Kubernetes) и за пет различни планети с напълно различни морски течения и ветрове (доставчици на облаци). Освен това се изискваше всички кораби (клъстери OpenShift), независимо от планетите, на които се извършва навигация, от гледна точка на капитаните (оператори, които управляват работата на клъстерите) да се държат еднакво. За да продължа морската аналогия, капитаните на кораби изобщо не се интересуват какви такелажни блокове (CRI-O) се използват на техните кораби - основното за тях е тези блокове да са здрави и надеждни.
OpenShift 4, като облачна платформа, е изправена пред много подобно бизнес предизвикателство. Нови възли трябва да бъдат създадени по време на създаването на клъстера, в случай на повреда в един от възлите или при мащабиране на клъстера. Когато създавате и инициализирате нов възел, критичните хост компоненти, включително CRI-O, трябва да бъдат съответно конфигурирани. Както във всяко друго производство, в началото е необходимо да се подадат "суровини". При корабите като суровини се използват метал и дърво. Въпреки това, в случай на създаване на хост за разполагане на контейнери в клъстер OpenShift 4, трябва да имате конфигурационни файлове и сървъри, предоставени от API като вход. След това OpenShift ще осигури правилното ниво на автоматизация през целия жизнен цикъл, предлагайки необходимата продуктова поддръжка за крайните потребители и по този начин възвръщайки инвестицията в платформата.
OpenShift 4 е създаден по такъв начин, че да осигури възможността за удобно актуализиране на системата през целия жизнен цикъл на платформата (за версии 4.X) за всички основни доставчици на облачни изчисления, платформи за виртуализация и дори голи метални системи. За да направите това, възлите трябва да бъдат създадени на базата на взаимозаменяеми елементи. Когато даден клъстер изисква нова версия на Kubernetes, той също получава съответната версия на CRI-O на CoreOS. Тъй като версията CRI-O е свързана директно с Kubernetes, това значително опростява всякакви пермутации за целите на тестване, отстраняване на неизправности или поддръжка. В допълнение, този подход намалява разходите за крайните потребители и Red Hat.
Това е фундаментално нов начин на мислене за клъстерите на Kubernetes и поставя основата за планиране на някои много полезни и завладяващи нови функции. CRI-O (Container Runtime Interface - Open Container Initiative, съкратено CRI-OCI) се оказа най-успешният избор за масово създаване на възли, необходими за работа с OpenShift. CRI-O ще замени използвания преди това Docker двигател, предлагайки потребители на OpenShift – да, чухте правилно – скучен контейнерен двигател, създаден специално за работа с Kubernetes.
Светът на отворените контейнери
Светът отдавна върви към отворени контейнери. Независимо дали е в Kubernetes или на по-ниски нива, води до екосистема от иновации на всяко ниво.
Всичко започна със създаването на Open Containers Initiative . На този ранен етап от работата спецификациите на контейнера и . Това гарантира, че инструментите могат да използват един стандарт и единен формат за работа с тях. Спецификациите са добавени по-късно , което позволява на потребителите лесно да споделят .
След това общността на Kubernetes разработи единен стандарт за pluggable интерфейс, наречен . Благодарение на това потребителите на 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 файл и след това операторът може да създаде необходимия екземпляр на приложението в производствената среда и работното състояние на този екземпляр ще съответства напълно на указаното.
Чрез използването на оператори в платформата OpenShift 4 въвежда тази нова парадигма (използвайки концепцията за набор и действително състояние) към управлението на RHEL CoreOS и CRI-O. Задачите по конфигуриране и управление на версии на операционната система и контейнерния двигател са автоматизирани с помощта на т.нар. . MCO значително опростява работата на администратора на клъстера, като по същество автоматизира последните етапи на инсталиране, както и последващите операции след инсталирането (операции от втория ден). Всичко това прави OpenShift 4 истинска облачна платформа. Ще разгледаме това малко по-късно.
Течащи контейнери
Потребителите са имали възможността да използват CRI-O двигателя в платформата OpenShift от версия 3.7 в състояние на Tech Preview и от версия 3.9 в състояние на общодостъпен (поддържа се в момента). В допълнение, Red Hat масово използва в OpenShift Online от версия 3.10. Всичко това позволи на екипа, работещ върху CRI-O, да придобие богат опит в масовото стартиране на контейнери на големи клъстери Kubernetes. За да получите основно разбиране за това как Kubernetes използва CRI-O, нека да разгледаме следната илюстрация, която показва как работи архитектурата.
Ориз. 2. Как работят контейнерите в клъстер на Kubernetes
CRI-O опростява създаването на нови хостове на контейнери чрез синхронизиране на цялото най-високо ниво при инициализиране на нови възли и при пускане на нови версии на платформата OpenShift. Преразглеждането на цялата платформа позволява транзакционни актуализации/връщания назад и също така предотвратява задънени блокировки в зависимостите между ядрото на опашката на контейнера, двигателя на контейнера, възлите (Kubelets) и основния възел Kubernetes. Чрез централно управление на всички компоненти на платформата, с контрол и управление на версиите, винаги има ясен път от състояние А до състояние Б. Това опростява процеса на актуализиране, подобрява сигурността, подобрява отчитането на производителността и помага за намаляване на разходите за актуализации и инсталации на нови версии .
Демонстрация на силата на взаимозаменяемите елементи
Както бе споменато по-рано, използването на 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
Заключение:
NAME AGE
set-log-and-pid 22h
След като създадем 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 за клъстера. В този случай напълно готовият конфигурационен файл може да се види с помощта на Kubernetes API. Не забравяйте, че ContainerRuntimeConfig е само специализирана версия на MachineConfig, така че можем да видим резултата, като разгледаме съответните редове в MachineConfigs:
oc get MachineConfigs | grep rendered
Заключение:
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
Моля, имайте предвид, че полученият конфигурационен файл за главните възли е по-нова версия от оригиналните конфигурации. За да го видите, изпълнете следната команда. Мимоходом отбелязваме, че това е може би един от най-добрите едноредови в историята на 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
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
Сега нека да разгледаме инсталирания файл. Ще видите, че файлът е актуализиран с новите стойности за директивите 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 и променете един етикет в MachineConfigPool. И можете да направите това с всяка версия на OpenShift Container Platform 4.X, работеща с Kubernetes през целия й жизнен цикъл.
Често технологичните компании се развиват толкова бързо, че не можем да обясним защо избираме определени технологии за основните компоненти. Контейнерните двигатели исторически са били компонентът, с който потребителите взаимодействат директно. Тъй като популярността на контейнерите естествено започна с появата на двигатели за контейнери, потребителите често проявяват интерес към тях. Това е още една причина, поради която Red Hat избра CRI-O. Контейнерите се развиват с акцент сега върху оркестрацията и ние открихме, че CRI-O предоставя най-доброто изживяване при работа с OpenShift 4.
Източник: www.habr.com