OpenShift как корпоративная версия Kubernetes. Часть 1

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

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

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

• Kubernetes – это сердце платформы OpenShift И это на 100% сертифицированный Kubernetes, с полностью открытым кодом и без малейшей проприетарности. Вкратце:
  • API для кластера OpenShift – это стопроцентный Kubernetes.
  • Если контейнер работает в любой другой системе Kubernetes, то он без каких-либо изменений будет работать и на OpenShift. Вносить изменения в приложения не нужно.
• OpenShift не только дополняет Kubernetes полезными функциями и возможностями. Как и автомобиль, OpenShift сразу же готов к использованию, его можно немедленно пускать в продакшн и, как мы покажем ниже, он значительно упрощает жизнь разработчику. Именно поэтому OpenShift един в двух лицах. Это и успешная, и широко известная PaaS-платформа корпоративного класса, если смотреть с позиций разработчика. И одновременно это супернадежное решение класса Container-as-a-Service с точки зрения промышленной эксплуатации.

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

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

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

Команды kubectl
Команды OC

kubectl get pods
oc get pods

kubectl get namespaces
oc get namespaces

kubectl create -f deployment.yaml
oc create -f deployment.yaml

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

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

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

Команда kubectl create -f mydeployment.yaml создает kubernetes-ресурсы точно так же, как на и на любой другой Kubernetes-платформе, как показано в видео ниже:

Иначе говоря, все 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:

Kubernetes / kubectl
$> git clone github.com/sclorg/nodejs-ex.git
1- Создаем Dockerfile, выполняющий сборку образа из кода
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ] ————–
2- Выполняем сборку образа
$> podman build …
3- Логинимся в реестр
podman login …
4- Размещаем образ в реестре
podman push
5- Создаем yaml-файлы для развертывания приложения (deployment.yaml, service.yaml, ingress.yaml) – это абсолютный минимум
6- Развертываем manifest-файлы:
Kubectl apply -f .

OpenShift / oc
$> oc new-app github.com/sclorg/nodejs-ex.git – имя_нашего_приложения

OpenShift / odo
$> git clone github.com/sclorg/nodejs-ex.git
$> odo create component nodejs myapp
$> odo push

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

Kubernetes / kubectl
1- Создаем контекст в kubeconfig для проекта “myproject”
2- kubectl set-context …

OpenShift / oc
oc project “myproject”

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

Представьте, что вас усаживают в гоночный болид и говорят: «Мы тут поставили тормоза нового типа и, честно говоря, у них пока не все в порядке с надежностью… Но ты не переживай, будем их активно дорабатывать прямо по ходу чемпионата». Как вам такая перспектива? Нам в 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, в частности, такие как:

• RBAC. В Kubernetes не было функций RBAC (ClusterRole, ClusterRoleBinding) до тех пор, пока инженеры Red Hat не решили реализовать их в составе самой платформы, а не как дополнительный функционал OpenShift. Не боится ли Red Hat улучшать Kubernetes? Конечно нет, ведь Red Hat строго следует принципам открытого кода, а не играет в игры Open Core. Улучшения и новшества, которые реализуются на уровне сообществ разработки, а не по принципу проприетарности, становятся более жизнеспособными и получают более широкое распространение, что отлично согласуется с нашей главной целью – сделать софт с открытым кодом более полезным для наших клиентов.
• Политики безопасности для pod’ов (Pod Security Policies). Первоначально эта концепция безопасного выполнение приложений внутри pod’ов была реализована в OpenShift под именем SCC (Security Context Constraints). И как и в предыдущем примере, Red Hat решила ввести эти наработки в состав открытого проекта Kubernetes, чтобы ими могли пользоваться все желающие.

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

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

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

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

OpenShift – это умная Kubernetes-платформа

Взгляните на рисунок выше: всё, что находится вне прямоугольника 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 и т. д) и наглядно визуализирующий связи между компонентами приложения.

Консоль Developer Console наглядно представляет компоненты приложения и упрощает работу с Kubernetes

Кроме того, 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 %.
Компания пожинает плоды своей стратегии продаж с активным участием в делах клиента, в рамках которой она вначале консультирует и обучает корпоративных разработчиков, а затем переходит к монетизации по мере того, как предприятие начинает внедрять контейнеры в продакшн».

(Источник: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863)

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

Источник: habr.com