Четверта версія OpenShift вийшла порівняно недавно. Актуальна на даний момент версія 4.3 доступна з кінця січня і всі зміни в ній - це або щось нове, чого в третій версії не було, або велике оновлення того, що з'явилося у версії 4.1. Все, що ми зараз розповімо, потрібно знати, розуміти та враховувати тим, хто працює з OpenShift та планує переходити на нову версію.
З випуском версії OpenShift 4.2, Red Hat спростила роботу з Kubernetes. З'явилися нові інструменти та плагіни для створення контейнерів, CI/CD-конвеєрів та serverless-розгортань. Нововведення дають розробникам можливість зосередитись на написанні коду, а не на розглядах з Kubernetes.
Власне, що нового у версіях OpenShift 4.2 та 4.3?
Рух у бік гібридних хмар
При плануванні нової ІТ-інфраструктури або при розвитку ІТ-ландшафту компанії все частіше розглядають хмарний підхід у наданні ІТ-ресурсів, для чого реалізують приватні хмарні рішення, або використовують потужності публічних хмарних провайдерів. Таким чином, сучасні ІТ-інфраструктури все частіше будуються за «гібридною» хмарною моделлю, коли застосовуються як on-premises ресурси, так і публічні хмарні ресурси із загальною системою управління. Red Hat OpenShift 4.2 спеціально розроблений для спрощення переходу до моделі гібридної хмари та дозволяє легко підключати до кластера ресурси таких провайдерів, як AWS, Azure та Google Cloud Platform нарівні з використанням приватних хмар на VMware та OpenStack.
Новий підхід до інсталяції
У 4 версії змінився підхід до інсталяції OpenShift. Red Hat пропонує спеціальну утиліту для розгортання кластера OpenShift – openshift-install. Утиліта є єдиним бінарним файлом, написаним на Go. Openshit-installer готує yaml-файл із конфігурацією, необхідною для розгортання.
У разі інсталяції з використанням хмарних ресурсів потрібно вказати мінімальну інформацію про майбутній кластер: DNS-зону, кількість worker-вузлів, специфічні налаштування для хмарного провайдера, дані облікового запису для доступу до хмарного провайдера. Після підготовки конфігураційного файлу кластер може бути розгорнутий однією командою.
У разі інсталяції на власних обчислювальних ресурсах, наприклад, при використанні приватної хмари (підтримуються vSphere та OpenStack) або при інсталяції на bare metal серверах, знадобиться ручне налаштування інфраструктури – підготувати мінімальну кількість віртуальних машин або фізичних серверів, необхідну для створення Control Plane кластера, налаштувати мережеві служби. Після такого настроювання кластер OpenShift можна буде аналогічно створити однією командою утиліти openshift-installer.
Оновлення в інфраструктурі
Інтеграція з CoreOS
Ключове оновлення – це інтеграція з Red Hat CoreOS. Тепер master-ноди Red Hat OpenShift можуть працювати лише на новій ОС. Це безкоштовна операційна система Red Hat, яка призначена спеціально для контейнерних рішень. Red Hat CoreOS є полегшеним Linux, оптимізований для запуску контейнерів.
Якщо 3.11 операційна система і OpenShift існували окремо, то 4.2 вона нерозривно пов'язані з OpenShift. Тепер це єдиний appliance – immutable infrastructure.
Для кластерів, які використовують RHCOS для всіх вузлів, оновлення OpenShift Container Platform є простим та добре автоматизованим процесом.
Раніше, щоб оновити OpenShift, необхідно було спочатку оновити базову операційну систему, де продукт був запущений (тоді це була Red Hat Enterprise Linux). Тільки після цього можна було оновлювати OpenShift поступово, вузол за вузлом. Ні про яку автоматизацію процесу не йшлося.
Зараз, оскільки OpenShift Container Platform повністю контролює системи та служби на кожному вузлі, включаючи ОС, це завдання вирішується натисканням кнопки з веб-інтерфейсу. Після цього запускається спеціальний оператор усередині кластера OpenShift, який керує всім процесом оновлення.
Новий CSI
Друге – новий CSI – контролер storage-інтерфейсу, який дозволяє підключати різні зовнішні СГД до кластера OpenShift. Підтримується багато провайдерів storage-драйверів для OpenShift на базі storage-драйверів, які пишуть самі виробники СГД. Повний список підтримуваних CSI-драйверів можна знайти в цьому документі: . У цьому списку можна знайти всі основні моделі дискових масивів провідних виробників (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-рішень (Ceph) та хмарних сховищ (AWS, Azure, Google). OpenShift 4.2 підтримує роботу з драйверами CSI специфікації CSI версії 1.1.
RedHat OpenShift Service Mesh
Заснована на проектах Istio, Kiali та Jaeger - Red Hat OpenShift Service Mesh, окрім звичайних завдань маршрутизації запитів між службами дозволяє виконувати їх трасування та візуалізацію. Це допомагає розробникам спростити взаємодію, спостереження та керування додатком, розгорнутим усередині Red Hat OpenShift.
Візуалізація програми, що має мікросервісну архітектуру з використанням Kiali
Щоб максимально спростити процеси встановлення, сервісу та керування життєвим циклом Service Mesh, Red Hat OpenShift надає адміністраторам спеціальний оператор – Service Mesh Operator. Це оператор Kubernetes, який дозволяє розгорнути на кластері переконфігуровані пакети Istio, Kiali та Jaeger, максимально знімаючи адміністративне навантаження на керування програмами.
CRI-O замість Docker
Дефолтний контейнерний runtime Docker був замінений CRI-O. Скористатися CRI-O можна було вже у версії 3.11, але у 4.2 він став основним. Не добре і не погано, але варто мати на увазі під час використання продукту.
Оператори та деплой додатків
Оператори – нова сутність для RedHat OpenShift, яка з'явилася у четвертій версії. Це метод упаковки, розгортання та керування додатком Kubernetes. Його можна уявити, як керований за допомогою API Kubernetes та інструментів kubectl плагін для додатків, розгорнутих у контейнерах.
Оператори Kubernetes допомагають автоматизувати будь-які завдання, пов'язані з адмініструванням та керуванням життєвим циклом програми, яку ви розгортаєте у своєму кластері. Наприклад, оператор може автоматизувати оновлення, резервне копіювання та масштабування програми, змінювати конфігурацію тощо. Повний список операторів можна переглянути на .
OperatorHub доступний безпосередньо з веб-інтерфейсу консолі управління. Він є каталогом додатків для OpenShift, що підтримується Red Hat. Тобто. всі оператори, схвалені Red Hat, покриватимуться вендорською підтримкою.
Портал OperatorHub в консолі керування OpenShift
Universal base image
Це стандартизований набір образів ОС RHEL, які можна використовувати для створення додатків у контейнерах. Є мінімальний, стандартний та повний набори. Вони займають зовсім небагато місця, підтримують усі необхідні встановлені пакети та мови програмування.
Інструменти CI/CD
У RedHat OpenShif 4.2 з'явилася можливість вибрати між Jenkins та OpenShift Pipelines на базі Tekton Pipelines.
OpenShift Pipelines заснований на Tekton, який найкраще підтримують підходи Pipeline as Code та GitOps. У конвеєрах OpenShift кожен крок виконується у власному контейнері, тому ресурси використовуються лише під час виконання кроку. Це дає розробникам повний контроль над конвеєрами доставки модулів, плагінами та контролем доступу без центрального сервера CI/CD для керування.
OpenShift Pipelines в даний час знаходиться в стадії Preview для розробників і доступний як оператор на кластері OpenShift 4. Зрозуміло, користувачі OpenShift, як і раніше, можуть використовувати Jenkins в RedHat OpenShift 4.
Оновлення в управлінні для розробників
У 4.2 OpenShift повністю оновився веб-інтерфейс як розробників, так адміністраторів.
У попередніх версіях OpenShift усі працювали у трьох консолях: сервіс-каталог, адміністратор-консоль та work-консоль. Зараз кластер розділений лише на дві частини - administrator console та developer console.
Developer console отримала значні поліпшення інтерфейсу користувача. Тепер на ній зручніше відображаються топології додатків та їх складання. Це полегшує розробникам створення, розгортання та візуалізацію контейнерних додатків та кластерних ресурсів. Дозволяє зосередитись на тому, що для них важливо.
Портал розробника в консолі керування OpenShift
Одо
Odo — орієнтована на розробників утиліта командного рядка, що спрощує розробку програм OpenShift. Використовуючи взаємодію в стилі git push, цей CLI допомагає розробникам, не знайомим з Kubernetes, створювати програми OpenShift.
Інтеграція із середовищами розробки
Розробники тепер можуть створювати, налагоджувати та розгортати свої програми в OpenShift, не залишаючи своє улюблене середовище розробки коду, наприклад Microsoft Visual Studio, JetBrains (включаючи IntelliJ), Eclipse Desktop і т.д.
Red Hat OpenShift Deployment extension for Microsoft Azure DevOps
З'явилося розширення Red Hat OpenShift Deployment для Microsoft Azure DevOps. Тепер користувачі цього набору інструментів DevOps можуть розгортати свої програми в Azure Red Hat OpenShift або будь-якому іншому кластері OpenShift безпосередньо з Microsoft Azure DevOps.
Перехід із третьої версії на четверту
Оскільки йдеться про новий реліз, а не про оновлення, то не можна так просто взяти і поставити четверту версію поверх третьої. Оновлення з третьої на четверту версію не підтримуватиметься.
Але є і хороша новина: Red Hat надає інструменти для перенесення проектів із 3.7 до 4.2. Ви можете перенести робочі навантаження програм за допомогою інструмента Cluster Application Migration (CAM). CAM дозволяє контролювати міграцію та мінімізувати час простою програми.
OpenShift 4.3
Основні новації, описані в цій статті, з'явилися у версії 4.2. У нещодавно випущеній 4.3 зміни не такі значні, але все ж таки є дещо нове. Перелік змін досить великий, наведемо найбільш значущі на наш погляд:
Апдейт версії Kubernetes до 1.16.
Версія проапгрейдилась відразу на два кроки, OpenShift 4.2 була 1.14.
Шифрування даних etcd
Починаючи з версії 4.3, з'явилася можливість шифрувати дані базі etcd. Після включення шифрування буде можливе шифрування наступних ресурсів OpenShift API та Kubernetes API: Secrets, ConfigMaps, Routes, токенів доступу та авторизації OAuth.
Кермо
Додано підтримку Helm 3-ї версії – популярного пакетного менеджера для Kubernetes. Поки що підтримка має статус TECHNOLOGY PREVIEW. У майбутніх версіях OpenShift підтримку Helm буде розширено до повної. Утиліта helm cli поставляється разом із OpenShift і може бути завантажена з Web-консолі керування кластером.
Оновлення Project Dashboard
У новій версії Project Dashboard надає додаткову інформацію на сторінці проекту: статус проекту, утилізацію ресурсів та квоти для проекту.
Відображення вразливостей для quay у Web-консолі
У консоль управління додано функцію відображення відомих уразливостей для образів у репозиторіях Quay. Підтримується відображення вразливостей для локальних та зовнішніх репозиторіїв.
Спрощено створення офлайн operatorhub
Для розгортання кластера OpenShift в ізольованій мережі, доступ з якої в інтернет обмежений або відсутній, спрощено створення «дзеркала» для реєстру OperatorHub. Тепер це можна буде зробити лише трьома командами.
Автори:
Віктор Пучков, Юрій Семенюков
Джерело: habr.com