okd openshift что это
Использование OpenShift в Azure
Применимо к: ✔️ виртуальные машины Linux ✔️ гибкие масштабируемые наборы
OpenShift — это открытая и расширяемая платформа приложений-контейнеров, которая позволяет использовать Docker и Kubernetes на предприятии.
OpenShift включает Kubernetes для оркестрации контейнеров и управления ими. Здесь добавлены инструменты для разработчиков и операций, позволяющие:
Существует несколько доступных версий OpenShift. Из этих версий только две пользователи могут использовать для развертывания в Azure: платформа контейнеров OpenShift и OKD (прежнее название OpenShift Origin).
Azure Red Hat OpenShift
Microsoft Azure Red Hat OpenShift представляет собой полностью управляемое предложение OpenShift, выполняемое в Azure. Эта служба управляется и поддерживается совместно корпорацией Майкрософт и Red Hat. Дополнительные сведения см. в документации по службе Azure Red Hat OpenShift.
Платформа контейнеров OpenShift
OpenShift Container Platform — это коммерческая версия корпоративного класса, которая разрабатывается и поддерживается компанией Red Hat. Чтобы использовать эту версию, клиенты должен приобрести необходимые права доступа к платформе OpenShift Container Platform. Кроме того, они сами устанавливают и администрируют всю инфраструктуру.
Так как клиенты являются владельцами самой платформы, они могут установить ее в локальном центре обработки данных или в общедоступном облаке (например, в Azure).
OKD — это высокоуровневый проект OpenShift с открытым кодом, который поддерживается сообществом. OKD можно установить в ОС CentOS или Red Hat Enterprise Linux (RHEL).
OKD4 – общедоступный релиз уже здесь
Рабочая группа OKD рада сообщить о выходе общедоступного релиза системы OKD4, которая представляет собой community-версию Red Hat OpenShift Kubernetes.
Red Hat в очередной раз подтверждает приверженность принципам open source и открытого сотрудничества с сообществами разработки Kubernetes и других облачно-ориентированных инициатив.
Истоки OKD
Когда в апреле 2012 года Red Hat впервые запустила Origin как опенсорсный upstream-вариант OpenShift, было сложно представить, насколько быстрым и успешным будет развитие облачно-ориентированных технологий. Последующие годы запомнились взлетом контейнеров, созданием OCI и Fedora CoreOS, а также недавним переездом Operator Framework под крышу CNCF. Без этих инновационных технологий и сообществ, в которых они были созданы, появление OKD4 было бы невозможно.
Во время релиза третьей версии OKD выступал в качестве стабильной основы для OpenShift Container Platform, играя роль upstream-дистрибутива на основе community-компонентов, таких как CentOS, Project Atomic и других. С появлением Universal Base Image взаимоотношения между OKD и OCP изменились: на смену формату upstream-downstream пришло то, что мы называем «родственные дистрибутивы» (sibling distributions). Образы теперь строятся на базе RHEL7 и могут распространяться одновременно и для OKD, и для OCP без какой-либо пересборки. В результате это позволяет обоим дистрибутивам получать обновления, включая исправления безопасности RHEL7, а также обеспечивает стабильный базис для Red Hat Enterprise Linux.
В OpenShift 4.x особое внимание уделяется высокой доступности, наблюдаемости и бесшовном обновлении. С выходом OKD 4 сообщество не только получает автоматический доступ к этим функциям, но и возможность влиять на развитие платформы (через репозиторий процесс улучшений), а также пространство для экспериментов, дискуссий и обмена знаниями. Широко используемый в OKD 4 шаблон Operators позволяет пользователям эффективно сопровождать кластеры на протяжении всего срока службы.
Особенности релиза
OKD4 использует в качестве базовой ОС для своих узлов Fedora CoreOS, предоставляя кластер с последними исправлениями безопасности, новыми функциями (вроде cgroups v2) и обновленным ПО. OKD4 использует те же образы, что и соответствующая версия OpenShift Container Platform. Поэтому сообщество может полноценно участвовать в разработке системы и модифицировать любые части кластера для достижения тех или иных целей.
При этом кластер сохраняет знакомые по OKD3 особенности: его можно устанавливать в user environment, конфигурировать по своему вкусу и обновлять.
В чем отличия OKD от OCP
У OKD4 есть ряд важных отличий от OCP:
Во-первых, как community-дистрибутиву ему не нужен pull-секрет с сайта https://openshift.com/try. Все образы OKD4 доступны без дополнительной аутентификации. Базовый образ ОС для OKD4 загружается с сайта https://getfedora.org/en/coreos/download/. Однако для некоторых опциональных операторов с сайта operatorhub.io pull-секрет все же требуется, поэтому по умолчанию OKD4 устанавливает исходник только с community-операторами, подробнее см. FAQ.
Во-вторых, OCP – это особый дистрибутив Kubernetes, с упором на высокую доступность и продакшн-нагрузки. Отсюда и ограничения на конфигурацию кластеров – например, не поддерживаются конфигурации single master. В свою очередь, OKD4 легко позволяет создавать такие конфигурации для тех же девелоперских или тестовых stage-сред. Хотя такие кластеры и нельзя потом обновить до следующей версии.
Новые nightly-релизы OKD4 создаются после того, как OCP проходит тестирование в рамках нашей системы CI. Каждые две недели мы будем перемещать nightly-релиз в канал stable, чтобы пользователи могли получать обновления к новейшему и оттестированному коду без переключения каналов.
Как приступить к работе с OKD4
OKD4 устанавливается так же легко, как и OCP4, см. инструкции в руководстве Getting Started.
Документация по OKD доступна на сайте docs.okd.io
Сообщать о неполадках можно на OKD Github Repo по адресу https://github.com/openshift/okd
Уже пользуетесь OKD?
В этом случае потратьте, пожалуйста, пять минут на заполнение опросника OKD Adoption, чтобы помочь рабочей группа OKD планировать дальнейшее развитие проекта и лучше понять характер рабочих нагрузок, для которых он применяется!
Включайтесь в работу
На сайте сообщества OKD.io можно загрузить последний релиз, ознакомиться с ключевыми upstream-проектами, над которыми мы работаем, лучше узнать наших конечных пользователей и рабочие нагрузки, для которых используется OKD, а также найти ссылки на последние информационные ресурсы.
Рабочая группа OKD собирается дважды в неделю, чтобы обсудить текущее состояние и последующие шаги разработки. Время и место встреч отслеживаются в репо openshift/community.
Повестку и детали предстоящих встреч можно найти здесь: https://github.com/openshift/community/projects/1
Русскоязычное сообщество OpenShift в Telegram:
https://t.me/ru_openshift
Вступайте в наши ряды
Сообщество OpenShift Commons насчитывает более 590 организаций-участников, которые ведут совместную работу над OpenShift. Сообщество открыто для всех: пользователей, операторов, предприятий, стартапов, некоммерческих организаций, образовательных учреждений, партнеров и поставщиков услуг.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
OpenShift
Содержание
Обзор
OpenShift включает Kubernetes для оркестрации контейнеров и управления ими. Здесь добавлены инструменты для разработчиков и операций, позволяющие:
Существует несколько версий OpenShift:
Платформа контейнеров 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 — это мультитенантная среда, контейнеры могут размещаться на тех же узлах виртуальных машин, что и контейнеры других клиентов. Стоимость вычисляется из расчета на один контейнер.
Преимущества для разработчиков
Преимущества для специалистов IT-систем
Общие предварительные требования для развертывания OpenShift в Azure
При установке OpenShift используются модули playbook Ansible. Чтобы выполнить действия по установке, Ansible использует Secure Shell (SSH) для подключения ко всем узлам кластера. Когда Ansible создает SSH-подключение к удаленным узлам, нет возможности ввести пароль. Поэтому развертывание завершится сбоем, если с закрытым ключом связана парольная фраза. Так как все виртуальные машины развертываются с помощью шаблонов Azure Resource Manager, для доступа к ним используется один открытый ключ. Нужно включить соответствующий закрытый ключ в виртуальную машину, на которой также выполняются все модули playbook. Чтобы сделать это безопасно, используйте Azure Key Vault для передачи закрытого ключа в виртуальную машину. Если контейнерам требуется постоянное хранилище, вам понадобятся постоянные тома. OpenShift поддерживает виртуальные жесткие диски Azure (VHD) для этой возможности, но сначала требуется настроить Azure в качестве поставщика облачных услуг. В этой модели OpenShift выполняет следующие действия:
Чтобы эта конфигурация работала, OpenShift нужны разрешения на выполнение указанных выше задач в Azure. Это достигается с помощью субъекта-службы. Субъект-служба — это учетная запись безопасности в Azure Active Directory, которой предоставляются разрешения на доступ к ресурсам. Субъект-служба должна иметь доступ к учетным записям хранения и виртуальным машинам, входящим в состав кластера. При развертывании всех ресурсов кластера OpenShift в одной группе ресурсов субъект-служба может получить разрешения на доступ к этой группе ресурсов. В этом руководстве описывается создание артефактов, связанных с необходимыми компонентами.
Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Вход в azzure
Входим в Azure с помощью команды az login и следуем инструкциям на экране или щелкаем «Попробовать», чтобы использовать Cloud Shell.
Создание группы ресурсов
Создание хранилища ключей
Создайте хранилище ключей, где будут храниться ключи 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:
Далее рассмотрим как развернуть сам кластер OpenShift.
Развертывание платформы контейнеров OpenShift в Azure
Для развертывания платформы OpenShift Container Platform в Azure можно использовать один из нескольких способов: Можно вручную развернуть необходимые компоненты инфраструктуры Azure, а затем следовать инструкциям из документации по платформе OpenShift Container Platform. Также можно использовать существующий шаблон Resource Manager, упрощающий развертывание кластера платформы OpenShift Container Platform. Другой вариант — использовать предложение Azure Marketplace. Для всех вариантов подписка Red Hat является обязательной. Во время развертывания экземпляр Red Hat Enterprise Linux регистрируется в подписке Red Hat и связывается с идентификатором пула, который содержит права доступа к платформе OpenShift Container Platform. Убедитесь, что у вас есть действительное имя пользователя, пароль и идентификатор пула диспетчера подписки Red Hat (RHSM). Можно также использовать ключ активации, идентификатор организации и идентификатор пула. Данные можно проверить, войдя на сайт https://access.redhat.com.
Развертывание платформы контейнеров OpenShift с помощью шаблона Resource Manager
Для развертывания с использованием шаблона Resource Manager используется файл параметров, в котором указываются входные параметры. Для дополнительной настройки развертывания следует создать вилку репозитория GitHub и измените нужные элементы. Например, достаточно часто возникает потребность изменить следующие параметры:
Настройка файла параметров
Разные выпуски могут иметь разные параметры, поэтому следует проверить необходимые параметры для используемой ветви.
Развертывание с помощью Azure CLI
В примере ниже кластер OpenShift и все связанные ресурсы развертываются в группу ресурсов openshiftrg с именем развертывания myOpenShiftCluster. Репозиторий GitHub ссылается непосредственно на шаблон, при этом используется локальный файл параметров с именем azuredeploy.parameters.json.
Для завершения развертывания требуется не менее 30 минут в зависимости от общего количества развертываемых узлов и настроенных параметров. После завершения развертывания в терминале отобразятся полное доменное имя DNS узла-бастиона и URL-адрес консоли OpenShift.
Развертывание платформы контейнеров 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
Очистка ресурсов
Как Sec примерил сбрую Ops, или deploy Red Hat OKD 3.11 for dummies
Прошлой осенью мне по работе понадобилось протестировать решения для защиты сред контейнеризации (я работаю ИБ-инженером), но готового стенда с микросервисной архитектурой для этого не оказалось. Мотор-то мы купили, да трактор… у нас украли. Почувствовался резкий дефицит систем оркестрации контейнеров, и в воздухе запахло приключением!
Так как мои Ops коллеги всегда на острие интеграций и внедрений, денно и нощно разворачивают сложнейшие системы и вычислительные комплексы, просить их «по-быстренькому запилить кластер OpenShift» совсем не укладывалось в концепт инженерной солидарности. Поэтому я принял волевое решение — делать самому! Не без советов коллег, разумеется, ибо с Sec’ом да прибудет мудрость Ops’а.
Забегая вперед, скажу, что в итоге стенд удался и даже вполне себе работает по сей день, а мне хочется поделиться с вами полученным опытом.
Итак, речь пойдет о платформе оркестрации Red Hat OKD 3.11. Сразу оговорюсь, что, хотя уже вышла ее новая, четвертая мажорная версия, предыдущие все еще широко используются для работы микросервисных приложений в контейнерах. Даже там, где в test уже пробуют 4.x, в prod по-прежнему частенько задействуют 3.x.
Решение Red Hat OKD 3.11 весьма любопытное, однако общественное мнение о нем противоречивое.
— Смузи и подвороты! Навесили свистелок на Vanilla Kubernetes и толкают как энтерпрайз. Proof me wrong!
— А еще раньше на корове деревянным плугом пахали. Если собрали все в кучу и заставили работать хорошо, да еще вдогонку дали вендорскую поддержку, почему бы и нет?
Бабка ставит самовар, да начнется холивар…
И, как вы уже успели заметить, комментарии моего альтер эго могут проскакивать по тексту в скобочках <> — не пугайтесь.
Дисклеймер: мнение автора может не совпадать с мнением редакции, маркетингового департамента Red Hat, президента Уругвая и кошки автора!
С чего начать?
Master — это управляющие серверы, на которых работает ядро системы. Они управляют развертыванием контейнеров, хранят в себе конфигурации системы, на них шуршит API, через который все компоненты системы общаются между собой. Короче говоря, мозги. Минимальное количество — один.
Worker — рабочий сервер, в первом приближении — «ведро» контейнеров. По сути это вычислительная среда, предоставляющая мощности для работы контейнеров. Управляются, как и следовало ожидать, мастерами. Минимальное количество — два.
Infra — тоже воркер, но служебный. На нем развернуты сервисные контейнеры внутреннего реестра образов (где хранятся образы), роутер (контейнерный маршрутизатор, об этом позже) и контейнеры системы мониторинга (сбор и отображение метрик о состоянии системы). Контейнеры с другими приложениями на нем не поднимаются. Минимальное количество — один.
Вся система представляет собой набор контейнеров, а в нашей инсталляции будет еще отдельный сервер под NFS и DNS, на нем же развернем Ansible, с помощью которого выполним установку. Ну, и простим платформе ее жирноту в угоду удобству и отказоустойчивости.
Разберемся, что к чему
Мой on-premise стенд обладает следующими характеристиками:
Развернул я все это добро в облаке vCloud, где создал виртуальные машины с указанными характеристиками. На каждой из них установил CentOS 7.4-1708 в паке web-server (оптимальный вариант, т.к. занимает не слишком много места, и большинство нужных пакетов уже есть), создал привилегированных пользователей и через network manager прописал сетевые настройки. Так что все серверы доступны друг для друга.
Хранение данных
Все долгосрочное хранение данных контейнеризированных сервисов в моем случае будет расположено на NFS (сервер Bastion) в каталогах persistent volume’ов, поэтому можно обойтись без большой дисковой емкости непосредственно на самих нодах. Контейнеры хранят данные внутри себя в течение жизненного цикла, то есть, пока не будут остановлены. Если требуется постоянное хранение данных, не зависящее от удаления и перезапуска контейнеров, то оно происходит в сущности под названием persistent volume. Это своего рода каталог с данными, доступными определенным контейнерам в соответствии с настроенными политиками доступа. Грубо говоря, приложение в контейнере записывает данные в persistent volume, под которым по факту находится каталог NFS, куда попадут эти данные. После перезапуска контейнера или, например, добавления второй реплики контейнера с приложением оба приложения из обоих контейнеров все равно будут иметь доступ к этим данным.
Я выбрал NFS, потому что его просто и быстро развернуть, благо в интернете полно инструкций и гайдов. Однако вендор не рекомендует использовать такой вариант в prod. Для тестов, демо и всего такого его вполне достаточно, но в prod могут возникнуть сложности. Например, OpenShift не создает каталоги на NFS для хранения данных, их придется создать и экспортировать заранее. Для сотен и тысяч контейнеров в сотнях проектов создавать каталоги руками будет не гуд.
Давайте вернемся к платформе. В идеальном мире конфигурация платформы будет примерно такой, как на рисунке ниже. Это полная рекомендуемая инсталляция — дальше можно масштабировать добавлением worker’ов, сколько влезет.
Три Master ноды — обеспечивают отказоустойчивость для зачач хранения конфигураций (etcd datastore), управления репликами контейнеров (Replication controller) и планирования развертывания новых контейнеров (scheduler), а также служат для управления системой.
Три Worker ноды (они же Application Node) — по ним равномерно размазываются контейнеры с приложениями (если не настроено иначе), причем в случае отказа какой-то ноды они перетекут на другие.
Три Infra ноды — тут все происходит по аналогии с worker, только со служебными контейнерами.
Load Balancer — условно говоря, это как бы NAT для виртуальной внутренней сети, к которой подключены контейнеры и роутер для трафика между ними. Детально рассматривать не буду, потому как непосредственно его настраивать не стану. Скажу только, что это виртуальный маршрутизатор, умеющий разруливать сетевой трафик и раскидывать его по нужным контейнерным сервисам.
Ansible Master — этот компонент не является частью непосредственно платформы, но стоит упоминания. Если вы сталкиваетесь с ним впервые, вот пара слов о том, что это и зачем:
«Ansible — система управления конфигурациями, написанная на языке программирования Python, с использованием декларативного языка разметки для описания конфигураций. Используется для автоматизации настройки и развертывания программного обеспечения». Wiki
Попробую объяснить на пальцах, как это работает: мастер-хост Ansible подключается по сети к целевым хостам и может автоматически их настраивать. Чтобы это работало, у него есть первое — файл inventory, в котором прописаны параметры доступа к целевым хостам: их IP-адреса, пользователь, под которым нужно подключаться, и его пароль (это минимум). И второе — playbook, то есть перечень заданных значений параметров для настройки. Ansible проверяет значение конкретного параметра и задает необходимый. Грубо говоря, система проверяет systemctl is-enabled docker и ожидаемое значение, например enabled, если значение от целевого хоста возвращается disabled, соответственно, выполняет systemctl enable docker, задав таким образом требуемое значение параметра. Пример деревянный, но суть приблизительно такая.
В сложных системах применяются переменные для значений параметров конфигураций, SSH-ключи для авторизации, дочерние группы хостов для группировок целевых хостов по различным типам и много других крутых штук, которые очень полезны, но тянут на отдельную статью. Когда столкнемся с ними по ходу установки, посмотрим чуть детальнее.
Пока нам достаточно понимать, что это сервер, который умеет настраивать другие серверы. Очень полезная вещь, если на целевом сервере нужно много всего настроить, и таких серверов большое количество. Делать он это может отправкой команд на целевые хосты либо заливкой конфигурации из файла. Естественно, при условии сетевой связности машин.
Порядок действий по установке системы есть в инструкции на портале вендора, но отдельно обращу внимание на некоторые моменты, где есть нюансы:
1. Настроить сетевые адаптеры и hostname на хостах
С помощью network manager’а задаю конфигурацию сети, сразу указываю свой будущий DNS — ничего необычного. Мне удобнее через nmtui.
для worker-1 и так далее.
Домен okd.local у меня будет локальным, для него я создам отдельную DNS-зону. Вы можете придумать домен по своему вкусу. Cпокуха, мы сейчас до этого дойдем. Выполнить эту настройку, соответственно, нужно для всех master, worker и infra нод.
2. Установить и запустить DNS-сервер
В моем случае — просто Bind. Нужен для отработки запросов в кластерном домене. Приложения внутри кластера могут общаться между собой в том числе через доменные имена. Все эти доменные имена будут расположены в кластерной зоне, которую DNS и обслуживает.
Запускаю и включаю автозагрузку сервиса:
Открываю и привожу файл конфигурации bind /var/named/chroot/etc/named.conf к следующему виду (убрал под спойлер):
options <
listen-on port 53 < any; >;
listen-on-v6 port 53 < none; >;
directory «/var/named»;
dump-file «/var/named/data/cache_dump.db»;
allow-query < 127.0.0.1; 192.168.7.0/24; >;
recursion yes;
allow-recursion < 127.0.0.1; 192.168.7.0/24; >;
forwarders < 8.8.8.8; >;
version «DNS Server»;
managed-keys-directory «/var/named/dynamic»;
pid-file «/run/named/named.pid»;
session-keyfile «/run/named/session.key»;
dnssec-enable no;
dnssec-validation no;
>;
zone «.» IN <
type hint;
file «named.ca»;
>;
include «/etc/named.rfc1912.zones»;
include «/etc/named.root.key»;
logging <
channel default_file <
file «/var/log/named/default.log» versions 3 size 5m;
severity dynamic;
print-time yes;
>;
category default < default_file; >;
>;
Я задал такие параметры:
Если совсем лень, можете все оставить по умолчанию — работать будет. Идем дальше.
3. Настроить локальную зону DNS
Для начала, собственно, нужно создать эту зону. Я описываю файл зоны в named.conf (т.е. говорю named’у: «Параметры зоны ищи там-то») и указываю файл зоны в конце файла. Вот так:
И содержимое файла (под спойлером):
@ IN SOA okd. okd.local. (
1192648703
10800
3600
604800
38400
);
@ IN NS localhost.
console IN CNAME master
bastion IN A 10.31.хх.30
master IN A 10.31.хх.32
api IN A 10.31.хх.32
api-int IN A 10.31.хх.32
infra IN A 10.31.хх.31
worker-1 IN A 10.31.хх.33
worker-2 IN A 10.31.хх.34
*.okd.local IN A 10.31.хх.31
И сохраняю (в nano ctrl+x).
Пара слов о том, что я сделал: создал новую зону, которую будет резолвить DNS-сервер, и указал в ней необходимые хосты. Я сказал DNS’у, что все запросы на master, api, infra и т.д. будут попадать на соответствующие хосты, и указал их IP-адреса. Тут ничего сложного, но что за API?
Это — API-сервер самого OpenShift (сиречь — Kubernetes), с помощью которого пользователь и компоненты системы могут общаться с ее ядром, а также компоненты между собой. Например, программы oc и kubectl (пользовательские консольные оболочки) производят ввод-вывод как раз через этот API. Если вы говорите системе oc get nodes (команда показать статус нод кластера), oc под капотом делает запрос в API, а он в свою очередь возвращает ответ, который oc переводит в понятный человеку вид…
Такой записью я в явном виде указал, что этот API работает на master.
Короче говоря, файл зоны я создал, сохранил и скормил Named’у. Теперь давайте перезапустим DNS и посмотрим, чтобы не было ошибок:
Команда должна выполниться и ничего не писать в ответ. Если получилось иначе, посмотрите сообщение об ошибке: она подскажет, где проверить, что именно пошло не так. Обычно для этого нужно обратиться в /var/log/messages или journalctl. Что именно там смотреть, вы также узнаете из сообщения об ошибке.
Для этого проверьте настройку DNS в /etc/resolv.conf, конфигурацию hostname, и отвечают ли серверы по именам. Например, так:
В /etc/resolve.conf убедитесь, что прописан верный DNS.
Проверьте на нодах hostname.
Проверьте, что ноды пингуются по имени.
nslookup или dig’ом проверьте, что ноды резолвятся с правильным доменным именем.
Соответственно, все это надо проверить на всех нодах кластера, включая сервер с DNS. Важно, чтобы настройки были идентичны на всех серверах, и для каждого были соответствующие. Например, hostname для master был master.okd.local, для infra — infra.okd.local и так далее. Если все верно — отлично, если нет — приведите к правильному виду. Лучше перепроверьте все сейчас, чем потом будете долго и муторно выискивать ошибку. Поехали дальше…
4. Теперь перейдем к подготовке Ansible master
Настроим беспарольное подключение по SSH для выполнения Ansible плейбуков. С этого момента можно считать, что мы приступили к установке OpenShift. Отключать пароли я не буду — просто сгенерирую ключи и импортирую их на хост Ansible master.
На каждом хосте сгенерируйте SSH-ключи. Как я уже говорил, они понадобятся для того, чтобы Ansible master мог подключиться под привилегированным пользователем и выполнять команды настройки хостов так, чтобы при этом приходилось вручную вводить пароли пользователей. Для этого на всех целевых хостах выполните:
И на все вопросы протыкайте Enter. В итоге сервер покажет директорию, в которой сохранен ключ, его отпечаток и рандомарт.
После этого, собственно, беспарольное подключение. Если вы хоть раз пользовались Ansible, вам все должно быть понятно. Если такого опыта у вас не было, поясню: Ansible выполняет команды на целевых хостах, будучи залогиненым на них указанным пользователем и подключенным по SSH. Чтобы плейбук (или простая ad-hoc команда) мог отрабатывать, ему нужно указать адрес хоста назначения, пользователя, под которым Ansible должен подключаться, и в самом простом случае — пароль. Чтобы каждый раз не подтверждать подключение и не вводить пароль, импортируйте публичные SSH-ключи с целевых машин на Ansible master. Разумеется, ключи должны быть уже сгенерированы (см. выше). Для этого на Bastion (который Ansible master) выполняем:
/.ssh/id_rsa.pub должны появиться скопированные ключи. Проверить, что все в порядке, можно путем подключения с Bastion к каждому хосту. Категорически рекомендую и жалостливо умоляю это сделать:
На запрос подтверждения нужно ответить yes. Сервер должен залогиниться на каждый хост без ввода пароля, а благодаря тому, что мы приняли предложение подключиться, больше оно появляться не будет. Для отработки плейбуков это хорошо: не надо будет каждый раз при их запуске жмакать yes.
5. Установить и обновить требуемые пакеты
Все там же, на хосте Bastion.
Тут есть нюанс. Указанный порядок работает для CentOS, а для RHEL процедура выглядит несколько иначе. Например, в RHEL нужно активировать подписку на обновления через subcribition manager, зарегистрировать на портале Red Hat свои хосты, выбрать необходимые репозитории и производить установку с них. В моем же случае, т.к. CentOS на портале не зарегистрировать, выполняю простую установку при помощи RPM-пакетов. Результат будет одинаковый, так что это не принципиально.
Подробнее об этом можно посмотреть в инструкции.
В принципе, не все из указанного может понадобиться, но это полный пак утилит для настройки и траблшутинга возможных проблем. Поэтому лучше не ломаться, а поставить все:
6. Установить требуемые репозитории
Устанавливаю репозиторий epel, с него загружу Ansible.
Глобально выключаю репозиторий, чтобы в дальнейшем по умолчанию пакеты грузились и обновлялись с дефолтных репо.
И наконец выполняю установку ansible rpm из репозитория epel:
7. Скачать архив плейбуков
Тут каточка на изи: я сходил в домашний каталог, склонировал в него с Гитхаба архив с плейбуками и всеми нужными файлами и убедился, что взял нужную версию.
8. Установить Docker, создать docker storage
Это делаю на нодах master, infra и обоих worker! Там, где платформа будет крутиться.
Что я сделал? Установил Docker в качестве контейнерного движка и включил его хранилище. Но помните, что это сторадж для хранения загруженных образов и вообще для самого докера. Это не сторадж для приложений в контейнере, его нужно будет создать в самой платформе позже. Вообще, на этом этапе можно не останавливаться подробно, потому что конфигурацию хранилища, ее безопасность и прочие нужные штуки возьмет на себя OpenShift. Docker будет тупо запускать контейнеры так, как скажет платформа.
Хранение тут я оставил по самому дефолтному дефолту, и дополнительных настроек обычно не требуется. Однако в некоторых случаях может появиться надобность что-то сконфигурировать. Я использую простой драйвер device-mapper, а для хранилища — простые блочные устройства, диски /sda, /sdb и так далее.
9. Отредактировать inventory файл
Первым делом приведу ссылку на документацию по этому разделу. Она понадобится… I know that feel bro…
Тут остановлюсь чуть подробнее, так как здесь большой кусочек боли и бессонницы — верных спутников первой установки OpenShift 3.x. Inventory файл описывает установку платформы, типы и роли ее нод, конфигурацию дополнительных модулей и много всего прочего. Он хранит в себе переменные, используемые плейбуком при выполнении, и их целевые значения. В самом простом случае inventory файл мог бы выглядеть как-то так (это пример с тестового стенда, Openshift тут ни при чем — просто для наглядности):
Тут можно увидеть группы серверов (RHEL, DEBIAN, windows), называются они Children — дочерние как бы. Например, если надо установить на все серверы net-tools, то для RHEL based операционных систем хостов команда в плейбуке будет yum install net-tools, а для Debian based Ubuntu — apt-get install net-tools. Вот для того, чтобы один плейбук, пытающийся выполнить две эти команды, не валил сразу на все серверы в логи ошибку о том, что он не может выполнить yum на Ubuntu и apt-get на RHEL, целевые хосты можно разбить на группы. Для группы RHEL выполнять плейбук с yum, а для Ubuntu — с apt-get. Очень топорный пример, но суть, думаю, понятна.
Соответственно, в каждой группе указан хост с придуманным именем (-=CentOS-1=- / 2 и так далее), отображаться он будет только при выполнении плейбука. Это нужно для того, чтобы пользователь понимал, на каком хосте что происходит, и где случилась ошибка. Присутствует IP-адрес этого хоста, пользователь для подключения и его пароль.
Да, кстати, Windows Ansible тоже умеет конфигурировать, он делает это по-другому, и, пожалуйста, давайте не будем об этом, мы здесь сейчас не за этим.
Так вот, в inventory файле для развертывания OpenShift все хосты также разделены на группы по их ролям (master, worker, infra и все такое), а еще сразу добавлены переменные конфигурации самой системы. То есть сначала, при выполнении, Ansible подгоняет конфигурации хостов к целевым (это плейбук prerequisites.yml), а далее, когда он начинает разворачивать систему (плейбук deploy-cluster.yml) и задавать параметры ее конфигурации, то берет эти самые параметры из указанных в inventory переменных.
Возвращаясь к тому, как выглядит invetory файл: спрятал под спойлер мой inventory от OpenShift — там чад кутежа, например.
Пф-ф-ф, да все понятно, ваще изи…
openshift_master_default_subdomain=apps.okd.local — здесь и далее укажите домен из созданной зоны, у меня это okd.local.
openshift_master_cluster_hostname=api.okd.local
openshift_master_cluster_public_hostname=console.okd.local
openshift_console_hostname=console.apps.okd.local
openshift_metrics_storage_volume_size=40Gi — тут можете указать размер хранилища метрик мониторинга.
openshift_logging_storage_volume_size=50Gi — здесь можете указать размер хранилища логов.
openshift_hosted_etcd_storage_volume_size=5G — можете указать размер хранилища etcd, это хранилище конфигураций.
Дальше те самые Children группы. В данном случае они привязаны к роли ноды:
# host group for masters
[masters]
master — тут хостнейм мастера.
# host group for etcd
[etcd]
master — тут тоже hostname мастера, потому что конфига хранится на нем.
[nfs]
bastion — хостнейм NFS-сервера (если разворачивали). У меня это Bastion с Ansible, DNS и NFS.
[nodes]
master openshift_node_group_name=«node-config-master» — мастеру указываем роль node-config-master. Trust me, просто указываем.
worker-1 openshift_node_group_name=«node-config-compute» — рабочим нодам указываем роль node-config-compute.
worker-2 openshift_node_group_name=«node-config-compute»
infra openshift_node_group_name=«node-config-infra» — инфра нодам указываем роль node-config-infra.
После всех подготовительных мероприятий требуется запустить плейбук из скачанного пака. Плейбуков там много, и многие из них предназачены для дальнейшего обслуживания, например, расширения хранилища логов и мониторинга, добавления нод в кластер, ротации сертификатов шифрования и т. д.
Хочется сказать пару слов про всю эту установку, поделиться сугубо моими ощущениями. Автоматизация с помощью Ansible — в целом клевая тема, однако для такой сложной штуки, как OpenShift, процесс инсталляции требует огромного количества проверок и конфигураций целевых хостов. В результате вполне возможен сбой по ходу отработки плейбука, что приведет к остановке инсталляции.
Безусловно, Ansible покажет этап, на котором произошла ошибка, некоторое ее описание и так далее. Однако полагать, что причина ошибки будет понятна из отчета выполнения плейбука, к сожалению, очень наивно. Так что, скорее всего, вам придется лезть во всевозможные логи и журналы и анализировать, где произошла ошибка и в чем она заключается. Sad but true…
Однако Red Hat в корне поменял свой подход, и уже в мажорных 4-ых версиях используется операционная система CoreOS, которую можно развернуть на нодах одновременно с инсталляцией платфморы. Очень круто, но об этом в другой раз.
Да где же этот “Install”!?
По завершении Ansible выводит краткую сводку по выполнению. Типа такой, только цифры будут больше:
К каждому хосту из файла inventory приведено количество задач (TASK) из групп плейбуков. Иными словами, это действия по настройке.
11. Выполнить плейбук deploy_cluster.yml
В случае неудачного выполнения плейбука в Ansible предусмотрен режим отладки выполнения. Запустить его можно путем выполнения плейбука с ключом -v. Например:
В таком случае Ansible будет показывать детали выполнения каждой задачи. Чтобы повысить детализацию, добавьте дополнительный ключ -v. Для максимальной детализации укажите 5 ключей (-vvvvv).
12. Доступ к веб-интерфейсу
При успешной установке кластера для доступа на веб-интерфейс надо указать IP-адрес мастер ноды. Я просто прописал в hosts master.okd.local:
10.31.хх.32 console.okd.local
После этого будет доступен веб-интерфейс консоли по адресу https://console.okd.local:8443.
ВАБА – ЛАБА – ДАБ – ДАБ! Кластер проинсталлирован!
Немного ретроспективы и возникшие проблемы
Касательно инсталляции при помощи плейбуков: предполагается запустить первый плейбук, перекурить, налить чай и после его успешного выполнения, минут так через десять—пятнадцать, запустить второй, кластерный деплой. Само собой, этот уже будет пожирнее, и можно даже успеть перекусить: я в этот момент в десятом часу вечера вторника успел дойти от офиса до кафешки с шаурмой, заскочить в ларек за газировкой и вернуться в офис, схомячив шаурму.
И вот, по завершении второго плейбука, вывод команды oc get nodes должен показать все ноды в статусе ready, и веб-консоль оказалась доступна…
По ходу выполнения есть вероятность неявных проблем, например:
1. В файле inventory есть такой параметр:
openshift_disable_check
В моем случае он имеет значение:
В него я добавил выделенный жирным параметр.
Как это было в жизни
При выполнении плейбука prerequisites есть этап Check Docker image availability с хэндлером, он циклично повторяется некоторое количество раз, пока заданный параметр не получит ожидаемое значение — это в контексте Ansible. В реальности же происходило то, что демон Docker искал в публичном реестре некоторый образ, который по какой-то причине был недоступен. Из-за запутанности переменными и ссылками плейбуков на плейбуки найти концы в тот момент мне так и не удалось.
Это был образ консоли внутреннего реестра образов. В OpenShift есть сам реестр образов, в котором можно хранить свои образы, а есть консоль — веб-интерфейс для этого реестра для удобного просмотра содержимого. Образ этой консоли как раз и оказался недоступен, и сама она не работала.
А когда понадобилась, мне пришлось найти новый образ, заменить им старый в конфигурации деплоймента консоли и пересоздать эту консоль. Потому как на момент инсталляции я этого не знал, то решил попробовать добавить проверку в исключение и посмотреть, на чем зафейлится выполнение плейбука дальше.
Это только один из примеров, демонстрирующих неожиданные векторы проблем, которые могут возникнуть при раскатывании OpenShift из плейбуков. Хотя, безусловно, о самой идее попытаться автоматизировать установку так, чтобы после запуска двух плейбуков все само стало ОК, ничего плохого сказать нельзя.
С горем пополам выполнение prerequisites плейбука завершилось успешно, я закинулся валокордином и поставил на выполнение плейбук deploy-cluster. Тут все также гладко не прошло.
2. Возникла ошибка о том, что сетевой плагин SDN не работает.
Главная сложность деплоя посредством набора плейбуков, битком набитых переменными и ссылками на другие плейбуки, заключалась в проблематичности поиска причин ошибок. Например, на этапе установки плагина SDN (внутренней виртуальной сети платформы) Ansible отрапортовал ошибкой. В логах машины будущего мастера оказалось множество ошибок о сетевой недоступности. Как выяснилось сильно позже, проблема была в опечатке в конфиге DNS-зоны. В плейбуке происходила проверка доступности API-сервера по его доменному имени, которое было задано из inventory. В конфигурации DNS-зоны FQDN-имя было написано неправильно, и DNS его не резолвил. В результате API-сервер на master был недоступен, что плейбук интерпретировал как ошибку сетевого плагина.
Знаю-знаю, сам криворукий, но выловить ошибку удалось, только глубоко погрузившись в логи DNS, master ноды и ручную проверку доступности хостов между собой…
Итого
Я не говорю, что способ развертывания плохой. Я лишь утверждаю, что отловить ошибку при инсталляции, да еще на нескольких машинах, тем более на нескольких уровнях абстракции, когда к тому же не понимаешь, что делаешь, очень проблематично.
И вот ошибки отловлены и исправлены, процесс инсталляции завершен, и мы можем пользоваться платформой. Взглянем, что она может нам предложить.
Слышал такое мнение:
Что ж, звучит вполне складно.
Из коробки мы имеем:
Отличий на самом деле много, но первое, с которым вам придется столкнуться, — это процесс инсталляции. Тут вендор кардинально изменил подход, отказавшись от идеи использования Ansible. Вместо этого теперь используется метод инсталляции на хосты образов CoreOS. Это операционная система от Red Hat, позиционируемая вендором как легковесная, специально заточенная под развертывание кластеров, имеющая минимальную необходимую функциональность, в которой приложения работают в контейнерах. Система заливается при помощи PxE-сервера, оттуда же в процессе развертывания подтягиваются все конфигурации, и в целом процесс установки состоит по сути из этапа подготовки всех конфигураций и этапа ожидания, пока все само развернется.
Сам кластер OpenShift 4.x, кстати, работает практически весь в контейнерах и обладает новой сущностью — operator, контейнерами, которые умеют разворачивать другие контейнеры с приложениями и всегда следить за их работоспособностью. Но об этом есть статьи от самого Red Hat 🙂
Собственно, друзья мои, вот мы с вами вместе и установили систему. Теперь можно выдохнуть и похвалить себя. В другой статье мы позанимаемся так называемыми «day 2 operations» — вещами, которые стоит сконфигурировать после инсталляции. И конечно же, не обделим вниманием средства безопасности: я расскажу, что такое Security Context Constraints, Network Policies, и объясню, зачем надо мыть руки перед деплоем приложения!