Контейнер – на конвеєр: CRI-O тепер за замовчуванням у OpenShift Container Platform 4

Платформа Контейнерна платформа Red Hat OpenShift 4 дозволяє поставити на потік створення хостів для розгортання контейнерів, у тому числі в інфраструктурі постачальників хмарних сервісів, на платформах віртуалізації або 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, що використовувався раніше, пропонуючи користувачам OpenShift економний, стабільний, простий та нудний - Так, ви не дочули - нудний контейнерний двигун, створений спеціально для роботи з Kubernetes.

Світ відкритих контейнерів

Світ уже давно рухається до відкритих контейнерів. Чи то в Kubernetes, чи на нижчих рівнях, розвиток контейнерних стандартів призводить до появи екосистеми інновацій кожному рівні.

Все почалося із створення ініціативи Open Containers Initiative у червні 2015 року. На цьому ранньому етапі роботи були сформовані специфікації контейнерного образу (image) и середовища виконання (runtime). Це дозволило гарантувати, що інструменти можуть використовувати єдиний стандарт контейнерних образів та єдиний формат для роботи з ними. Пізніше були додані специфікації дистрибуції (distribution)що дозволило користувачам з легкістю обмінюватися контейнерними образами.

Потім спільнота Kubernetes розробила єдиний стандарт інтерфейсу (pluggable interface), що отримав назву Інтерфейс часу виконання контейнера (CRI). Завдяки цьому користувачі Kubernetes змогли підключати різні двигуни для роботи з контейнерами на додаток до Docker.

Інженери Red Hat і Google побачили потребу в контейнерному движку, що існувала на ринку, який міг би приймати запити від Kubelet по протоколу CRI і представили контейнери, які були сумісні зі згаданими вище специфікаціями OCI. Так з'явився OCID. Але дозвольте, адже ми сказали, що цей матеріал буде присвячений CRI-O? Насправді так і є, просто із випуском версії 1.0 проект було перейменовано на CRI-O.

Рис. 1.

Інновації з CRI-O та CoreOS

Із запуском платформи OpenShift 4 було змінено контейнерний двигун, що використовується в платформі за замовчуванням, і на зміну Docker прийшов CRI-O, який запропонував економічне, стабільне, просте та нудне середовище для запуску контейнера, яке розвивається паралельно з Kubernetes. Це значно спрощує підтримку та конфігурацію кластера. Конфігурування контейнерного двигуна та хоста, а також керування ними стає автоматизованою в рамках OpenShift 4.

Стоп, як це?

Саме так, з появою OpenShift 4, тепер більше немає потреби підключатися до окремих хостів і встановлювати контейнерний двигун, конфігурувати сховище, настроювати сервери для пошуку або конфігурувати мережу. Платформа OpenShift 4 була повністю перероблена для використання the Operator Framework не тільки з точки зору програм кінцевих користувачів, але і з точки зору базових операцій на рівні платформи, таких як розгортання образів, конфігурування системи або встановлення оновлень.

Kubernetes завжди дозволяв користувачам керувати програмами, визначаючи бажаний стан та використовуючи контролери (Controllers)щоб гарантувати, що фактичний стан максимально відповідає заданому стану. Цей підхід з використанням заданого стану та фактичного стану відкриває великі можливості як з погляду розробки, і з погляду операцій. Розробники можуть визначити необхідний стан, передати його оператору у вигляді YAML або JSON файлу, а потім оператор може створити в експлуатаційному середовищі необхідний екземпляр програми, при цьому робочий стан цього екземпляра буде повністю відповідати заданому.

Використовуючи оператори (Operators) у платформі, OpenShift 4 привносить цю нову парадигму (з використанням концепції заданого та фактичного стану) в керування RHEL CoreOS та CRI-O. Завдання конфігурування та управління версіями операційної системи та контейнерного двигуна автоматизується за допомогою так званого оператора конфігурації машини (Machine Config Operator, MCO). MCO значно полегшує роботу адміністратора кластера, по суті автоматизуючи останні етапи установки, а також наступні операції після встановлення (day two operations). Все це робить OpenShift 4 справжньою хмарною платформою. Ми зупинимося на цьому трохи згодом.

Запуск контейнерів

Користувачі мали можливість використовувати двигун CRI-O у платформі OpenShift починаючи з версії 3.7 у статусі Tech Preview і з версії 3.9 у статусі Generally Available (підтримується в даний час). Крім того, Red Hat масово використовує CRI-O для запуску виробничих робочих навантажень в 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

Висновок:

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, та змінити одну мітку (label) у MachineConfigPool. І ви можете зробити це з будь-якою версією платформи OpenShift Container Platform 4.X, що використовується в Kubernetes, протягом усього її життєвого циклу.

Найчастіше технологічні компанії розвиваються настільки швидко, що ми можемо пояснити, чому ми вибираємо ті чи інші технології для базових компонентів. Контейнерні двигуни історично були тим компонентом, з яким користувачі взаємодіють безпосередньо. Оскільки популярність контейнерів закономірно починалася з появи контейнерних двигунів, користувачі часто виявляють до них зацікавленість. Це ще одна причина, чому Red Hat зупинила свій вибір на CRI-O. Контейнери розвиваються, при цьому сьогодні основна увага приділяється оркестровці, і ми дійшли висновку, що CRI-O забезпечує найкращий досвід роботи з OpenShift 4.

Джерело: habr.com