Как стать автором
Обновить
710.84
Рейтинг
Инфосистемы Джет
российская ИТ-компания

OpenShift 4.5.1: установка в vSphere IPI

Блог компании Инфосистемы Джет IT-инфраструктура *Openshift *
Если вы раньше имели дело с OpenShift, то знаете насколько трудоемко установить «с нуля» кластер OpenShift в vSphere. В основном потому, что нужно подготовить окружающую инфраструктуру. В релизе OpenShift 4.5.1 эта задача стала намного легче.



До релиза 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 не обойтись, но список задач стал скромнее:

  1. Нужен DHCP сервер (для выдачи адресов узлам OpenShift);
  2. Потребуются две записи в DNS (VIP для кластерного API и VIP для Ingress трафика);
  3. Понадобится учетная запись в 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


Сама процедура установки теперь максимально упрощена:

  1. получаем программу установки и ключи (Pull Secret) с сайта Red Hat;
  2. готовим yaml файл с install-config.yaml с планируемой конфигурацией кластера;
  3. устанавливаем кластер.

Получаем программу установки и ключи


Загружаем программу инсталляции и 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:

  1. созданием и удалением ресурсов для кластера управляет администратор OpenShift через machineset;
  2. конфигурацией настроек ОС на узлах кластера также управляет администратор 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.
Теги:
Хабы:
Всего голосов 9: ↑9 и ↓0 +9
Просмотры 4.9K
Комментарии 3
Комментарии Комментарии 3

Публикации

Информация

Сайт
jet.su
Дата регистрации
Дата основания
1991
Численность
1 001–5 000 человек
Местоположение
Россия