Openshift какую роль выполняет proxy у каждой поды приложения
Kubernetes — мощный и гибкий инструмент для оркестрации контейнеров. Но это не готовая платформа корпоративного уровня. Чтобы полноценно начать пользоваться Kubernetes, нужно его настроить и интегрировать дополнительные инструменты.
Это добавляет сложности тем, кто хочет получить готовую платформу для управления контейнерами и не готов уделять много времени обслуживанию. Поэтому появились решения, которые облегчают использование Kubernetes и позволяют начать им пользоваться сразу после установки. Они объединяют Kubernetes и спектр нужных компонентов в готовый продукт.
Мы рассмотрим несколько решений: обычный Kubernetes, платформу OpenShift в разных вариантах и Kubernetes as a Service (KaaS) на примере сервиса VK Cloud Solutions (бывш. MCS). Это сравнение поможет выбрать инструмент в зависимости от ваших задач:
- хотите ли вы все делать самостоятельно с возможностью полной кастомизации либо вам нужно готовое решение с некоторыми ограничениями;
- готовы ли вы платить за дорогостоящую лицензию или вам больше подходит модель оплаты за используемые ресурсы, либо ваш выбор — бесплатный вариант с более сложным внедрением и администрированием решения.
OpenShift и KaaS: в чем разница
OpenShift и KaaS — это два разных инструмента, у которых совершенно разные подходы:
- OpenShift — готовая платформа для разработки и эксплуатации контейнерных приложений. Ее можно установить на свои серверы или арендовать у облачного провайдера. OpenShift — это больше чем Kubernetes. Kubernetes лежит в основе платформы, но кроме него еще есть много других инструментов, которые упрощают работу с кластером и контейнерными приложениями в целом. Некоторые инструменты, которые в простом Kubernetes нужно изучать и настраивать, тут доступны «из коробки». Например, в OpenShift более строгая политика безопасности, которая не позволяет запускать контейнеры от root-пользователя, есть инструменты для упрощения интеграции с Active Directory, встроенный конвейер CI/CD и другое. — это Managed-решение от облачного провайдера, которое не нужно устанавливать, оно доступно в виде готового облачного сервиса. Основные плюсы, которые получают пользователи — простую установку и первоначальную настройку кластера, автомасштабирование и отсутствие необходимости администрировать кластер, много готовых интегрированных инструментов, упрощающих работу с Kubernetes.
Также отметим, что OpenShift — это готовый дистрибутив, он везде предоставляет одинаковую функциональность. А функциональность KaaS зависит от конкретного облачного провайдера. В одном случае будет удобный графический интерфейс управления кластером, в другом — расширенные функции мониторинга, а в третьем — интеграция c IdM. Поэтому, чтобы не сравнивать некий абстрактный KaaS, мы будем говорить конкретно про KaaS на платформе VK Cloud Solutions (бывш. MCS).
Давайте сравним эти два инструмента и посмотрим, какие преимущества они дают по сравнению с простой установкой K8s. OpenShift мы будем рассматривать с двух сторон: как Open Source-решение, которое можно установить и использовать самостоятельно, и облачное платное решение от вендора.
Автомасштабирование в Kubernetes, OpenShift и KaaS
Kubernetes умеет автоматически масштабировать кластер, то есть увеличивать количество нод. Но чтобы сделать это на своем оборудовании, нужно постоянно держать наготове резерв серверов, который будет простаивать во время снижения нагрузки. Если же Kubernetes развернут на IaaS, придется настраивать автоматическое подключение виртуальных машин по требованию, что трудоемко.
OpenShift поддерживает автомасштабирование на уровне кластера: он может изменять количество подов и нод в кластере. Но если рассматривать установку On Premise, то на физическом сервере количество ресурсов ограничено, OpenShift в любом случае может упереться в потолок. В моменте из-за этого ухудшится производительность, а если такое будет случаться постоянно — то придется докупать оборудование. Если рассматривать OS как услугу облачного провайдера, то там используют виртуальные серверы, и у них больше возможностей для расширения.
KaaS находится у облачного провайдера, вы можете подключить автоматическое масштабирование кластера. Тогда система сможет автоматически подключать до ста новых серверов. При этом автомасштабирование настраивается в несколько кликов: достаточно лишь указать минимальное и максимальное количество нод.
Балансировка нагрузки в Kubernetes, OpenShift и KaaS
Kubernetes не умеет балансировать нагрузку «из коробки»: придется самостоятельно поднимать и настраивать балансировщик.
OpenShift в облаке имеет настроенный и готовый к работе балансировщик нагрузки. Если устанавливать на своей инфраструктуре — то все придется делать руками, как и с обычным Kubernetes.
В KaaS балансировщики уже интегрированы и подключаются автоматически. Обычно создается два балансера в отказоустойчивом режиме Active/Standby. Это означает, что первый балансер активно работает, а второй находится в режиме ожидания. Если первый по какой-то причине перестает работать, то автоматически включается второй.
Мониторинг в Kubernetes, OpenShift и KaaS
В Kubernetes по умолчанию нет мониторинга, его нужно устанавливать и настраивать отдельно.
В OpenShift используются Prometheus и Grafana. Такой набор стал уже своего рода стандартом мониторинга Kubernetes. Они уже установлены, настроены и сразу готовы к использованию.
В KaaS могут использоваться разные инструменты, в зависимости от провайдера. На платформе VK есть Prometheus и Grafana, которые тоже готовы к использованию.
Установка, администрирование и интеграция Kubernetes, OpenShift и KaaS с другими сервисами
Kubernetes нужно скачивать, устанавливать и настраивать самостоятельно. Причем существуют десятки инсталляторов и способов его установки. Минус в том, что нужно разобраться в их отличиях и выбрать нужный. А плюс — в том, что есть гибкость, ведь каждый инсталлятор делает что-то по-своему. Но кроме настройки самого Kubernetes его еще нужно интегрировать с другими системами: хранилища данных, авторизация, сбор логов и тому подобное. Администрированием тоже придется заниматься самостоятельно: поддерживать работоспособность и разбираться в проблемах.
OpenShift в облаке вендора уже установлен, настроен и готов к использованию. Но установку On Premise придется выполнять своими усилиями. Нужно учесть, что OpenShift работает только на дистрибутивах RHEL, CoreOS и CentOS. Интеграция с другими сервисами также зависит от способа установки. Если вы используете локальный OpenShift, то интегрироваться со всеми вашими системами придется самостоятельно. А если облачный — то у провайдера как правило есть разные сервисы, с которыми можно легко интегрироваться.
KaaS. Аналогично облачному OpenShift, в KaaS развернуть кластер можно за несколько кликов мышью. Администрированием занимается облачный провайдер, так что вам не нужно задумываться об отказоустойчивости и других проблемах. Блочные хранилища Persistent Volumes уже подключены к кластеру и позволяют хранить данные, также можно использовать S3-хранилище или облачные СУБД, если это позволяет логика приложения. Также KaaS работает с любыми сервисами, которые есть на платформе VK Cloud Solutions (бывш. MCS), например, сервисы для аналитики больших данных, машинного обучения и другие.
Обновление в Kubernetes, OpenShift и KaaS
Kubernetes нужно обновлять самостоятельно и не забывать про дополнительные инструменты. Каждое обновление нужно тестировать на совместимость: что вся система целиком правильно работает. Также важно выбрать инструмент обновления, который умеет обновлять кластер без простоя IT-системы, и организовать сам процесс. Однако в любом случае могут возникнуть непредвиденные проблемы, которые приведут к недоступности кластера. Со всеми ошибками в процессе обновления придется разбираться самостоятельно.
В OpenShift все содержимое обновляется и тестируется его разработчиками. Каждая новая версия OpenShift появляется только после полноценного тестирования всей платформы. Пользователям On Premise не нужно обновлять отдельные компоненты, но нужно обновлять саму платформу. Если после обновления ваши собственные сервисы перестанут работать с конкретной версией OS — разбираться тоже придется самостоятельно. А пользователи OpenShift от вендора могут не задумываться о проблемах обновления. Провайдер сделает все сам, и кластер не придется останавливать.
В KaaS тоже не нужно беспокоиться об обновлении. Облачный провайдер сделает все сам: обновит Kubernetes и дополнительные инструменты, протестирует их, и после этого они станут доступны для всех. О крупных изменениях предупредит заранее, в случае проблем — поможет. Обновление пройдет незаметно, кластер останавливать не придется.
Управление кластером в Kubernetes, OpenShift и KaaS
Kubernetes можно управлять разными способами: графический интерфейс (UI), API, CLI.
В OpenShift API и CLI совместимы со стандартным Kubernetes, и даже немного расширены: позволяют управлять теми функциями платформы, которых нет в классическом Kubernetes. Отдельно нужно отметить графический интерфейс: он намного удобней и функциональней классического Kubernetes Dashboard и позволяет сделать практически все, не прибегая к консоли. Иногда даже встречаются инсталляции обычного Kubernetes, на которых установлен интерфейс от OpenShift.
KaaS тоже поддерживает стандартные API и CLI Kubernetes. Веб-интерфейс нацелен на то, чтобы управлять только внешним периметром Kubernetes: создание, запуск и остановка кластера, добавление или удаление нод и так далее. Для того, чтобы управлять «внутренностями» кластера, вроде деплойментов, сервисов и так далее, можно использовать стандартные возможности Kubernetes, например предустановленный Kubernetes Dashboard или CLI kubectl.
Конвейер CI/CD в Kubernetes, OpenShift и KaaS
В Kubernetes нет готового CI/CD-решения. Чтобы настроить конвейер разработки, нужно самостоятельно интегрировать Kubernetes с другими инструментами и устанавливать плагины.
В OpenShift есть встроенный конвейер CI/CD. У него есть интересная функция: если указать ссылку на Git-репозиторий и выбрать шаблон нужного языка программирования, OpenShift сам скачает код, обернет его в контейнер, сгенерирует манифест и развернет приложение в Kubernetes. Если же возможностей встроенного CI/CD-конвейера не хватает, тогда можно подключить любой инструмент, который совместим с обычным Kubernetes.
В KaaS нет готового CI/CD решения, но к нему можно быстро подключить любые инструменты, совместимые с классическим Kubernetes. Также на платформе VK есть маркетплейс, который упрощает установку ряда облачных инструментов, нужных для работы с K8s.
Что выбрать: K8s, OpenShift или KaaS
У «чистого» Kubernetes преимущество в гибкости настройки. Он позволяет реализовать нестандартные сценарии инфраструктуры, но требует времени и умения с ним работать. Далеко не всем компаниям нужна эта гибкость: это как швейцарский нож, из арсенала которого используется только лезвие. Такое решение нужно выбирать, когда есть специфические требования к инфраструктуре и возможность администрировать кластер.
OpenShift — это платформа, которую можно установить на свои серверы или арендовать в облаке. Она упрощает работу с Kubernetes и предоставляет часть функций «из коробки». При этом, если вы используете Open Source-версию, то можете столкнуться с теми же проблемами, что и при эксплуатации обычного Kubernetes. Платная версия эти сложности решает, но стоит денег — она нужна, если вам необходима поддержка и гарантии от вендора, вы хотите снять с себя нагрузку по работе с кластером.
Есть еще один момент: OpenShift расширяет возможности стандартного Kubernetes, но использование его встроенных объектов затрудняет миграцию на обычный Kubernetes или другую платформу, придется перестраивать систему деплоя приложений. То есть это решение стоит выбирать, если преимущества и ограничения OS вас устраивают, нет намерения менять платформу.
KaaS — это Managed-решение Kubernetes, где администрированием кластера занимается облачный провайдер. Оно упрощает создание и сопровождение кластера, предлагает «из коробки» многое из того, что нужно для работы с Kubernetes, а также позволяет быстро интегрировать любые совместимые с K8s инструменты.
Про управление входящим в OpenShift трафиком (оно же Ingress) написано много в документации и различных статьях по его настройке. Но, кроме контроля входящего в кластер трафика, в работе зачастую требуется контроль исходящего трафика (Egress). А на эту тему информации, систематизирующей подходы и технические решения, значительно меньше. Постараемся заполнить эту нишу серией постов.
Итак, в каких ситуациях нужен контроль исходящего из кластера трафика?
Можно выделить три типовых сценария использования.
Доступ к внешнему ресурсу контролируется извне кластера
Например, есть внешняя база данных, доступ к которой контролируется межсетевым экраном, и требуется предоставить доступ к этой БД только для определенных POD кластера. По умолчанию POD при взаимодействии с внешними ресурсами используют IP-адрес узла кластера, поэтому задача не решается «в лоб».
Можно выделить несколько узлов исключительно под эти POD, но это зачастую не выход. Узлов понадобится несколько (нам же нужна отказоустойчивость), а требуемых POD может быть совсем немного. Узлы могут получать IP адреса по DHCP, что также затрудняет решение проблемы. Ну и, наконец, таких внешних «зон безопасности» может быть много, и выделять под каждую по два узла совсем не хочется.
Для определенных POD в кластере требуется доступ в изолированные сегменты сети
Типичным случаем здесь является организация доступа определенных POD к сегментам сети, расположенным в другом VLAN (которого нет на узлах кластера) или вообще на другом оборудовании (например, по требованиям PCI DSS).
Создавать по кластеру в каждом таком сегменте — дорого и к тому же тяжело поддерживать. А заводить требуемый VLAN на узлы кластера не будут: его для этого и сделали, чтобы доступ получило только то ПО и оборудование, которое участвует в этом критичном с точки зрения ИБ бизнес-процессе.
К пропускной способности или задержкам сети определенных POD предъявляются особые требования
Например, приложение требует для нормальной работы выделенного соединения 10G Ethernet и полностью его утилизирует. В этом случае также непонятно, как обеспечить эти требования в условиях одновременной работы десятков или сотен POD на одном рабочем узле. Не выделять же полностью узел кластера под один подобный POD.
На все вышеописанные сценарии есть решения, которые связаны с управлением исходящего из кластера OpenShift трафика. Попробуем разобраться, в каком случае какое решение по Egress применять, и как оно работает.
Egress IP и Egress Router
Static IP Egress
В OpenShift, начиная с версии 3.7, появилась возможность выделить фиксированные адреса на namespace, и именно с этих адресов все POD в этом namespace будут обращаться к внешним ресурсам кластера. Реализовано это средствами OpenShift SDN.
Как это работает:
-
Создадим проект «egress» и запустим в нем тестовый POD «tool»:
Ответ на этот вопрос дает статья How to Enable Static Egress IP in OCP. Давайте с ее помощью выясним, что же происходит «под капотом» OpenShift при использовании Egress IP.
-
В таблице NAT в iptables на shift-worker1 есть такие строчки:
Принадлежность к проекту определяется его virtual network ID (VNID), в нашем случае 0xe28820 — это шестнадцатеричное значение VNID для проекта egress.
OpenShift SDN заворачивает все подобные пакеты в tunnel interface vxlan0 с указанием, что доставить пакет надо на хост shift-worker0:
Таким образом, OpenShift SDN выбирает «основной» Egress IP-адрес, и все пакеты с проекта помечает меткой и отправляет на хост, содержащий «основной» Egress IP. На этом хосте iptables выполняет Source NAT, и задача решена. Если хост с «основным» Egress IP становится недоступен, то пакеты перенаправляются на следующий в списке Egress IP-адресов хост (в нашем случае это будет shift-worker1).
Если мы выключим хост shift-worker0, то наш тестовый POD «наружу» будет выходить уже с адресом 192.168.111.226, который мы присвоили узлу shift-worker1:
Subnet IP Egress
Если нужно сделать фиксированные Egress-адреса для нескольких проектов, то использовать Egress IP неудобно. В этом случае узлам кластера можно указать, какую подсеть использовать, а проекту — какой IP адрес из этой подсети взять.
После этого указываем проекту, какой IP-адрес использовать для исходящего трафика:
Разумеется, egressCIDR должен быть в той же подсети, что и основной IP-адрес узла. И выделять два адреса на проект в данном случае не требуется — при отказе узла используемый адрес «переедет» на другой доступный узел с установленным egressCIDR (при условии, что этот адрес в него входит).
Egress Router
Рассказывая про Egress в OpenShift, важно также упомянуть про Egress router. Он применялся еще до того, как появилась возможность контролировать исходящий трафик средствами Openshift SDN. В качестве решения использовался специальный POD, у которого один адрес находился в кластерной сети OpenShift, а другой получал внешний IP-адрес и доступ к физическому интерфейсу узла через macvlan CNI plugin.
Этот POD выступал в роли маршрутизатора между внутренней сетью кластера и внешними сетями за пределами OpenShift. Пример управления исходящим трафиком через Egress router можно посмотреть на странице Red Hat OpenShift Blog. Но так как конфигурация на базе OpenShfit SDN проще в настройке и поддержке, описание решения на базе Egress router в OpenShift версии 4 удалено из документации.
Vanilla Kubernetes
А что с управлением Egress трафиком в «ванильном» Kubernetes? К сожалению, единого решения здесь нет. Все зависит от возможностей SDN, который используется в работе кластера. Например, Calico позволяет отключить Source NAT для определенного пула IP-адресов. Но в этом случае вопросы маршрутизации трафика между POD кластера и внешним миром придется решать самостоятельно.
Резюме
В OpenShift можно штатными средствами SDN организовать контроль IP-адресации исходящего трафика, чтобы обеспечить требования внешних систем контроля доступа. При этом необходимо понимать возникающие в работе кластера технические нюансы:
- Весь исходящий трафик от проекта с фиксированным Egress IP будет направлен через один узел кластера вне зависимости от того, где находятся POD этого проекта. Если у вас на кластере большая нагрузка на сетевую подсистему, то это может увеличить задержки в передаче данных;
- Network alias для Egress IP будет создан на первом с точки зрения OC интерфейсе. Поэтому, если на узлах несколько интерфейсов, необходимо, чтобы «основной» из них был первым;
- Вам придется заняться IP address management для Egress IP. Это очевидно: раз вы сами занимаетесь выделением IP, то и контроль за корректностью тоже будет за вами.
Подмена IP-адресов здесь никак не поможет. Решением является использование CNI «meta-plugin» Multus. Multus CNI plugin стал доступен в качестве поддерживаемого компонента в OpenShift 4.1 и фактически позволяет организовать подключение POD к нескольким сетям одновременно.
Настройке и использованию Multus CNI Plugin в OpenShift посвятим вторую часть этого поста.
Список литературы
Автор: Сергей Артемов, руководитель отдела DevOps-решений «Инфосистемы Джет»
- Сборку артефакта произвожу сам, своим инструментом (maven, gradle и др.)
- Контролирую создание Docker Image через Dockerfile
- Build и Deployment процесс в Openshift настраивается в шаблоне, т.е. любые характеристики контейнера, pod настраиваются.
- Таким образом сам процесс можно перенести во внешнюю систему сборки, развертывания
Таким образом в папке будет два файла: артефакт и Dockerfile
Состав файлов это условно, если например в Dockerfile потребуются еще дополнительные файлы для docker image, то их добавляем сюда. Сейчас собственно в Dockerfile указан базовый образ java и мое приложение Spring boot, открыто два порта и др.
На этом шаге имеем выбор/свободу в средстве сборки приложения и сборки docker image.
Далее подготавливаю OpenShift template для приложения, эта операция может быть разовой, ее надо только параметризовать. Поскольку он может содержать в себе все возможное для создания, запуска и работы приложения, то через него и будем управлять этими процессами. У меня он будет достаточно простой и состоять из трех самых необходимых конфигураций
- ImageStream
- BuildConfig
- DeploymentConfig
В шаблоне указаны как пример некоторые параметры контейнера, указаны например ресурсы/лимиты, перемененная окружения TZ, указан один параметр шаблона — имя приложения (APP_NAME). Адрес docker реестра указан для версии minishift (172.30.1.1:5000/myproject/ ее использую локально для разработки) и др.
Но для моего сценария самое главное указано здесь
В BuildConfig сказано что источником будет являться бинарный файл(ы), а управлять стратегией подготовки docker image — Dockerfile (type: Docker)
Создадим этот шаблон в OpenShift
Этот шаблон появится в каталоге шаблонов (можно будет организовать процесс и из web UI консоли, но не здесь).
По этому шаблону далее создадим приложение (по факту это только имя и не более)
укажем имя шаблона и параметр имя приложения
Создались три мои конфигурации.
Запускаем сам процесс сборки и развертывания приложения в контейнере.
Важно выполнять из папки где указан бинарный файл и Dockerfile, как раз параметр --from-dir указывает на это, что будет подготовлена вся папка для загрузки в OpenShift для построения и развертывания image в docker реестре. Есть и другие параметры этой команды, например из архива.
Видим, что содержимое папки было загружено в OpenShift, который запустил процесс Docker для подготовки Image по Dockerfile и в заключении поместил образ в docker registry.
В web консоли OpenShift видно стартовало приложение
Указанные в конфигурации параметры контейнера
Указанная в конфигурации переменная окружения
Таким образом без дополнительных плагинов, с максимальным контролем и свободой выбора удалось разместить приложение в OpenShift.
Installing Minishift
для изучения темы OpenShift я бы посоветовал начать с Minishift
OpenShift - это открытая и расширяемая платформа приложений-контейнеров, которая позволяет использовать Docker и Kubernetes на предприятии [Источник 2] .
Содержание
Обзор
OpenShift включает Kubernetes для оркестрации контейнеров и управления ими. Здесь добавлены инструменты для разработчиков и операций, позволяющие:
- быстро разрабатывать приложения;
- легко развертывать и масштабировать решения;
- обслуживать жизненный цикл команд и приложений в долгосрочной перспективе.
Существует несколько версий OpenShift:
- Платформа контейнеров OpenShift;
- OpenShift в Azure (полностью управляемый OpenShift ожидается в начале 2019);
- OKD (прежнее название — OpenShift Origin);
- OpenShift Dedicated;
- OpenShift Online.
Платформа контейнеров OpenShift
OpenShift Container Platform — это коммерческая версия корпоративного класса, которая разрабатывается и поддерживается компанией Red Hat. Чтобы использовать эту версию, клиенты должен приобрести необходимые права доступа к платформе OpenShift Container Platform. Кроме того, они сами устанавливают и администрируют всю инфраструктуру. Так как клиенты являются владельцами платформы, они могут установить ее в локальном центре обработки данных или в общедоступном облаке (Azure, AWS или Google).
OpenShift в Azure
OpenShift в Azure — это полностью управляемое предложение OpenShift, выполняемое в Azure. Эта служба управляется и поддерживается совместно корпорацией Майкрософт и Red Hat. Кластер будет развернут в подписку Azure клиента. В настоящий момент служба находится в закрытой предварительной версии, а в начале CY 2019 планируется выпустить общедоступную версию. Дополнительные сведения будут представлены, когда предложение будет ближе к общедоступной версии. OKD (прежнее название — OpenShift Origin); OKD — это высокоуровневый проект OpenShift с открытым кодом, который поддерживается сообществом. OKD можно установить в ОС CentOS или Red Hat Enterprise Linux (RHEL).
OpenShift Dedicated
OpenShift Dedicated — это управляемая Red Hat однотенантная (получающая доступ к другим службам в выделенной среде) OpenShift, которая использует платформу контейнеров OpenShift. Red Hat управляет всей базовой инфраструктурой (виртуальными машинами, кластером OpenShift, сетью, хранилищем и т. д.). Кластер связан только с одним клиентом и выполняется в общедоступном облаке (AWS или Google). Начальный кластер включает четыре узла приложений, и все затраты — ежегодные и оплачиваются заранее.
OpenShift Online
OpenShift Online — это мультитенантная(обращающаяся к службам в общей среде в нескольких организациях) платформа OpenShift (на базе Container Platform) под управлением Red Hat. Red Hat управляет всей базовой инфраструктурой (виртуальными машинами, кластером OpenShift, сетью и хранилищем).
Чтобы использовать эту версию, клиенты развертывают контейнеры, но при этом они не могут выбирать, на каких узлах эти контейнеры выполняются. Так как OpenShift Online — это мультитенантная среда, контейнеры могут размещаться на тех же узлах виртуальных машин, что и контейнеры других клиентов. Стоимость вычисляется из расчета на один контейнер.
Преимущества для разработчиков
OpenShift Container Platform предоставляет оптимальную платформу для подготовки (provisioning), сборки и развертывания приложений и их компонентов в режиме самообслуживания. Средства автоматизации, наподобие встроенной конвертации S2I (source -to-image), значительно упрощают сборку контейнерных образов в формате docker на основе кода, извлеченного из системы контроля версий. Интеграция с инструментами непрерывной интеграции и доставки (CI/CD) превращает OpenShift Container Platform в идеальное решение для любой организации.
Преимущества для специалистов IT-систем
OpenShift Container Platform – это корпоративная Kubernetes -платформа приложений с развитыми средствами автоматизации и управления на основе политик. Встроенные средства кластеризации, планирования и оркестрации обеспечивают эффективную балансировку нагрузки и автомасштабирование. Функции безопасности полностью устраняют риски вмешательства tenant - клиентов в работу других приложений или хоста, а возможность подключения постоянного хранилища непосредственно к контейнерам Linux® позволяет одновременно использовать эту платформу для приложений stateful и stateless.
Общие предварительные требования для развертывания OpenShift в Azure
При установке OpenShift используются модули playbook Ansible. Чтобы выполнить действия по установке, Ansible использует Secure Shell (SSH) для подключения ко всем узлам кластера. Когда Ansible создает SSH-подключение к удаленным узлам, нет возможности ввести пароль. Поэтому развертывание завершится сбоем, если с закрытым ключом связана парольная фраза. Так как все виртуальные машины развертываются с помощью шаблонов Azure Resource Manager, для доступа к ним используется один открытый ключ. Нужно включить соответствующий закрытый ключ в виртуальную машину, на которой также выполняются все модули playbook. Чтобы сделать это безопасно, используйте Azure Key Vault для передачи закрытого ключа в виртуальную машину. Если контейнерам требуется постоянное хранилище, вам понадобятся постоянные тома. OpenShift поддерживает виртуальные жесткие диски Azure (VHD) для этой возможности, но сначала требуется настроить Azure в качестве поставщика облачных услуг. В этой модели OpenShift выполняет следующие действия:
- Создает объект виртуального жесткого диска в учетной записи хранения Azure или на управляемом диске;
- Подключает виртуальный жесткий диск к виртуальной машине и форматирует том;
- Подключает том к модулю.
Чтобы эта конфигурация работала, OpenShift нужны разрешения на выполнение указанных выше задач в Azure. Это достигается с помощью субъекта-службы. Субъект-служба — это учетная запись безопасности в Azure Active Directory, которой предоставляются разрешения на доступ к ресурсам. Субъект-служба должна иметь доступ к учетным записям хранения и виртуальным машинам, входящим в состав кластера. При развертывании всех ресурсов кластера OpenShift в одной группе ресурсов субъект-служба может получить разрешения на доступ к этой группе ресурсов. В этом руководстве описывается создание артефактов, связанных с необходимыми компонентами.
- Создайте хранилище ключей, чтобы управлять ключами SSH для кластера OpenShift.
- Создайте субъект-службу, которую будет использовать поставщик облачных служб Azure.
Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Создание группы ресурсов
Создаем группу ресурсов с помощью команды az group create . Группа ресурсов Azure является логическим контейнером, в котором происходит развертывание ресурсов Azure и управление ими. Рекомендуется использовать выделенную группу ресурсов для размещения хранилища ключей. Эта группа отделена от группы ресурсов, в которой развертываются ресурсы кластера OpenShift. В следующем примере создается группа ресурсов с именем keyvaultrg в расположении eastus:
Создание хранилища ключей
Создайте хранилище ключей, где будут храниться ключи SSH для кластера, с помощью команды az keyvault create. Имя хранилища ключей должно быть глобально уникальным. В следующем примере создается хранилище ключей с именем keyvault в группе ресурсов keyvaultrg:
Создание ключа SSH
Ключ SSH необходим для защиты доступа к кластеру OpenShift. Создаем пару ключей SSH с помощью команды ssh-keygen (в Linux или macOS):
Сохранение закрытого ключа SSH в Azure Key Vault
Развертывание OpenShift использует созданный ключ SSH, чтобы защитить доступ к основному кластеру OpenShift. Чтобы обеспечить для развертывания безопасное извлечение ключа SSH, следует ключ в Key Vault с помощью следующей команды:
Создание субъекта-службы
OpenShift взаимодействует с Azure, используя имя пользователя и пароль или субъект-службу. Субъект-служба Azure является удостоверением безопасности, которое можно использовать с приложениями, службами и инструментами автоматизации, такими как OpenShift. Разработчик определять разрешения на то, какие операции может выполнять субъект-служба в Azure, и управлять ими. Рекомендуется ограничить область разрешений субъекта-службы определенными группами ресурсов, а не всей подпиской. Создаем субъект-службу с помощью команды az ad sp create-for-rbac и выведем учетные данные, необходимые для OpenShift: В следующем примере создается субъект-служба, а группе ресурсов с именем openshiftrg назначаются разрешения участника. Прежде всего создаем группу ресурсов с именем openshiftrg:
Если действия совершаются на Windows, следует выполнить az group show --name openshiftrg --query id и использовать полученные выходные данные вместо $scope. Запишите свойство appId, возвращенное из команды:
Далее рассмотрим как развернуть сам кластер OpenShift.
Развертывание платформы контейнеров OpenShift в Azure
Развертывание платформы контейнеров OpenShift с помощью шаблона Resource Manager
Для развертывания с использованием шаблона Resource Manager используется файл параметров, в котором указываются входные параметры. Для дополнительной настройки развертывания следует создать вилку репозитория GitHub и измените нужные элементы. Например, достаточно часто возникает потребность изменить следующие параметры:
- размер виртуальной машины-бастиона (переменная в azuredeploy.json);
- соглашения об именовании (переменные в azuredeploy.json);
- особенности кластера OpenShift, изменяемые в файле hosts (deployOpenShift.sh).
Настройка файла параметров
Шаблон платформы контейнеров OpenShift содержит несколько ветвей для разных версий платформы контейнеров OpenShift. В соответствии с потребностями можно выполнять развертывание непосредственно из репозитория или создать вилку репозитория, чтобы вносить нужные изменения в шаблоны и скрипты перед развертыванием. Используйте значение appId созданной ранее субъект-службы для параметра aadClientId . В примере ниже представлен файл параметров с именем azuredeploy.parameters.json, который содержит все необходимые входные данные.
Разные выпуски могут иметь разные параметры, поэтому следует проверить необходимые параметры для используемой ветви.
Развертывание с помощью Azure CLI
В примере ниже кластер OpenShift и все связанные ресурсы развертываются в группу ресурсов openshiftrg с именем развертывания myOpenShiftCluster. Репозиторий GitHub ссылается непосредственно на шаблон, при этом используется локальный файл параметров с именем azuredeploy.parameters.json.
Для завершения развертывания требуется не менее 30 минут в зависимости от общего количества развертываемых узлов и настроенных параметров. После завершения развертывания в терминале отобразятся полное доменное имя DNS узла-бастиона и URL-адрес консоли OpenShift.
Чтобы окно командной строки оставалось ожидать завершения развертывания, необходимо добавить --no-wait в число параметров при развертывании группы. Выходные данные из развертывания можно получить на портале Azure в разделе развертывания для группы ресурсов [Источник 3] .
Развертывание платформы контейнеров OpenShift с помощью предложения Azure Marketplace
Для развертывания платформы OpenShift Container Platform в Azure проще всего использовать предложение Azure Marketplace. Это самый простой вариант, но он имеет ограниченные возможности для настройки. Предложение Marketplace включает в себя следующие параметры конфигурации: Master Nodes (Главные узлы): три главных узла, для которых можно указать тип экземпляра. Infra Nodes (Узлы Infra): три узла Infra, для которых можно указать тип экземпляра. Nodes (Узлы): здесь можно настроить число узлов (от 2 до 9) и тип экземпляров. Disk Type (Тип диска): используются Управляемые диски. Networking (Сеть): поддержка новой или существующей сети, а также пользовательского диапазона CIDR. CNS: позволяет включить CNS. Metrics (Метрики): позволяет включить метрики. Logging (Ведение журнала): позволяет включить ведение журнала. Azure Cloud Provider (Поставщик облачных служб): позволяет включить поставщик облачных служб.
Подключение к кластеру OpenShift
Очистка ресурсов
Если группа ресурсов, кластер OpenShift и все связанные ресурсы больше не нужны, их можно удалить с помощью команды az group delete .
Читайте также: