Четвъртата версия на OpenShift излезе сравнително наскоро. Актуалната версия 4.3 е налична от края на януари и всички промени в нея са или нещо съвсем ново, което не е било налично в третата версия, или значителни актуализации на функционалности от версия 4.1. Всичко, което ще споделим, е необходимо да се знае, разбира и отчита от тези, които работят с OpenShift и планират преминаване към новата версия.
С пускането на версия OpenShift 4.2 Red Hat опрости работата с Kubernetes. Появиха се нови инструменти и плъгини за създаване на контейнери, CI/CD потоци и безсървърни разгръщания. Нововъведенията дават на разработчиците възможност да се съсредоточат върху писането на код, а не да се бъркат в Kubernetes.
Всъщност, какво ново има в версиите OpenShift 4.2 и 4.3?
Движение към хибридни облаци
При планирането на нова ИТ инфраструктура или при развитието на съществуващия ИТ ландшафт компаниите все по-често разглеждат облачния подход за предоставяне на ИТ ресурси, реализирайки частни облачни решения или използвайки мощностите на публични облачни доставчици. По този начин, съвременните ИТ инфраструктури все повече се изграждат по хибриден облачен модел, като се използват както локални ресурси, така и публични облачни ресурси с обща система за управление. Red Hat OpenShift 4.2 е специално проектиран за опростяване на прехода към модела на хибридно облако и позволява лесно свързване на кластера с ресурси от доставчици като AWS, Azure и Google Cloud Platform наред с използването на частни облаци на VMware и OpenStack.
Нов подход към инсталацията
В четвъртата версия се промени подходът към инсталацията на OpenShift. Red Hat предоставя специален инструмент за разгръщане на кластера OpenShift – openshift-install. Инструментът е единствен бинарен файл, написан на Go. Openshift-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. Сега това е единен апарат – 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
Универсален базов образ
Това е стандартизиран набор от образи на ОС RHEL, които могат да се използват за изграждане на вашите приложения в контейнери. Има минимални, стандартни и пълни набори. Те заемат много малко място, поддържат всички необходими инсталирани пакети и езици за програмиране.
CI/CD инструменти
В RedHat OpenShift 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 всичко работеше в три конзоли: каталог на услуги, администраторска конзола и работна конзола. Сега клъстерът е разделен само на две части — администраторска конзола и консола за разработчици.
Консолата за разработчици получи значителни подобрения в потребителския интерфейс. Сега в нея по-удобно се показват топологии на приложенията и техните сборки. Това улеснява разработчиците да изграждат, разгръщат и визуализират контейнерни приложения и клъстерни ресурси. Позволява им да се фокусират върху това, което е наистина важно за тях.
Портал на разработчика в консолата за управление на OpenShift
Odo
Odo е насочен към разработчици инструмент за команден ред, който опростява разработката на приложения в OpenShift. Използвайки взаимодействие в стил git push, този CLI помага на разработчици, които не са запознати с Kubernetes, да изграждат приложения в OpenShift.
Интеграция с разработчиците на среди
Разработчиците сега могат да изграждат, отстраняват грешки и разгръщат своите приложения в OpenShift, без да напускат любимата си среда за разработка на код, като Microsoft Visual Studio, JetBrains (включително IntelliJ), Eclipse Desktop и др.
Разширение за разгръщане на Red Hat OpenShift за 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
Добавена е поддръжка за Helm версия 3 – популярен пакетен мениджър за Kubernetes. В момента поддръжката е в статус TECHNOLOGY PREVIEW. В бъдещи версии на OpenShift поддръжката за Helm ще бъде разширена до пълна. Утилитата helm cli идва с OpenShift и може да бъде изтеглена от уеб конзолата за управление на кластера.
Актуализация на Project Dashboard
В новата версия Project Dashboard предоставя допълнителна информация на страницата на проекта: статус на проекта, увеличаване на ресурси и квоти за проекта.
Показване на уязвимости за quay в уеб конзолата
Функцията за показване на известни уязвимости за образи в репозиториите Quay е добавена в административната конзола. Поддържа се показването на уязвимости както за локални, така и за външни репозитории.
Оптимизирано създаване на офлайн operatorhub
За инсталация на клъстер OpenShift в изолирана мрежа, достъпът до интернет в която е ограничен или отсъства, е опростено създаването на 'зеркало' за регистра на OperatorHub. Сега това може да се направи само с три команди.
Автори:
Виктор Пучков, Юрий Семенюков
Източник: habr.com
