Подготовка окружения#

Используйте дистрибутив DropApp Plus, полученный от производителя продукта.

Подготовка элементов развертывания#

После получения архива с образами и бинарными файлами необходимо распаковать его и переложить образы в свой локальный репозиторий образов.

Для загрузки образов в локальный репозиторий требуется утилита skopeo. Skopeo позволяет сохранить sha256 оригинальных образов.

Установите skopeo:
```
sudo dnf install -y skopeo
```
Распакуйте полученный архив, в нем содержится две директории binaries (она содержит oc и dropappplus-install) и images, а также инструкцию по обновлению с актуальным sha256 релизного образа и инструкцию по установке:
```
drwxr-xr-x 2 binaries
-rw-r--r-- 1 cluster_upgrade_instructions.pdf
drwxr-xr-x 2 images
```
С помощью skopeo синхронизируйте каталог с локальным репозиторием (в примере здесь и ниже это registry.example.aa.ааа без аутентификации):
```
skopeo sync --preserve-digests --src dir --dest docker ./4.8.57-dropappplus-2.0.3-x86_64/images registry.example.aa.bbb # для версии dplus-release
```
Примечание

Репозиторий должен быть доверенным. Если нет, то сгенерируйте сертификат и добавьте его на nodes кластера

Настройка окружения#

Подготовка сервера администратора#

На первом шаге необходимо подготовить сервер администратора.

DropApp Plus настраивается администратором на виртуальной node с ОС (см. официальную документацию к продуктам, указанным в разделе «Системные требования» текущего документа).

Получить утилиты dropappplus-install и oc из дистрибутива поставки DropApp Plus.

dropappplus-install - используется для подготовки манифест файлов и ignition файлов для установки серверов bootstrap, master, worker. CLI утилита oc используется для управления кластером.

Для подготовки сервера администратора выполните следующую последовательность действий.

Задайте переменную окружения с релизным образом Dropapp 2.0.3 который указывает на релизный образ из локального registry, пример:
```
export OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE="registry.com/dapp-release:4.8.57-dropappplus-2.0.3-x86_64-release"
```

Проверьте версию dropappplus-install:

dropappplus-install version

Вывод будет следующим:

dropappplus-install 4.8.57-dropappplus-2.0.3
built from commit <хеш коммита>
release image <путь репозитория>/dropappplus/2.0.3/dplus-release@sha256:<хеш образа>

Подготовьте файл install-config.yaml для создания ignition файлов установки кластера, например:

apiVersion: v1
baseDomain: dplus.example # Имя домена, в котором будет развернут кластер
compute:
- hyperthreading: Disabled  #  Disabled, если установка происходит на виртуальные nodes, иначе - Enabled
  name: worker
  replicas: 2 # Количество worker nodes
controlPlane:
  hyperthreading: Disabled  # Disabled, если установка происходит на виртуальные nodes, иначе - Enabled
  name: master
  replicas: 3
metadata:
  name: test # Имя кластера
networking:
  clusterNetwork:
  - cidr: NN.NNN.N.N/14 # Актуальный IP адрес
    hostPrefix: 23
  networkType: OpenShiftSDN
  serviceNetwork:
  - NNN.NN.N.NN/16 # Актуальный IP адрес
platform:
  none: {}
fips: false
pullSecret: '' # Данные для авторизации в registry, где хранятся образы из поставки DropApp Plus 2.0.3
sshKey: ''

Добавьте путь для mirror аналогично последовательности, указанной в разделе обновление кластера -> Mirroring с помощью ImageContentSourcePolicy.
Создайте пустой каталог:
```
mkdir ~/config
```
Скопируйте install-config.yaml в config:
```
cp ~/install-config.yaml ~/config
```
Подготовьте файлы ignition:
```
dropappplus-install create manifests --dir ~/config
dropappplus-install create ignition-configs --dir ~/config
```
На данном шаге формируются ignition-файлы для установки кластера и kubeconfig для работы с кластером DropApp Plus.

Выведите список ignition-файлов для установки кластера:

ls -laR ~/config/*.ign

Вывод будет следующим:

-rw-r-----. 1 <Name> users 269173 Dec 19 12:28 /home/<Name>/config/bootstrap.ign
-rw-r-----. 1 <Name> users   1716 Dec 19 12:28 /home/<Name>/config/master.ign
-rw-r-----. 1 <Name> users   1716 Dec 19 12:28 /home/<Name>/config/worker.ign

Выведите список ignition-файлов для установки kubeconfig:

ls -laR ~/config/auth

Вывод будет следующим:

/home/<Name>/config/auth:
total 24
drwxr-x---. 2 <Name> users 4096 Dec 19 12:28 .
drwxr-xr-x. 3 <Name> users 4096 Dec 19 12:28 ..
-rw-r-----. 1 <Name> users   23 Dec 19 12:28 kubeadmin-password
-rw-r-----. 1 <Name> users 8940 Dec 19 12:28 kubeconfig

Настройка вспомогательного сервера#

Для установки кластера вручную возможны два варианта для установки ОС на nodes кластера. Установка из ISO-образа и загрузка PXE и установка по сети. Далее описан вариант с установкой из ISO образа.

Вспомогательный сервер нужен для работы служб DHCP, Docker-Registry и веб-сервера.

DHCP-сервер должен выдавать фиксированные IP-адреса для nodes кластера. Необходимо настроить резервацию. Далее прописать полученные адреса для настройки DNS-зоны.

DNS-сервер должен обслуживать запросы в зоне, имя которой формируется из значений, заданных в файле install-config.yaml, например, с01.example.ab.abc.

Для установки кластера необходимо подготовить балансировщик, в примерах используется HAProxy.

В этом разделе представлены примеры конфигурации записей A и PTR, которые соответствуют требованиям DNS для развертывания контейнерной платформы DropApp Plus в инфраструктуре пользователя. Примеры не предназначены для выбора одного решения DNS по сравнению с другим.

В примерах имя кластера — ocp4 и базовый домен — example.com.

Вспомогательный сервер используется для раздачи ignition-файлов на nodes кластера в процессе установки. На веб-сервере необходимо разместить файлы bootstrap.ign, master.ign и worker.ign. Записать контрольные суммы файлов в формате sha512. Контрольные суммы используются при установке nodes кластера.

Пример настройки DNS-зоны#

В следующем примере показан файл зоны BIND, в котором отображены образцы записей A для разрешения имен в кластере:

Пример базы данных зоны DNS

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	NNN.NNN.N.5
smtp.example.com.		IN	A	NNN.NNN.N.5
;
helper.example.com.		IN	A	NNN.NNN.N.5
helper.ocp4.example.com.	IN	A	NNN.NNN.N.5
;
api.ocp4.example.com.		IN	A	NNN.NNN.N.5 # Обеспечивает разрешение имен для Kubernetes API. Запись относится к IP-адресу балансировщика нагрузки API.
api-int.ocp4.example.com.	IN	A	NNN.NNN.N.5 # Обеспечивает разрешение имен для Kubernetes API. Запись относится к IP-адресу балансировщика нагрузки API и используется для внутренней связи кластера.
;
*.apps.ocp4.example.com.	IN	A	NNN.NNN.N.5 # Обеспечивает разрешение имен для маршрутов с подстановочными знаками. Запись относится к IP-адресу балансировщика нагрузки приложения. Балансировщик нагрузки приложения предназначен для nodes, на которых работают модули Ingress Controller. Модули Ingress Controller по умолчанию запускаются на worker nodes.
;
bootstrap.ocp4.example.com.	IN	A	NNN.NNN.N.96 # Обеспечивает разрешение имен для bootstrap сервера.
;
master0.ocp4.example.com.	IN	A	NNN.NNN.N.97 # Обеспечивает разрешение имен для master nodes.
master1.ocp4.example.com.	IN	A	NNN.NNN.N.98 # Обеспечивает разрешение имен для master nodes.
master2.ocp4.example.com.	IN	A	NNN.NNN.N.99 # Обеспечивает разрешение имен для master nodes.
;
worker0.ocp4.example.com.	IN	A	NNN.NNN.N.11 # Обеспечивает разрешение имен для worker nodes.
worker1.ocp4.example.com.	IN	A	NNN.NNN.N.7 # Обеспечивает разрешение имен для worker nodes.
;
;EOF

где NNN.NNN.N.{x} – IP адреса выбранной подсети.

Примечание

В этом примере один и тот же балансировщик нагрузки используется для API Kubernetes и входящего трафика приложения. В производственных сценариях необходимо развернуть API и балансировщики входной нагрузки приложений отдельно, чтобы можно было масштабировать инфраструктуру балансировщиков нагрузки для каждого из них в отдельности.

Пример настройки обратной PTR DNS#

В следующем примере файла зоны BIND показаны примеры записей PTR для обратного разрешения имен в кластере:

Пример базы данных зоны DNS для обратных записей

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.N.NNN.NNN.in-addr.arpa.	IN	PTR	api.ocp4.example.com. # Обеспечивает обратное разрешение DNS для API Kubernetes. Запись PTR относится к имени записи балансировщика нагрузки API.
5.N.NNN.NNN.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. # Обеспечивает обратное разрешение DNS для API Kubernetes. Запись PTR относится к имени записи балансировщика нагрузки API и используется для внутренней связи кластера.
;
96.N.NNN.NNN.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. # Обеспечивает обратное разрешение DNS для bootstrap сервера.
;
97.N.NNN.NNN.in-addr.arpa.	IN	PTR	master0.ocp4.example.com. # Обеспечивает обратное разрешение DNS для master nodes.
98.N.NNN.NNN.in-addr.arpa.	IN	PTR	master1.ocp4.example.com. # Обеспечивает обратное разрешение DNS для master nodes.
99.N.NNN.NNN.in-addr.arpa.	IN	PTR	master2.ocp4.example.com. # Обеспечивает обратное разрешение DNS для master nodes.
;
11.N.NNN.NNN.in-addr.arpa.	IN	PTR	worker0.ocp4.example.com. # Обеспечивает обратное разрешение DNS для worker nodes.
7.N.NNN.NNN.in-addr.arpa.	IN	PTR	worker1.ocp4.example.com. # Обеспечивает обратное разрешение DNS для worker nodes.
;
;EOF

где {x}.N.NNN.NNN – обратные IP адреса выбранной подсети.

Выпуск и подготовка сертификатов#

Предварительные выпуск и подготовка сертификатов не требуются. В процессе развертывания кластера DropApp генерируется токен для связи рабочих узлов с мастер-узлом.

Решение о выпуске дополнительных сертификатов принимает администратор безопасности конечной АС, использующей продукт.