Если вы раньше имели дело с 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.