openshift 4 что нового
Red Hat OpenShift 4
Red Hat® OpenShift® expands enterprise Kubernetes with full-stack automated ops to manage hybrid cloud and multicloud deployments.
What’s new in Red Hat OpenShift 4
Immutable Red Hat Enterprise Linux CoreOS
Improved installation based on immutable Red Hat® Enterprise Linux® CoreOS for consistency and upgradability.
Operator framework
Single-step installation for Kubernetes applications and services, plus automated, over-the-air updates and performance tuning with Kubernetes operators.
OpenShift service mesh
Increased resiliency and performance for your distributed applications with OpenShift service mesh.
Knative framework
Developer-friendly serverless framework and components for building, serving, and running event-driven applications.
Already have one or more subscriptions?
Get started with Red Hat OpenShift 4
Full-stack automated operations
Red Hat OpenShift 4 offers automated installation, upgrades, and life cycle management for every part of your container stack.
Red Hat OpenShift: Operator Framework
OpenShift: Kubernetes is optimized for developers on Red Hat OpenShift
Support for developer productivity
Code in production mode for any infrastructure. Red Hat OpenShift 4 supports well-known developer tools and helps streamline your build and delivery workflows.
Built-in service mesh for microservices
Microservices architectures can cause communication between services to become complicated to encode and manage. The OpenShift service mesh abstracts the logic of interservice communication into a dedicated infrastructure layer, so communication is more efficient and distributed applications are more resilient.
Что нового в Red Hat OpenShift 4.2 и 4.3?
Четвертая версия 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-драйверов можно найти в этом документе: https://kubernetes-csi.github.io/docs/drivers.html. В этом списке можно найти все основные модели дисковых массивов ведущих производителей (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 помогают автоматизировать любые задачи, связанные с администрированием и управлением жизненным циклом приложения, которое вы разворачиваете в своем кластере. Например, оператор может автоматизировать обновления, резервное копирование и масштабирование приложения, менять конфигурацию и т.д. Полный список операторов можно посмотреть на https://operatorhub.io/.
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. Теперь это можно будет сделать всего тремя командами.
Red Hat OpenShift 4.8 расширяет спектр рабочих нагрузок для гибридного облака
Red Hat объявила о выпуске Red Hat OpenShift 4.8, новой версии ведущей отраслевой Kubernetes-платформы корпоративного класса. Предоставляя мощную основу для разработки и эксплуатации разнообразных рабочих нагрузок в гибридном облаке, решение помогает организациям ускорить создание современных облачных приложений без отказа от имеющихся ИТ-систем, в которые были вложены значительные инвестиции.
Поскольку новые цели заказчиков продолжают создавать пространство для инноваций на рынке, Red Hat OpenShift 4.8 предоставляет организациям общую основу для более последовательной разработки, развертывания и запуска гибридного набора приложений и услуг.
Red Hat OpenShift 4.8, в основе которого лежит Kubernetes 1.21 и runtime-интерфейс CRI-O 1.21, упрощает работу разработчиков, а также расширяет спектр рабочих нагрузок и сценариев использования гибридного облака. Список новшеств и улучшений OpenShift 4.8 включает в себя следующие возможности и функции:
Поддержка двойного стека IPv6/IPv4 и одинарного стека IPv6 обеспечивает интероперабельность и связь приложений в средах, где наряду с IPv4 применяется IPv6, например, в Cloud-Native Network Functions на сетях телеком-операторов, а также в госучреждениях, где в обязательном порядке требуется поддержка IPv6. Кроме того, это помогает обеспечить дополнительную безопасность приложений, включая соответствие регулятивным требованиям.
OpenShift Pipelines теперь позволяет пользователям декларативно задавать, версионировать и отслеживать изменения в конвейерах доставки приложений по аналогии с исходным кодом в репозиториях Git. Таким образом, разработчики могут использовать рабочие процессы на основе Git для автоматизации развертывания конвейеров CI/CD, чтобы вводить в строй новые функции более быстрым и безопасными для бизнеса способом. Кроме того, Git-процессы можно использовать для управления конвейерами с ведением записей аудита в виде Git-коммитов, что пригодится при коллективном изменении конвейеров в ходе их жизненного цикла.
Новые возможности консоли OpenShift для разработчиков, включая возможность кодировать и тестировать приложения Spring Boot локально, прежде чем выкладывать код в общий доступ. Кроме того, расширяя поддержку разработки с использованием технологий Serverless, Red Hat OpenShift 4.8 предлагает дополнительные опции масштабирования из консоли разработчика.
OpenShift Serverless Functions позволяют разработчикам создавать функции и запускать их OpenShift по требованию. Этот функционал, доступный в версии technology preview, помогает упростить, автоматизировать и ускорить разработку и эксплуатацию приложений за счет устранения ручных операций по подготовке и масштабированию инфраструктуры.
Песочница для контейнеров OpenShift на основе СПО-проекта Kata Containers, обеспечивают более безопасную среду выполнения контейнеров с использованием легковесных виртуальных машин. Этот функционал доступен в версии technology preview и может применяться для защиты особых рабочих нагрузок с повышенными требованиями безопасности на уровне приложений. Для подавляющего большинства приложений и сервисов хватает стандартных средств безопасности Linux-контейнеров, однако песочница обеспечивает дополнительный уровень изоляции для особо критичных в плане безопасности задач, вроде запуска привилегированных нагрузок или недоверенного кода.
За последние годы выросло количество нагрузок OpenShift, предлагаемых сторонними разработчиками, которые являются ISV-партнерами Red Hat. Упомянутый выше опрос компании Pulse показал, что 63% респондентов используют либо комбинацию из ISV- и заказных нагрузок, либо только ISV-нагрузки на базе контейнеров и Kubernetes.
Стремясь предоставить организациям более широкий выбор, Red Hat доработала свою программу сертификации решений для OpenShift, чтобы расширить спектр нагрузок, доступных для этой ведущей отраслевой Kubernetes-платформы промышленного класса. Теперь партнеры Red Hat могут адаптировать и сертифицировать свои программные решения для OpenShift с использованием механизмов Kubernetes Operators либо Helm Charts, чтобы, в том числе, задействовать технологии Kubernetes для управления и масштабирования своих программных систем.
Экосистема OpenShift с сертификацией на уровне Kubernetes Operators и диаграмм Helm содержит более 150 партнерских решений, включая недавно сертифицированные на уровне Operators решения Intel OpenVINO Model Server и OpenNESS, контейнерно-ориентированную платформу данных Ionir, гибридное облачное хранилище объектов MinIO, облачный сервис баз данных MongoDB Atlas, а также сертифицированный на уровне Helm продукт HashiCorp Vault. Экосистема помогает организациям расширить свои возможности за счет решений, которые тесно интегрируются с OpenShift и обеспечивают перенос в облако широкого спектра задач, включая базы данных, AI/ML, среды выполнения приложений, инструменты разработки, хранилища данных, сетевые решения, средства безопасности, мониторинга и журналирования, а также и многие другие решения.
Кроме того, подразделение Red Hat Services предоставляет заказчикам свои экспертные знания и практический опыт в области разработки приложений, помогая успешно преодолевать препятствия на пути создания современных масштабируемых приложений для гибридного облака.
Планируется, что общедоступная версия Red Hat OpenShift 4.8 выйдет в июле 2021 года, в том числе в виде ознакомительного варианта на портале Developer Sandbox for Red Hat Openshift.
Контейнер – на конвейер: CRI-O теперь по умолчанию в OpenShift Container Platform 4
Платформа Red Hat OpenShift Container Platform 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), получившего название Container Runtime Interface (CRI). Благодаря этому пользователи Kubernetes смогли подключать различные движки для работы с контейнерами в дополнение к Docker.
Инженеры Red Hat и Google увидели существовавшую на рынке потребность в контейнерном движке, который мог бы принимать запросы от Kubelet по протоколу CRI и представили контейнеры, которые были совместимы с упомянутыми выше спецификациями OCI. Так появился OCID. Но позвольте, ведь мы же сказали, что этот материал будет посвящен CRI-O? На самом деле так и есть, просто с выпуском версии 1.0 проект был переименован в CRI-O.
Инновации с 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, это:
Теперь отправим этот файл в кластер Kubernetes и проверим, что он действительно создан. Обратите внимание, что работа осуществляется точно так же, как и с любым другим ресурсом Kubernetes:
После того, как мы создали ContainerRuntimeConfig, нам необходимо изменить один из MachineConfigPools, чтобы дать понять Kubernetes, что мы хотим применить эту конфигурацию к определенной группе машин в кластере. В этом случае мы изменим MachineConfigPool для мастер-узлов:
Вывод (для наглядности оставлена основная суть):
В этот момент MCO начинает создавать новый файл crio.conf для кластера. При этом полностью готовый файл конфигурации можно просмотреть средствами Kubernetes API. Помните, ContainerRuntimeConfig – это всего лишь специализированная версия MachineConfig, поэтому мы можем увидеть результат, взглянув на нужные строки в MachineConfigs:
Обратите внимание, что полученный файл конфигураций для мастер-узлов оказался более новой версией, чем исходные конфигурации. Чтобы просмотреть его, запустите следующую команду. Попутно отметим, что это, возможно, один из лучших однострочных скриптов за всю историю Kubernetes:
Теперь убедимся, что конфигурация была применена ко всем мастер-узлам. Сначала получим список узлов в кластере:
Теперь просмотрим установленный файл. Вы увидите, что файл был обновлен по новым значениям директив pid и debug, которые мы указали в ресурсе ContainerRuntimeConfig. Сама элегантность:
Все эти изменения в кластере были внесены даже без запуска SSH. Вся работа была выполнена путем обращения к мастер-узлу Kuberentes. То есть эти новые параметры были сконфигурированы только на мастер-узлах. Рабочие узлы при этом не менялись, что демонстрирует преимущества методологии Kubernetes с использованием заданных и актуальных состояний применительно к хостам контейнеров и контейнерных движков с взаимозаменяемыми элементами.
Приведенный выше пример показывает возможность вносить изменения в небольшой кластер OpenShift Container Platform 4 с тремя рабочими нодами или в огромный производственный кластер с 3000 нодов. В любом случае объем работ будет одинаковым – и совсем небольшим – достаточно настроить файл ContainerRuntimeConfig, и изменить одну метку (label) в MachineConfigPool. И вы можете проделать это с любой версией используемой в Kubernetes платформы OpenShift Container Platform 4.X в течение всего ее жизненного цикла.
Зачастую технологические компании развиваются настолько быстро, что мы не в состоянии объяснить, почему мы выбираем те или иные технологии для базовых компонентов. Контейнерные движки исторически были тем компонентом, с которым пользователи взаимодействуют напрямую. Поскольку популярность контейнеров закономерно начиналась с появления контейнерных движков, пользователи нередко проявляют к ним заинтересованность. Это еще одна причина, почему Red Hat остановила свой выбор на CRI-O. Контейнеры развиваются, при этом сегодня основное внимание уделяется оркестровке, и мы пришли к выводу, что CRI-O обеспечивает наилучший опыт при работе с OpenShift 4.