Если вы раньше имели дело с OpenShift, то знаете насколько трудоемко установить «с нуля» кластер OpenShift �� vSphere. В основном потому, что нужно подготовить окружающую инфраструктуру. В релизе OpenShift 4.5.1 эта задача стала намного легче.
До релиза OpenShift 4.5.1 инсталлировать кластер на платформе vSphere было возможно только в варианте UPI (User Provider Infrastructure). Пользователь должен был самостоятельно подготовить необходимую для установки инфраструктуру, а именно подготовить:
При этом любая ошибка (а как известно — «errare humanum est») в подготовке окружения приводит к неудаче с инсталляцией кластера. Чтобы как-то облегчить эту задачу, стали появляться сторонние проекты для ускорения подготовки окружения и уменьшения в этом процессе влияния «человеческого фактора». Один из самых известных — проект OCP Helper Node, который на одном сервере через Ansible готовит всю необходимую конфигурацию для установки OpenShift. Еще были варианты установки кластера с подготовкой инфраструктуры через Terraform.
Но подобные проекты не решали всех проблем с разворачиванием кластера в vSphere. Часто нужно предоставить кластер OpenShift как услугу («kubernetes as service»), и в этом случае автоматизация установки OpenShift оставалась непростым делом — требовалось ручное вмешательство: соблюдение очередности установки ОС на узлах кластера, подтверждение сертификатов в кластере, ожидание завершения установки cluster operators, и т.д. При необходимости можно автоматизировать и этот процесс, но для этого тоже нужны время и ресурсы, чтобы создать и поддерживать подобные решения.
Начиная с релиза 4.5.1., выпущенного 13 июля 2020 года, OpenShift поддерживает установку в vSphere в варианте IPI (Installer Provided Infrastructure). Это значит, что программа инсталляции теперь умеет:
Кроме этого, после подобной инсталляции администратор одной командой в OpenShift может добавлять или удалять узлы кластера. Или вообще включить autoscaling, предоставив кластеру возможность самостоятельно реагировать на изменения нагрузки.
Но у нового способа инсталляции есть одно ограничение — все узлы кластера, а также сервер, с которого производится инсталляцию, должны иметь прямой доступ в Internet. Если администратор находится за корпоративным proxy-сервером или Internet для кластера недоступен — устанавливать кластер придется как раньше, в варианте UPI.
Совсем без подготовки инфраструктуры при установке OpenShift не обойтись, но список задач стал скромнее:
В нашем случае для установки OpenShift и запуска всех требуемых сервисов использовался сервер shift-is01 под управление CentOS 7.
Здесь ничего специфичного, выделяем пул адресов (192.168.111.100 -192.168.111.150) под серверы OpenShift:
Для нашего кластера создана зона ocp45.demo.local и созданы A и PTR записи для диапазона DHCP. Создаем требуемые OpenShift записи для API и Ingress:
Кусок из BIND zone ocp45.demo.local:
После этого загружаем сертификаты с нашего vCenter и устанавливаем их как доверенные на наш сервер.
Устанавливаем сертификаты vCenter:
Сама процедура установки теперь максимально упрощена:
Загружаем программу инсталляции и PullSecret c RedHat, эта процедура описана в Installation Guide. В нашем примере все необходимые для работы бинарные файлы расположены в директории bin домашней директории пользователя ocp.
При подготовке этого файла с будущей конфигурацией кластера следует обратить внимание на три нюанса.
Во-первых, кластер запомнит конфигурацию рабочих узлов кластера (worker node), определенных в install-config. И все последующие узлы, которые вы будете создавать при масштабировании кластера, окажутся ровно такой же конфигурации. Поэтому необходимо сразу определится с оптимальной конфигурацией worker node.
Во-вторых, желательно, чтобы внутренняя адресация кластера (Cluster Network и Service Network) не пресекалась с вашей внутренней адресацией. Иначе есть вероятность, что POD внутри кластера не сможет открыть соединение с внешними ресурсами (например, сходить во внешнюю БД).
В-третьих, имя кластера (поле metadata) должно совпадать с вашим доменом для этого кластера. В нашем случае имя кластера ocp45, и его адреса находятся в домене ocp45.demo.local.
Можно подготовить install-config.yaml и через программу установки openshift-install, но тогда не получится определить конфигурацию worker node и внутреннюю адресацию. В любом случае есть смысл создать install-config.yaml через программу установки, а затем поправить его.
Сама процедура установки кластера принципиально не изменилась. После запуска программы инсталляции:
Процесс установки кластера.
Запускаем установку кластера и ждем. Обычно процесс установки занимает 30-40 минут:
Если соединение с Internet небыстрое, то установка может не пройти: инсталлятор не дождется загрузки RHCOS image. Вы можете заранее загрузить RHCOS image по ссылке, которую показывает инсталлятор. Полученный файл надо положить в директорию ~/.cache/openshift-installer/image_cache c именем 5dad1f50634794b0e1ff8a830cad4b98 и перезапустить инсталляцию. На этот раз openshift-install возьмет его с файловой системы:
Всё, кластер готов:
Плюсы нового способа не только в том, что установка теперь проще и требует меньше усилий на подготовку. Кластер OpenShift, установленный в vSphere через IPI, воспринимает vShpere как полноценную Cloud Platform и может пользоваться ее преимуществами — «эластичностью».
Теперь у кластера на платформе vSphere (как у больших облачных платформ типа Amazon AWS или Google GCP) есть machineset, автоматически создаваемый программой установки:
Это позволяет свести масштабирование кластера к запуску одной команды. OpenShift самостоятельно создаст узел и введет его в кластер или удалит его.
Способность кластера самостоятельно создавать и удалять узлы можно использовать для настройки автоматического масштабирования кластера OpenShfit.
В общем с vSphere IPI Installation все управление платформой оркестрации контейнерами OpenShift переходит на сторону kubernetes:
Это хорошо укладывается в заявленный RedHat подход Zero Administration для нижележащей под кластером инфраструктуры.
Кроме автоматизации создания кластеров, новая программа установки умеет их самостоятельно удалять. «Под капотом» у инсталлятора Terraform и в директории с конфигурационными файлами инсталляции остается файл состояния Terraform (terraform.tfstate). Это позволяет удалить ранее созданный кластер, не боясь случайно «задеть» чужие ресурсы:
Если вы постоянно создаете и удаляете кластеры, например, для тестов или учебных окружений, то эта возможность помогает также автоматизировать этот процесс и предотвратить возможные человеческие ошибки в этом процессе.
Установка OpenShift на платформе VMware vSphere — это самый распространенный вариант инсталляции. И умение OpenShift работать с vSphere как с облачной платформой, появившееся в релизе 4.5.1, значительно упрощает его администрирование, предоставляя готовое решение по автоматизации процессов жизненного цикла от создания платформы, ее масштабирования и удаления.
Теперь подход Infrastructure as Code для обслуживания on-premise решений на базе Red Hat OpenShift и VMware vSphere становится гораздо более доступным для воплощения в жизнь.
Автор: Сергей Артемов, архитектор отдела DevOps-решений «Инфосистемы Джет»
P.S. Присоединяйтесь к сообществу в Telegram DevSecOps Talks.
До релиза OpenShift 4.5.1 инсталлировать кластер на платформе vSphere было возможно только в варианте UPI (User Provider Infrastructure). Пользователь должен был самостоятельно подготовить необходимую для установки инфраструктуру, а именно подготовить:
- внешние сетевые балансировщики (один для балансировки трафика кластера, другой — для балансировки трафика приложений);
- ряд записей DNS, включая SRV record;
- сервер DHCP для выдачи адресов узлам кластера (ну или определиться со способом установки статической адресации);
- сервер HTTP для передачи ingnition config при установке RHCOS.
При этом любая ошибка (а как известно — «errare humanum est») в подготовке окружения приводит к неудаче с инсталляцией кластера. Чтобы как-то облегчить эту задачу, стали появляться сторонние проекты для ускорения подготовки окружения и уменьшения в этом процессе влияния «человеческого фактора». Один из самых известных — проект OCP Helper Node, который на одном сервере через Ansible готовит всю необходимую конфигурацию для установки OpenShift. Еще были варианты установки кластера с подготовкой инфраструктуры через Terraform.
Но подобные проекты не решали всех проблем с разворачиванием кластера в vSphere. Часто нужно предоставить кластер OpenShift как услугу («kubernetes as service»), и в этом случае автоматизация установки OpenShift оставалась непростым делом — требовалось ручное вмешательство: соблюдение очередности установки ОС на узлах кластера, подтверждение сертификатов в кластере, ожидание завершения установки cluster operators, и т.д. При необходимости можно автоматизировать и этот процесс, но для этого тоже нужны время и ресурсы, чтобы создать и поддерживать подобные решения.
Начиная с релиза 4.5.1., выпущенного 13 июля 2020 года, OpenShift поддерживает установку в vSphere в варианте IPI (Installer Provided Infrastructure). Это значит, что программа инсталляции теперь умеет:
- самостоятельно подготовить все необходимые ресурсы в vSphere;
- одной командой создать кластер OpenShift;
- одной командой удалить ранее созданный кластер OpenShift.
Кроме этого, после подобной инсталляции администратор одной командой в OpenShift может добавлять или удалять узлы кластера. Или вообще включить autoscaling, предоставив кластеру возможность самостоятельно реагировать на изменения нагрузки.
Но у нового способа инсталляции есть одно ограничение — все узлы кластера, а также сервер, с которого производится инсталляцию, должны иметь прямой доступ в Internet. Если администратор находится за корпоративным proxy-сервером или Internet для кластера недоступен — устанавливать кластер придется как раньше, в варианте UPI.
Подготовка окружающей инфраструктуры
Совсем без подготовки инфраструктуры при установке OpenShift не обойтись, но список задач стал скромнее:
- Нужен DHCP сервер (для выдачи адресов узлам OpenShift);
- Потребуются две записи в DNS (VIP для кластерного API и VIP для Ingress трафика);
- Понадобится учетная запись в vSphere c набором привилегий, описанных в документации по установке OpenShift.
В нашем случае для установки OpenShift и запуска всех требуемых сервисов использовался сервер shift-is01 под управление CentOS 7.
Конфигурация DHCPD
Здесь ничего специфичного, выделяем пул адресов (192.168.111.100 -192.168.111.150) под серверы OpenShift:
[ocp@shift-is01 ~]$ sudo cat /etc/dhcp/dhcpd.conf authoritative; ddns-update-style interim; default-lease-time 14400; max-lease-time 14400; option routers 192.168.111.1; option broadcast-address 192.168.111.255; option subnet-mask 255.255.255.0; option domain-name-servers 192.168.111.10; option domain-name «ocp45.demo.local»; subnet 192.168.111.0 netmask 255.255.255.0 { interface ens192; pool { range 192.168.111.100 192.168.111.150; # this is PXE specific filename «pxelinux.0»; next-server 192.168.111.10; } }
Конфигурация DNS
Для нашего кластера создана зона ocp45.demo.local и созданы A и PTR записи для диапазона DHCP. Создаем требуемые OpenShift записи для API и Ingress:
Кусок из BIND zone ocp45.demo.local:
api IN A 192.168.111.190 *.apps IN A 192.168.111.191
После этого загружаем сертификаты с нашего vCenter и устанавливаем их как доверенные на наш сервер.
Устанавливаем сертификаты vCenter:
[ocp@shift-is01 ~]$ mkdir certs; cd certs; curl -kO https://vc01.demo.local/certs/download.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5795 100 5795 0 0 15500 0 --:--:-- --:--:-- --:--:-- 15536 [ocp@shift-is01 certs]$ unzip ./download.zip Archive: ./download.zip inflating: certs/lin/e01a85a3.r1 inflating: certs/mac/e01a85a3.r1 inflating: certs/win/e01a85a3.r1.crl inflating: certs/lin/e01a85a3.0 inflating: certs/mac/e01a85a3.0 inflating: certs/win/e01a85a3.0.crt [ocp@shift-is01 certs]$ sudo cp ./certs/lin/e01a85a3.* /etc/pki/ca-trust/source/anchors [ocp@shift-is01 certs]$ sudo update-ca-trust extract
Установка кластера OpenShift
Сама процедура установки теперь максимально упрощена:
- получаем программу установки и ключи (Pull Secret) с сайта Red Hat;
- готовим yaml файл с install-config.yaml с планируемой конфигурацией кластера;
- устанавливаем кластер.
Получаем программу установки и ключи
Загружаем программу инсталляции и PullSecret c RedHat, эта процедура описана в Installation Guide. В нашем примере все необходимые для работы бинарные файлы расположены в директории bin домашней директории пользователя ocp.
[ocp@shift-is01 bin]$ ll total 499036 -rwxr-xr-x 1 ocp ocp 78599208 Jul 16 11:53 kubectl -rwxr-xr-x 1 ocp ocp 78599208 Jul 16 11:53 oc -rwxr-xr-x 1 ocp ocp 353804288 Jul 16 11:53 openshift-install -rw-r--r-- 1 ocp ocp 954 Jul 16 11:53 README.md
Готовим install-config.yaml
[ocp@shift-is01 ~]$ cat ./install-config.yaml apiVersion: v1 baseDomain: demo.local compute: - hyperthreading: Enabled architecture: amd64 name: worker replicas: 3 platform: vsphere: cpus: 2 coresPerSocket: 1 memoryMB: 8192 osDisk: diskSizeGB: 120 controlPlane: hyperthreading: Enabled architecture: amd64 name: master replicas: 3 platform: vsphere: cpus: 4 coresPerSocket: 1 memoryMB: 16384 osDisk: diskSizeGB: 120 metadata: name: ocp45 networking: networkType: OpenShiftSDN clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 platform: vsphere: vcenter: ваш_vCenter username: ваш_пользователь_vCenter password: ваш_пароль datacenter: ваш_Datacenter defaultDatastore: ваше_Datastre network: ваш_Network cluster: ваш_Cluster apiVIP: 192.168.111.190 ingressVIP: 192.168.111.191 fips: false pullSecret: 'ваш_PullSecret' sshKey: 'ваш_SSH_Public_Key'
При подготовке этого файла с будущей конфигурацией кластера следует обратить внимание на три нюанса.
Во-первых, кластер запомнит конфигурацию рабочих узлов кластера (worker node), определенных в install-config. И все последующие узлы, которые вы будете создавать при масштабировании кластера, окажутся ровно такой же конфигурации. Поэтому необходимо сразу определится с оптимальной конфигурацией worker node.
Во-вторых, желательно, чтобы внутренняя адресация кластера (Cluster Network и Service Network) не пресекалась с вашей внутренней адресацией. Иначе есть вероятность, что POD внутри кластера не сможет открыть соединение с внешними ресурсами (например, сходить во внешнюю БД).
В-третьих, имя кластера (поле metadata) должно совпадать с вашим доменом для этого кластера. В нашем случае имя кластера ocp45, и его адреса находятся в домене ocp45.demo.local.
Можно подготовить install-config.yaml и через программу установки openshift-install, но тогда не получится определить конфигурацию worker node и внутреннюю адресацию. В любом случае есть смысл создать install-config.yaml через программу установки, а затем поправить его.
Устанавливаем кластер
Сама процедура установки кластера принципиально не изменилась. После запуска программы инсталляции:
- инсталлятор создает bootstrap node с ресурсами для инициализации master node;
- инсталлятор создает три master node;
- bootstrap node и три master node формируют cluster control plane;
- инсталлятор выключает и удаляет bootstrap node;
- control plane разворачивает worker nodes и настраивает необходим��е кластерные службы.
Процесс установки кластера.
Запускаем установку кластера и ждем. Обычно процесс установки занимает 30-40 минут:
Установка кластера
[ocp@shift-is01 ~]$ mkdir ocp45; cp ./install-config.yaml ./ocp45 [ocp@shift-is01 ~]$ ./bin/openshift-install create cluster --dir=ocp45 --log-level=info INFO Consuming Install Config from target directory INFO Obtaining RHCOS image file from 'https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.5/45.82.202007062333-0/x86_64/rhcos-45.82.202007062333-0-vmware.x86_64.ova?sha256=4189881eadb0b0cfd85c2f2ab1c32f6a320b71713cac3bd4179dba746ad4070a' INFO Creating infrastructure resources... INFO Waiting up to 20m0s for the Kubernetes API at https://api.ocp45.demo.local:6443... INFO API v1.18.3+8b0a82f up INFO Waiting up to 40m0s for bootstrapping to complete... INFO Destroying the bootstrap resources... INFO Waiting up to 30m0s for the cluster at https://api.ocp45.demo.local:6443 to initialize... INFO Waiting up to 10m0s for the openshift-console route to be created... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/ocp/ocp45/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.ocp45.demo.local INFO Login to the console with user: «kubeadmin», and password: «xxxxxxxxxxxxxxx» INFO Time elapsed: 41m56s
Проблемы с загрузкой RHCOS
Если соединение с Internet небыстрое, то установка может не пройти: инсталлятор не дождется загрузки RHCOS image. Вы можете заранее загрузить RHCOS image по ссылке, которую показывает инсталлятор. Полученный файл надо положить в директорию ~/.cache/openshift-installer/image_cache c именем 5dad1f50634794b0e1ff8a830cad4b98 и перезапустить инсталляцию. На этот раз openshift-install возьмет его с файловой системы:
INFO The file was found in cache: /home/ocp/.cache/openshift-installer/image_cache/5dad1f50634794b0e1ff8a830cad4b98. Reusing...Всё, кластер готов:
[ocp@shift-is01 ~]$ export KUBECONFIG=/home/ocp/ocp45/auth/kubeconfig [ocp@shift-is01 ~]$ ./bin/oc get nodes NAME STATUS ROLES AGE VERSION ocp45-64clc-master-0 Ready master 33m v1.18.3+6025c28 ocp45-64clc-master-1 Ready master 33m v1.18.3+6025c28 ocp45-64clc-master-2 Ready master 33m v1.18.3+6025c28 ocp45-64clc-worker-f7bw2 Ready worker 15m v1.18.3+6025c28 ocp45-64clc-worker-m277w Ready worker 15m v1.18.3+6025c28 ocp45-64clc-worker-wcjj7 Ready worker 15m v1.18.3+6025c28
Масштабирование и удаление кластера OpenShift
Плюсы нового способа не только в том, что установка теперь проще и требует меньше усилий на подготовку. Кластер OpenShift, установленный в vSphere через IPI, воспринимает vShpere как полноценную Cloud Platform и может пользоваться ее преимуществами — «эластичностью».
Теперь у кластера на платформе vSphere (как у больших облачных платформ типа Amazon AWS или Google GCP) есть machineset, автоматически создаваемый программой установки:
OpenShift machineset [ocp@shift-is01 ~]$ ./bin/oc get machinesets -n openshift-machine-api NAME DESIRED CURRENT READY AVAILABLE AGE ocp45-64clc-worker 3 3 3 3 50m
Это позволяет свести масштабирование кластера к запуску одной команды. OpenShift самостоятельно создаст узел и введет его в кластер или удалит его.
Добавление узла в кластер
[ocp@shift-is01 ~]$ ./bin/oc scale --replicas=4 machineset ocp45-64clc-worker -n openshift-machine-api machineset.machine.openshift.io/ocp45-64clc-worker scaled [ocp@shift-is01 ~]$ ./bin/oc get machinesets -n openshift-machine-api NAME DESIRED CURRENT READY AVAILABLE AGE ocp45-64clc-worker 4 4 3 3 61m [ocp@shift-is01 ~]$ ./bin/oc get nodes NAME STATUS ROLES AGE VERSION ocp45-64clc-master-0 Ready master 75m v1.18.3+6025c28 ocp45-64clc-master-1 Ready master 75m v1.18.3+6025c28 ocp45-64clc-master-2 Ready master 75m v1.18.3+6025c28 ocp45-64clc-worker-f7bw2 Ready worker 57m v1.18.3+6025c28 ocp45-64clc-worker-hvjmn Ready worker 9m27s v1.18.3+6025c28 ocp45-64clc-worker-m277w Ready worker 57m v1.18.3+6025c28 ocp45-64clc-worker-wcjj7 Ready worker 57m v1.18.3+6025c28
Удаление узла из кластера
[ocp@shift-is01 ~]$ ./bin/oc scale --replicas=3 machineset ocp45-64clc-worker -n openshift-machine-api machineset.machine.openshift.io/ocp45-64clc-worker scaled [ocp@shift-is01 ~]$ ./bin/oc get nodes NAME STATUS ROLES AGE VERSION ocp45-64clc-master-0 Ready master 97m v1.18.3+6025c28 ocp45-64clc-master-1 Ready master 98m v1.18.3+6025c28 ocp45-64clc-master-2 Ready master 98m v1.18.3+6025c28 ocp45-64clc-worker-hvjmn Ready worker 32m v1.18.3+6025c28 ocp45-64clc-worker-m277w Ready worker 79m v1.18.3+6025c28 ocp45-64clc-worker-wcjj7 Ready worker 79m v1.18.3+6025c28
Способность кластера самостоятельно создавать и удалять узлы можно использовать для настройки автоматического масштабирования кластера OpenShfit.
В общем с vSphere IPI Installation все управление платформой оркестрации контейнерами OpenShift переходит на сторону kubernetes:
- созданием и удалением ресурсов для кластера управляет администратор OpenShift через machineset;
- конфигурацией настроек ОС на узлах кластера также управляет администратор OpenShift через macheneconfig.
Это хорошо укладывается в заявленный RedHat подход Zero Administration для нижележащей под кластером инфраструктуры.
Кроме автоматизации создания кластеров, новая программа установки умеет их самостоятельно удалять. «Под капотом» у инсталлятора Terraform и в директории с конфигурационными файлами инсталляции остается файл состояния Terraform (terraform.tfstate). Это позволяет удалить ранее созданный кластер, не боясь случайно «задеть» чужие ресурсы:
[ocp@shift-is01 ~]$./bin/openshift-install destroy cluster --dir=ocp45 --log-level=info
Если вы постоянно создаете и удаляете кластеры, например, для тестов или учебных окружений, то эта возможность помогает также автоматизировать этот процесс и предотвратить возможные человеческие ошибки в этом процессе.
Заключение
Установка OpenShift на платформе VMware vSphere — это самый распространенный вариант инсталляции. И умение OpenShift работать с vSphere как с облачной платформой, появившееся в релизе 4.5.1, значительно упрощает его администрирование, предоставляя готовое решение по автоматизации процессов жизненного цикла от создания платформы, ее масштабирования и удаления.
Теперь подход Infrastructure as Code для обслуживания on-premise решений на базе Red Hat OpenShift и VMware vSphere становится гораздо более доступным для воплощения в жизнь.
Автор: Сергей Артемов, архитектор отдела DevOps-решений «Инфосистемы Джет»
P.S. Присоединяйтесь к сообществу в Telegram DevSecOps Talks.