кластер openshift что это

Тестирование в Openshift: Внутреннее устройство кластера

Это продолжение серии из трех статей (первая статья, третья статья) об автоматизированном тестировании программных продуктов в Openshift Origin. В данной статье будут описаны основные объекты Openshift, а также описаны принципы работы кластера. Я осознано не делаю попытку описать все возможные объекты и их особенности, так как это очень трудоемкая задача, которая выходит за рамки данной статьи.

Кластер:

В целом работа кластера Openshift Origin не сильно отличается от других решений. Поступающие задачи распределяются по рабочим узлам на основе их загруженности, данное распределение берет на себя планировщик.

Для запуска контейнеров требуется Docker образа, которые могут быть загружены из внутреннего или внешнего регистра. Непосредственно запуск контейнеров происходит в различных контекстах безопасности (политики безопасности, которые ограничивают доступ контейнера к различным ресурсам).

По умолчанию контейнеры из разных проектов могут коммуницировать друг с другом с помощью overlay сети (выделяется одна большая подсеть, которая разбивается на более мелкие подсети для всех рабочих узлов кластера). Запущенному на рабочем узле контейнеру выделяется IP-адрес из той подсети, которая была назначена данному узлу. Сама overlay сеть построена на базе Open vSwitch, который использует VXLAN для связи между рабочими узлами.

На каждом рабочем узле запускается выделенныё экземпляр Dnsmasq, который перенаправляет все DNS запросы контейнеров на SkyDNS во внутреннюю сервисную подсеть.

Если контейнер аварийно завершил свою работу или просто не может быть проинициализирован, то задача по его развертыванию передается на другой рабочий узел.

Стоит отметить что:

SELinux не является строгим условием работы кластера. Отключение оного (не рекомендуется по соображениям безопасности) привнесет некое увелечение скорости (равно как и отключение мониторинга, кстати) при работе с контейнерами. Если SELinux мешает работе приложения в контейнере, присутствует возможность добавления исключения SELinux непосредственно на рабочем узле кластера.

По умолчанию используется LVM в качестве хранилища Docker Engine. Это далеко не самое быстрое решение, но можно использовать любой другой тип хранилища (BTRFS, например).

Стоит иметь ввиду, что название сервиса (см. Service) — это DNS имя, которое влечет за собой ограничения на длину и допустимые символы.

Чтобы сократить временные и аппаратные издержки при сборке Docker образов можно использовать так называемый «слоистый» подход (multi-stage в Docker). В данном подходе используются базовые и промежуточные образа, которые дополняют друг друга. Имеем базовый образ «centos:7» (полностью обновлен), имеем промежуточный образ «centos:7-tools» (установлены иструменты), имеем финальный образ «centos:7-app» (содержит «centos:7» и «centos:7-tools»). То есть вы можете создавать задачи сборки, которые основываются на других образах (см. BuildConfig).

Достаточно гибким решением является подход, когда существует один проект, который занимается только сборкой Docker образов с последующей «линковкой» данных образов в другие проекты (см. ImageStream). Это позволяет не плодить лишних сущностей в каждом проекте и приведет к некой унификации.

Большинству объектов в кластере можно присвоить произвольные метки, с помощью которых можно совершать массовые операции над данными объектами (удаление определенных контейнеров в проекте, например).

Стоит сразу побеспокоиться об удалении старых образов и забытых окружений. Если первое решается с помощью сборщика мусора/oadm prune, то второе требует проработки и ознакомлении всех участников с правилами совместной работы в Openshift Origin.

Любой кластер ограничен ресурсами, поэтому очень желательно организовать мониторинг хотя бы на уровне рабочих узлов (возможен мониторинг на уровне приложения в контейнере). Сделать это можно как с помощью готового решения Openshift Metrics, так и с помощью сторонних решений (Sysdig, например). При наличии метрик загруженности кластера (в целом или по проектно) можно организовать гибкую диспетчерезацию поступающих задач.

Особенно хочется отметить тот факт, что рабочие узлы могут быть динамически проинициализированы, а это значит, что вы можете расширить свой кластер Openshift Origin на существующих мощностях IaaS. То есть, во время предрелизного тестирования вы можете существенно расширить свои мощности и сократить время тестирования.

Объекты:

Project — объект является Kubernetes namespace. Верхний уровень абстракции, который содержит другие объекты. Созданные в проекте объекты не пересекаются с объектами в других проектах. На проект могут быть выставлены квоты, привилегии, метки узлов кластера и т.д. Вложенная иерархия и наследование между проектами отсутствуют, доступна «плоская» структура проектов. Существуюет несколько системных проектов (kube-system, openshift, openshift-infra), которые предназначены для нормального функционирования кластера.

Создание нового проекта:

Редактирование настроек проекта:

Pod — объект, который стал одним из решающих факторов, так как позволяет запускать произвольные команды внутри контейнера с помощью специальных хуков (и не только). Pod является основной рабочей единицей в кластере. Любой запущенный в кластере контйенер — Pod. По своей сути — группа из одного и более контейнеров, которые работают в единых для этих контейнеров namespaces (network, ipc, uts, cgroup), используют общее хранилище данных, секреты. Контейнеры, из которых состоит Pod, всегда запущены на одном узле кластера, а не распределены в одинаковых пропорциях по всем узлам (если Pod будет состоять из 10 контейнеров, все 10 будут работать на одном узле).

Secret — может являться строкой или файлом, предназначен для проброса чувствительной (хранится в открытом виде в etcd (поддержка шифрования в Kubernetes 1.7)) информации в Pod. Один Secret может содержать множество значений.

Использование Secret в BuildConfig:

ServiceAccount — специальный тип объекта, который предназначен для взаимодействия с ресурсам кластера. По своей сути является системным пользователем.

По умолчанию новый проект содержит три ServiceAccount:

Перечисленные служебные аккаунты:

Добавление прав администратора проекта ServiceAccount:

DeploymentConfig — это объект, который оперирует всё теми же Pod, но при этом привносит ряд дополнительных механизмов для управления жизненным циклом запущенных приложений, а именно:

ImageStream — по своей сути является «контейнером» для «ссылок» (ImageStreamTag), которые указывают на Docker образа или другие ImageStream.

Создание тага/ссылки на Docker образ между проектами:

Создание тага/ссылки на Docker образ, который расположен на Docker Hub:

BuildConfig — объект является сценарием того, как будет собран Docker образ и куда он будет помещен. Сборка нового образа может базироваться на других образах, за это отвечает секция «from:»

Источники сборки (то место, где размещены исходные данные для сборки):

Стратегии сборки (каким образом следует интерпретировать источник данных):

Назначение сборки (куда будет выгружен собранный образ):

Какие операции выполнит данный BuildConfig:

Service — объект, который стал одним из решающих факторов при выборе системы запуска сред, так как он позволяет гибко настраивать коммуникации между средами (что очень важно в тестировании). В случаях с использованием других систем требовались подготовительные манипуляции: выделить диапазоны IP-адресов, зарегистрировать DNS имена, осуществить проброс портов и т.д. и т.п. Service может быть объявлен до фактического развертывания приложения.

Что происходит во время публикации сервиса в проекте:

Разрешение DNS имени:

Заключение:

Все объекты кластера можно описать с помощью YAML, это, в свою очередь, дает возможность полностью автоматизировать любые процессы, которые протекают в Openshift Origin. Вся сложность в работе с кластером заключается в знании приципов работы и механизмов взаимодействия объектов. Такие рутинные операции как инициализация новых рабочих узлов берут на себя сценарии Ansible. Доступность API открывает возможность работать с кластером напрямую минуя посредников.

Источник

Руководство по созданию кластера Azure Red Hat OpenShift 4

В этом учебнике (часть 1 из 3) вы подготовите среду для создания кластера Azure Red Hat OpenShift с OpenShift 4 и создадите кластер. Вы узнаете, как:

Перед началом

Для создания и запуска кластера OpenShift в Azure Red Hat OpenShift требуется не менее 40 ядер. Стандартная квота ресурсов Azure для новой подписки Azure не соответствует этому требованию. Чтобы запросить увеличение ограничений ресурсов, см. статью об увеличении ограничений для различных серий виртуальных машин.

Например, чтобы проверить квоту текущей подписки для наименьшего поддерживаемого SKU семейства виртуальных машин Standard DSv3, используйте такую команду:

Секрет для извлечения ARO не изменяет цену лицензии RH OpenShift для ARO.

Проверка разрешений

При работе с этим учебником будет создана группа ресурсов, в которой будет содержаться виртуальная сеть для кластера. Необходимо иметь разрешения «Участник» и «Администратор доступа пользователей» или разрешения «Владелец» либо непосредственно для виртуальной сети, либо для группы ресурсов или подписки, содержащей ее.

Кроме того, для создания приложения и субъекта-службы от вашего имени для кластера вам потребуются достаточные разрешения Azure Active Directory (пользователь — член клиента или пользователь-гость с ролью администратор приложений). Дополнительные сведения см. в статьях Пользователи — члены и гости и Назначение ролей администратора и других ролей пользователям с помощью Azure Active Directory.

Регистрация поставщиков ресурсов

Если у вас несколько подписок Azure, выберите нужный идентификатор подписки:

Предварительные версии функций ARO доступны на уровне самообслуживания. Предварительные версии функций предоставляются «как есть» и «как доступно», на них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии функций предоставляются с частичной клиентской поддержкой по мере возможности. Следовательно, эти функции не предназначены для использования в рабочей среде.

Получение секрета для извлечения Red Hat (необязательно)

Секрет для извлечения Red Hat позволяет вашему кластеру получать доступ к реестрам контейнера Red Hat и дополнительному содержимому. Этот шаг необязателен, но мы рекомендуем его выполнить.

Вам потребуется войти в учетную запись Red Hat или создать учетную запись Red Hat с помощью рабочего адреса электронной почты и принять условия.

Щелкните Download pull secret (Скачать секрет для извлечения) и скачайте секрет для извлечения, который будет использоваться с кластером ARO.

Сохраните файл pull-secret.txt в безопасном месте. Этот файл будет использоваться при каждом создании кластера, если вам потребуется создать кластер, включающий примеры или операторы для партнеров Red Hat или сертифицированных партнеров.

Если вы копируете свой секрет для извлечения или ссылаетесь на него в других скриптах, он должен быть отформатирован в виде допустимой строки JSON.

Подготовка личного домена для кластера (дополнительно)

Если вы предоставляете личный домен для кластера, учитывайте следующие моменты:

Создание виртуальной сети, содержащей две пустые подсети

Далее вы создадите виртуальную сеть, содержащую две пустые подсети. Если вы хотите использовать существующую виртуальную сеть, которая соответствует вашим требованиям, этот шаг можно пропустить.

Создайте группу ресурсов.

Группа ресурсов Azure — это логическая группа, в которой развертываются и управляются ресурсы Azure. Во время создания группы ресурсов вам будет предложено указать расположение. В этом расположении сохраняются метаданные группы ресурсов, а также выполняется их работа в Azure, если во время создания ресурса не указан другой регион. Создайте группу ресурсов с помощью команды az group create.

Платформа Azure Red Hat OpenShift доступна не во всех регионах, где поддерживается создание группы ресурсов Azure. Список регионов, где поддерживается Azure Red Hat OpenShift, см. в разделе Available regions (Доступные регионы).

В следующем примере выходных данных показано, что группа ресурсов успешно создана:

Создайте виртуальную сеть.

Для кластеров Azure Red Hat OpenShift с OpenShift 4 требуется виртуальная сеть с двумя пустыми подсетями для главного и рабочего узлов. Для этого вы можете создать новую виртуальную сеть или использовать существующую.

Создайте виртуальную сеть в той же группе ресурсов, которая была создана ранее:

В следующем примере выходных данных показано, что виртуальная сеть успешно создана:

Добавьте пустую подсеть для главных узлов.

Добавьте пустую подсеть для рабочих узлов.

Отключите политики частной конечной точки подсети в главной подсети. Это необходимо службе для подключения к кластеру и управления им.

Создайте кластер.

Чтобы создать кластер, выполните команду ниже. Если вы решили использовать один из указанных ниже параметров, измените команду соответствующим образом:

Если вы добавляете в команду необязательные аргументы, обязательно закройте аргумент в предыдущей строке команды конечной обратной косой чертой.

После выполнения команды az aro create создание кластера обычно занимает около 35 минут.

Дальнейшие действия

В этой части руководства вы узнали, как выполнить следующие действия:

Источник

OpenShift как корпоративная версия Kubernetes

«В чем разница между Kubernetes и OpenShift?» – этот вопрос возникает с завидным постоянством. Хотя на самом деле это все равно что спрашивать, чем автомобиль отличается от двигателя. Если продолжить аналогию, то автомобиль – это готовый продукт, им можно пользоваться сразу же, буквально: сел и поехал. С другой стороны, чтобы двигатель вас куда-то повез, его сначала надо дополнить массой других вещей, чтобы в итоге получить все тот же автомобиль.

Поэтому Kubernetes – это такой двигатель, вокруг которого собран автомобиль (платформа) марки OpenShift, который и везет вас к цели.

В этой статье мы хотим напомнить и чуть подробнее разобрать следующие ключевые моменты:

OpenShift – это Kubernetes со 100% сертификацией от фонда CNCF

В основе OpenShift лежит сертифицированный Kubernetes. Поэтому после соответствующего обучения пользователи восхищаются мощью kubectl. А те, кто перешел на OpenShift с Kubernetes Cluster, часто говорят, как им очень нравится, что после перенаправления kubeconfig на кластер OpenShift, все имеющиеся скрипты работают безупречно.

Вы наверняка слышали про OpenShift’овскую утилиту командной строки под названием OC. Она полностью совместима по командам с kubectl, плюс, предлагает несколько полезных helper’ов, которые пригодятся при выполнении целого ряда задач. Но вначале чуть подробнее о совместимости OC и kubectl:

Вот как выглядят результаты использования kubectl на OpenShift API:

• kubectl get pods – вполне ожидаемо возвращает pod’ы.

• kubectl get namespaces – вполне ожидаемо возвращает пространства имен.

Иначе говоря, все Kubernetes’овские API полностью доступны в OpenShift с сохранением 100% совместимости. Именно поэтому OpenShift признан сертифицированной Kubernetes-платформой фондом Cloud Native Computing Foundation (CNCF).

OpenShift дополняет Kubernetes полезными функциями

Kubernetes’овские API на 100% доступны в OpenShift, но вот штатной Kubernetes’овской утилите kubectl явно не достает функциональности и удобства. Поэтому Red Hat дополнил Kubernetes полезными функциями и инструментами командной строки, такими как OC (сокращение от OpenShift client) и ODO (OpenShift DO, эта утилита предназначена для разработчиков).

1. Утилита OC – более мощный и удобный вариант Kubectl

Например, в отличие от kubectl, она позволяет создавать новые пространства имен и легко переключать контекст, а также предлагает ряд полезных команд для разработчиков, например, для сборки контейнерных образов и развертывания приложений непосредственно из исходного кода или двоичных файлов (Source-to-image, s2i).

Давайте на примерах рассмотрим, как встроенные helper’ы и расширенная функциональность утилиты OC помогают упростить повседневную работу.

Пример первый – управление пространствами имен. В каждом кластере Kubernetes всегда есть несколько пространств имен. Обычно они используются для создания девелоперских и продакшн-окружений, но могут применяться и для того, чтобы, например, выдавать каждому разработчику персональную «песочницу». На практике это приводит к тому, что разработчику приходится часто переключаться между пространствами имен, поскольку kubectl работает в контексте текущего пространства. Поэтому в случае с kubectl народ активно применяет для этого helper-скрипты. А вот при использовании OC для переключения на нужное пространство достаточно сказать “oc project пространство_имен”.

Не помните, как называется нужное пространство имен? Не проблема, просто введите “oc get projects”, чтобы вывести на экран полный список. Скептически интересуетесь, как это сработает, если у вас есть доступ только к ограниченному подмножеству пространств имен на кластере? Ну, потому что kubectl делает это корректно, только если RBAC разрешает вам видеть все пространства на кластере, а в больших кластерах такие полномочия выдают далеко не всем. Так вот, отвечаем: для OC это вообще не проблема и она легко выдаст в такой ситуации полный список. Вот из таких мелочей и складывается корпоративная ориентированность Openshift и хорошая масштабируемость этой платформы в плане пользователей и приложений

2. ODO – улучшенная версия kubectl для разработчиков

В качестве еще одного примера улучшений Red Hat OpenShift по сравнению с Kubernetes можно привести утилиту командной строки ODO. Она предназначена для разработчиков и позволяет быстро развертывать локальный код на удаленном кластере OpenShift. Кроме того, с ее помощью можно оптимизировать внутренние процессы, чтобы мгновенно синхронизировать все изменения кода с контейнерами на удаленном кластере OpenShift без того, чтобы заново выполнять сборку, размещение в реестре и повторное развертывание образов.

Давайте посмотрим, как OC и ODO облегчает работу с контейнерами и Kubernetes.

Просто сравним парочку рабочих процессов, когда они строятся на основе kubectl, и когда применяются OC или ODO.

• Развертывание кода на OpenShift для тех, кто не владеет языком YAML:

• Переключение контекста: смена рабочего пространства имен или рабочего кластера.

Контроль качества: «Тут появилась одна интересная функция, пока в альфа-версии. Может введем ее в продакшн?»

Представьте, что вас усаживают в гоночный болид и говорят: «Мы тут поставили тормоза нового типа и, честно говоря, у них пока не все в порядке с надежностью… Но ты не переживай, будем их активно дорабатывать прямо по ходу чемпионата». Как вам такая перспектива? Нам в Red Hat как-то не очень. 🙂

Поэтому мы стараемся воздерживаться от альфа-версий до тех пор, пока они в достаточной мере не созреют, и мы не проведем тщательное боевое тестирование и не почувствуем, что их можно безопасно использовать. Обычно у нас всё проходит сначала через стадию Dev Preview, затем через Tech Preview и только потом выходит в виде общедоступного релиза General Availability (GA), который стабилен уже настолько, что годится в продакшн.

Почему так? Потому что, как и при разработке любого другого софта, далеко не все первоначальные задумки в Kubernetes доходят до финального релиза. Или доходят, и даже сохраняют задуманную функциональность, но их реализация кардинально отличается от той, что была в альфа-версии. Поскольку тысячи и тысячи клиентов Red Hat применяют OpenShift для поддержки критически важных задач, мы делаем особый упор на стабильности нашей платформы и на долговременной поддержке.

Red Hat целенаправленно выпускает частые релизы OpenShift и обновляет входящую в ее состав версию Kubernetes. Например, в текущий на момент написания этой статьи GA-релиз OpenShift 4.3 встроен Kubernetes 1.16, который всего на единичку отстает от upstream-версии Kubernetes с номером 1.17. Таким образом мы стараемся дать заказчику Kubernetes корпоративного класса и обеспечить дополнительный контроль качества в процессе выпуска новых версий OpenShift.

Программные исправления: «В той версии Kubernetes, которая у нас в продакшн, нашлась дыра. И закрыть ее можно только обновлением на три версии вверх. Или есть варианты?»

В рамках открытого проекта Kubernetes программные исправления обычно выходят в составе следующего релиза, иногда они охватывают один или два предыдущих промежуточных релиза, что дает охват всего на 6 месяцев назад.

Red Hat по праву гордится тем, что выпускает критические исправления раньше других и обеспечивает поддержу на гораздо больший срок. Возьмем, к примеру, уязвимость с эскалацией привилегий в Kubernetes (CVE-2018-1002105): она обнаружилась в Kubernetes 1.11, а исправления для предыдущих релизов выпустили только до версии 1.10.11, оставив эту в дыру во все предыдущие релизах Kubernetes, с 1.x по 1.9.

В свою очередь, Red Hat пропатчила OpenShift назад вплоть до версии 3.2 (там стоит Kubernetes 1.2), захватив девять релизов OpenShift и наглядно продемонстрировав заботу о клиентах (подробнее здесь).

Как OpenShift и Red Hat двигают вперед Kubernetes

Red Hat занимает второе место по размеру программного вклада в открытый проект Kubernetes, уступая здесь только Google, причем 3 из 5 самых плодовитых разработчиков являются сотрудниками Red Hat. Еще один малоизвестный факт: многие критически важные функции появились в Kubernetes именно по инициативе Red Hat, в частности, такие как:

Понятно, OpenShift – это Kubernetes. А различия-то в чём? 🙂

Надеемся, что, дочитав до этого места, вы уяснили, что Kubernetes –это основной компонент OpenShift. Основной, но далеко не единственный. Иначе говоря, просто установив Kubernetes, вы не получите платформу корпоративного класса. Вам надо будет добавить аутентификацию, сеть, безопасность, мониторинг, управление журналами и многое другое. Кроме того, придется сделать нелегкий выбор из большого количества доступных инструментов (чтобы оценить разнообразие экосистемы, просто гляньте диаграмму CNCF) и как-то обеспечить согласованность и слаженность, чтобы они работали как одно целое. Кроме того, вам регулярно придется выполнять обновление и регрессионное тестирование при выходе новой версии любого из используемых компонентов. То есть, помимо создания и сопровождения самой платформы, вам надо будет заниматься еще и всем этим софтом. Вряд ли тут останется много времени на решение бизнес-задач и достижение конкурентных преимуществ.

А вот в случае с OpenShift компания Red Hat берет все эти сложности на себя и просто дает вам функционально законченную платформу, куда входит не только сам Kubernetes, но и весь комплект необходимых инструментов с открытым кодом, превращающих Kubernetes в настоящее решение корпоративного класса, которое можно сразу же и совершенно спокойно запускать в продакшн. И конечно же, если у вас есть какие-то свои технологические стеки, то вы можете встроить OpenShift в уже имеющиеся решения.

Взгляните на рисунок выше: всё, что находится вне прямоугольника Kubernetes, – это те области, где Red Hat добавляет функционал, которого в Kubernetes нет, что называется, by-design. И сейчас мы рассмотрим основные из этих областей.

1. Надежная ОС в качестве основы: RHEL CoreOS или RHEL

Red Hat уже более 20 лет является ведущим поставщиком Linux-дистрибутивов для критически важных бизнес-приложений. Наработанный и постоянно обновляемый в этой области опыт позволяет нам предложить по-настоящему надежную и доверенную основу для промышленной эксплуатации контейнеров. RHEL CoreOS использует то же ядро, что и RHEL, но оптимизирована прежде всего для таких задач, как выполнение контейнеров и работа в кластерах Kubernetes: ее уменьшенный размер и неподверженность изменениям (immutability) упрощает установку кластеров, автомасштабирование, развертывание исправлений и т. д. Все эти функции делают ее идеальной основой для получения одного и того же пользовательского опыт при работе с OpenShift в самых разных вычислительных средах, от «голого железа» до частного и публичного облака.

2. Автоматизация ИТ-операций

Автоматизация процессов установки и операций второго дня (то есть повседневной эксплуатации) – это конек OpenShift, которые значительно облегчает администрирование, обновление и поддержание работы контейнерной платформы на высочайшем уровне. Это достигается за счет поддержки Kubernetes-операторов на уровне ядра OpenShift 4.

OpenShift 4 – это также и целая экосистема решений на основе Kubernetes-операторов, разработанных как самой Red Hat, так и сторонними партнерами (см. каталог операторов Red Hat, или магазин операторов operatorhub.io, созданный Red Hat для сторонних разработчиков).

В состав интегрированного каталога OpenShift 4 входит более 180 Kubernetes-операторов

3. Инструменты для разработчиков

Начиная с 2011 года, OpenShift доступна в виде платформы PaaS (Platform-as-a-Service), которая значительно упрощает жизнь разработчикам, помогает им сосредоточиться на создании кода и предлагает встроенную поддержки таких языков программирования, как Java, Node.js, PHP, Ruby, Python, Go, а также сервисы непрерывной интеграции и доставки CI/CD, базы данных и т. п. OpenShift 4 предлагает обширный каталог, включающий более 100 сервисов на основе Kubernetes-операторов, разработанных Red Hat и нашими партнерами.

В отличие от Kubernetes, в OpenShift 4 есть специальный графический интерфейс (Developer Console), помогающий разработчикам без лишних усилий развертывать в своих пространствах имен приложения из различных источников (git, внешние реестры, Dockerfile и т. д) и наглядно визуализирующий связи между компонентами приложения.

Кроме того, OpenShift предлагает набор инструментов разработки Codeready, куда, в частности, входит Codeready Workspaces, полностью контейнеризированная IDE с веб-интерфейсом, работающая непосредственно поверх OpenShift и реализующая подход «IDE-как сервис». С другой стороны, для тех, кто хочет работать строго в локальном режиме, есть Codeready Containers – полнофункциональная версия OpenShift 4, которую можно развернуть на ноутбуке.

Интегрированная «IDE как сервис» для эффективной разработки на платформе Kubernetes/OpenShift

Прямо из коробки OpenShift предлагает полноценную систему CI/CD, либо на основе контейнеризованного Jenkins и плагина DSL для работы с конвейерами, либо ориентированную на Kubernetes CI/CD-систему Tekton (пока в версии Tech preview). Оба этих решения полностью интегрируются с консолью OpenShift, позволяя запускать триггеры конвейеров, просматривать развертывания, журналы и т. д.

4. Инструменты для приложений

OpenShift позволяет развертывать как традиционные stateful-приложения, так и облачно-ориентированные решения на базе новых архитектур, вроде микросервисов или serverless. Решение OpenShift Service Mesh прямо из коробки ключевые для сопровождения микросервисов инструменты, как Istio, Kiali и Jaeger. В свою очередь, решение OpenShift Serverless включает в себя не только Knative, но и созданные в рамках совместной с Microsoft инициативы инструменты вроде Keda для предоставления функций Azure на платформе OpenShift.

Интегрированное решение OpenShift ServiceMesh (Istio, Kiali, Jaeger) пригодится при разработке микросервисов

Чтобы сократить разрыв между унаследованными приложениями и контейнерами, OpenShift теперь позволяет провести миграцию виртуальных машин на платформу OpenShift с помощью Container Native Virtualization (пока в версии в TechPreview), превращая гибридные приложения в реальность и облегчая их перенос между различными облака, как частными, так и публичными.

Виртуальная машина Windows 2019 Virtual, запущенная на OpenShift через Container Native Virtualization (пока в версии Tech preview)

5. Инструменты для кластеров

У любой платформы корпоративного класса должны быть сервисы мониторинга и централизованного ведения логов, механизмы безопасности, аутентификации и авторизация, средства сетевого управления. И OpenShift предоставляет всё это из коробки, причем всё это на 100% открытый код, включая такие решения как ElasticSearch, Prometheus, Grafana. Все эти решения идут в комплекте с информационными панелями, метриками и оповещениями, которые уже скомпонованы и настроены с учетом обширного опыта Red Hat в области мониторинга кластеров, что позволяет с первых же минут эффективно контролировать и отслеживать работу вашей продакшн-среды.

В OpenShift также штатно имеет такие важные для корпоративного заказчика вещи, как аутентификация со встроенным провайдером oauth, интеграция с провайдерами учетных данных, включая LDAP, ActiveDirectory, OpenID Connect, и многое другое.

Предварительно настроенная информационная панель Grafana для мониторинга кластера OpenShift

Более 150 предварительно настроенных метрик и оповещений Prometheus для мониторинга кластера OpenShift

Продолжение следует

Богатый функционал решения и обширный опыт Red Hat в области Kubernetes – именно по этим причинам OpenShift занял доминирующее положение на рынке, как показано на рисунке ниже (подробнее здесь).

«На текущий момент Red Hat лидирует на рынке с долей в 44 %.
Компания пожинает плоды своей стратегии продаж с активным участием в делах клиента, в рамках которой она вначале консультирует и обучает корпоративных разработчиков, а затем переходит к монетизации по мере того, как предприятие начинает внедрять контейнеры в продакшн».

Надеемся, вам понравилась эта статья. В следующих постах из этой серии мы подробнее остановимся на преимущества OpenShift по сравнению Kubernetes в каждой из рассмотренных здесь категорий.

Источник