Онлайн
Alvaros
.
- Регистрация
- 14.05.16
- Сообщения
- 21.452
- Реакции
- 101
- Репутация
- 204
Если вы раньше имели дело с OpenShift, то знаете насколько трудоемко установить «с нуля» кластер OpenShift в vSphere. В основном потому, что нужно подготовить окружающую инфраструктуру. В релизе OpenShfit 4.5.1 эта задача стала намного легче.
До релиза OpenShfit 4.5.1 инсталлировать кластер на платформе vSphere было возможно только в варианте UPI (User Provider Infrastructure). Пользователь должен был самостоятельно подготовить необходимую для установки инфраструктуру, а именно подготовить:
При этом любая ошибка (а как известно — «errare humanum est») в подготовке окружения приводит к неудаче с инсталляцией кластера. Чтобы как-то облегчить эту задачу, стали появляться сторонние проекты для ускорения подготовки окружения и уменьшения в этом процессе влияния «человеческого фактора». Один из самых известных — проект
Но подобные проекты не решали всех проблем с разворачиванием кластера в vSphere. Часто нужно предоставить кластер OpenShift как услугу («kubernetes as service»), и в этом случае автоматизация установки OpenShift оставалась непростым делом — требовалось ручное вмешательство: соблюдение очередности установки ОС на узлах кластера, подтверждение сертификатов в кластере, ожидание завершения установки cluster operators, и т.д. При необходимости можно автоматизировать и этот процесс, но для этого тоже нужны время и ресурсы, чтобы создать и поддерживать подобные решения.
Начиная с релиза
Кроме этого, после подобной инсталляции администратор одной командой в OpenShift может добавлять или удалять узлы кластера. Или вообще включить autoscaling, предоставив кластеру возможность самостоятельно реагировать на изменения нагрузки.
Но у нового способа инсталляции есть одно ограничение — все узлы кластера, а также сервер, с которого производится инсталляцию, должны иметь прямой доступ в Internet. Если администратор находится за корпоративным proxy-сервером или Internet для кластера недоступен — устанавливать кластер придется как раньше, в варианте UPI.
Подготовка окружающей инфраструктуры
Совсем без подготовки инфраструктуры при установке 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
% 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
Сама процедура установки теперь максимально упрощена:
Получаем программу установки и ключи
Загружаем программу инсталляции и PullSecret c RedHat, эта процедура описана в
[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 через программу установки, а затем поправить его.
Устанавливаем кластер
Сама процедура установки кластера принципиально не изменилась. После запуска программы инсталляции:
Процесс установки кластера.
Запускаем установку кластера и ждем. Обычно процесс установки занимает 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 '
INFO Creating infrastructure resources...
INFO Waiting up to 20m0s for the Kubernetes API at
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
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:
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) есть
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
Способность кластера самостоятельно создавать и удалять узлы можно использовать для настройки
В общем с vSphere IPI Installation все управление платформой оркестрации контейнерами OpenShfit переходит на сторону kubernetes:
Это хорошо укладывается в заявленный 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 становится гораздо более доступным для воплощения в жизнь.
Автор: Сергей Артемов, архитектор отдела
До релиза OpenShfit 4.5.1 инсталлировать кластер на платформе vSphere было возможно только в варианте UPI (User Provider Infrastructure). Пользователь должен был самостоятельно подготовить необходимую для установки инфраструктуру, а именно подготовить:
- внешние сетевые балансировщики (один для балансировки трафика кластера, другой — для балансировки трафика приложений);
- ряд записей DNS, включая SRV record;
- сервер DHCP для выдачи адресов узлам кластера (ну или определиться со способом установки статической адресации);
- сервер HTTP для передачи ingnition config при установке RHCOS.
При этом любая ошибка (а как известно — «errare humanum est») в подготовке окружения приводит к неудаче с инсталляцией кластера. Чтобы как-то облегчить эту задачу, стали появляться сторонние проекты для ускорения подготовки окружения и уменьшения в этом процессе влияния «человеческого фактора». Один из самых известных — проект
You must be registered for see links
, который на одном сервере через Ansible готовит всю необходимую конфигурацию для установки OpenShift. Еще были варианты установки кластера с подготовкой инфраструктуры через Terraform.Но подобные проекты не решали всех проблем с разворачиванием кластера в vSphere. Часто нужно предоставить кластер OpenShift как услугу («kubernetes as service»), и в этом случае автоматизация установки OpenShift оставалась непростым делом — требовалось ручное вмешательство: соблюдение очередности установки ОС на узлах кластера, подтверждение сертификатов в кластере, ожидание завершения установки cluster operators, и т.д. При необходимости можно автоматизировать и этот процесс, но для этого тоже нужны время и ресурсы, чтобы создать и поддерживать подобные решения.
Начиная с релиза
You must be registered for see links
, выпущенного 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 набором привилегий, описанных в документации
You must be registered for see links.
В нашем случае для установки 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
You must be registered for see links
% 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) с сайта
You must be registered for see links;
- готовим yaml файл с install-config.yaml с планируемой конфигурацией кластера;
- устанавливаем кластер.
Получаем программу установки и ключи
Загружаем программу инсталляции и PullSecret c RedHat, эта процедура описана в
You must be registered for see links
. В нашем примере все необходимые для работы бинарные файлы расположены в директории 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 '
You must be registered for see links
'INFO Creating infrastructure resources...
INFO Waiting up to 20m0s for the Kubernetes API at
You must be registered for see links
...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
You must be registered for see links
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:
You must be registered for see links
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) есть
You must be registered for see links
, автоматически создаваемый программой установки: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
Способность кластера самостоятельно создавать и удалять узлы можно использовать для настройки
You must be registered for see links
.В общем с vSphere IPI Installation все управление платформой оркестрации контейнерами OpenShfit переходит на сторону 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 становится гораздо более доступным для воплощения в жизнь.
Автор: Сергей Артемов, архитектор отдела
You must be registered for see links
«Инфосистемы Джет»