Розгортання Платформи з нуля у приватному хмарному середовищі vSphere

ЗМІСТ
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.
Будь ласка, зверніться до вашого постачальника, щоб отримати необхідний vSphere-інсталятор.

1. Підготовка інфраструктури vSphere для встановлення OKD

OKD — це дистрибутив Kubernetes, оптимізований для неперервної розробки додатків та розгортання декількох екземплярів ізольованого контейнерного середовища (у нашому випадку — екземплярів реєстру). За детальною інформацією зверніться до офіційного джерела.

1.1. Налаштування довіреного інтерфейсу vCenter API

Інсталер вимагає доступу до довіреного інтерфейсу vCenter API, який надає можливість завантажити довірені кореневі сертифікати CA vCenter.

Перед підключенням до API, сертифікати vCenter root CA повинні бути додані до системи, з якої запускатиметься OKD-інсталер.

1.2. Завантаження CA-сертифікатів

Сертифікати можуть бути завантажені з домашньої сторінки vCenter.

За замовчуванням сертифікати зберігаються за посиланням <vCenter>/certs/download.zip. Після завантаження і розархівування буде створено директорію, що містить сертифікати для ОС Linux, macOS та Windows.

1.2.1. Приклад перегляду структури

Структуру директорій із розміщеними в ній сертифікатами можна переглянути за допомогою команди:

$ tree certs

В результаті буде зображено наступну структуру:

certs

├── lin

│   ├── 108f4d17.0

│   ├── 108f4d17.r1

│   ├── 7e757f6a.0

│   ├── 8e4f8471.0

│   └── 8e4f8471.r0

├── mac

│   ├── 108f4d17.0

│   ├── 108f4d17.r1

│   ├── 7e757f6a.0

│   ├── 8e4f8471.0

│   └── 8e4f8471.r0

└── win

    ├── 108f4d17.0.crt

    ├── 108f4d17.r1.crl

    ├── 7e757f6a.0.crt

    ├── 8e4f8471.0.crt

    └── 8e4f8471.r0.crl


3 directories, 15 files

1.2.2. Приклад додавання сертифікатів

Необхідно додати відповідні сертифікати для вашої операційної системи.

Приклад для ОС Fedora:

$ sudo cp certs/lin/* /etc/pki/ca-trust/source/anchors

$ sudo update-ca-trust extract

1.3. Ресурси стандартної інсталяції

Стандартна інсталяція (Installer-Provisioned Infrastructure) створює наступні ресурси інфраструктури:

  • одну папку (1 Folder)

  • одну тег-категорію (1 Tag Category)

  • 1 тег (1 Tag)

  • віртуальні машини (Virtual machines):

    • один шаблон (1 template)

    • одну тимчасову ноду bootstrap (1 temporary bootstrap node)

    • три ноди консолі для управління Платформою (3 control-plane nodes)

    • три обчислювальні машини (3 compute machines)

1.3.1. Необхідні вимоги до ресурсів

1.3.1.1. Сховище даних

Разом із ресурсами, описаними вище, стандартне розгортання OKD вимагає мінімум 800 Гб простору для сховища даних.

1.3.1.2. DHCP

Розгортання вимагає налаштування DHCP-сервера для конфігурації мережі.

2. Розгортання та налаштування DNS і DHCP-компонентів

2.1. IP-адреси

Розгортання інфраструктури vSphere (Іnstaller-provisioned vSphere) вимагає двох статичних IP-адрес:

  • Адреса програмного інтерфейсу (API) - використовується для доступу до API-кластера.

  • Вхідна IP-адреса (Ingress) - використовується для вхідного трафіку кластера.

Віртуальні ІР-адреси для кожного з них повинні бути визначені у файлі install-config.yaml.

2.2. DNS-записи

DNS-записи (DNS records) повинні бути створені для двох ІР-адрес на будь-якому DNS-сервері, призначеному для середовища. Записи повинні містити значення, описані в таблиці:

Назва Значення

api.${cluster-name}.${base-domain}

API VIP

*.apps.${cluster-name}.${base-domain}`

Ingress VIP
${cluster-name} та ${base-domain} - це змінні, що взято із відповідних значень, вказаних у файлі install-config.yaml.

3. Створення конфігураційного файлу install-config.yaml

Передумови

  1. Увійдіть у свій обліковий запис Red Hat. Якщо у вас немає облікового запису, вам потрібно створити його.

  2. Придбайте платну підписку на DockerHub, якщо у вас її немає.

  3. Згенеруйте та додайте ssh-ключ до вашого конфігураційного файлу. Це необхідно для доступу до консолей ваших нод.

Створення файлу install-config.yaml, необхідного для розгортання OKD кластеру, виконується наступною командою:

$ openshift-installer create install-config

Після створення файлу потрібно заповнити необхідні параметри, які будуть представлені в контекстному меню. Створений конфігураційний файл включає лише необхідні параметри для мінімального розгортання кластера. Для кастомізації налаштувань можна звернутись до офіційної документації.

Конфігурація install-config.yaml 
apiVersion: v1
baseDomain: eua.gov.ua
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: mdtuddm
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
platform:
  vsphere:
    apiVIP: 10.9.1.110
    cluster: HX-02
    datacenter: HXDP-02
    defaultDatastore: NCR_Data2
    ingressVIP: 10.9.1.111
    network: EPAM_OKD_Vlan9_EPG
    password: <password>
    username: epam_dev1@vsphere.local
    vCenter: vcsa.ncr.loc
publish: External
pullSecret: '{"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}'
sshKey: |
  <ssh_key>

  • Під час створення конфігураційного файлу замініть <password> на ваш пароль, а <ssh_key> — на ваш згенерований ssh-ключ.

  • Також скопіюйте параметри автентифікації з облікового запису Red Hat та підставте у поле pullSecret.

  • Зверніть увагу, що деякі параметри, можливо, доведеться змінити, щоб вони відповідали вашій інфраструктурі та потребам.

4. Запуск OKD4-інсталера та розгортання порожнього кластера OKD4

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

$ openshift-installer create cluster
Процес розгортання кластера зазвичай займає до 1,5 години часу.

При успішному розгортанні, в результаті виконання команди будуть представлені наступні параметри доступу до кластера:

  • логін;

  • пароль;

  • посилання на веб-консоль кластера.

В директорії, де виконувалася команда, буде створено ряд файлів, що зберігають статус кластера, необдхіний для його деінсталяції.

Також в цій директорії з’явиться папка /auth, в якій буде збережено два файли для автентифікації для роботи з кластером через веб-консоль та інтерфейс командного рядка OKD (OKD CLI).

Після запуску процесу розгортання кластера, Інсталер видаляє install-config.yaml, тому рекомендовано виконати резервування цього файлу, якщо є потреба розгортання кількох кластерів.

5. Заміна самопідписаних сертифікатів на довірені сертифікати

Для заміни самопідписаних (self-signed) сертифікатів на довірені (trusted) необхідно спочатку отримати ці сертифікати.

В цьому пункті розглянуто отримання безкоштовних сертифікатів Let’s Encrypt та їх встановлення на сервер.

Отримання сертифікатів Let’s Encrypt здійснено за допомогою утиліти acme.sh.

Для отримання розширених деталей щодо використання Let’s Encrypt на базі ACME-протоколу, зверніться до офіційного джерела.

5.1. Підготовка

Необхідно клонувати утиліту acme.sh із репозиторію GitHub:

$ cd $HOME
$ git clone https://github.com/neilpang/acme.sh
$ cd acme.sh

5.2. Запит на отримання сертифікатів

  1. Щоб полегшити процес отримання сертифікатів, необхідно задати дві змінні середовища. Перша змінна повинна вказувати на API Endpoint. Переконайтесь, що ви увійшли до OKD як system:admin і використовуєте CLI-консоль Openshift, щоб знайти API Endpoint URL.

    $ oc whoami --show-server
    Приклад отриманої відповіді
    https://api.e954.ocp4.opentlc.com:6443

  2. Тепер встановіть змінну LE_API для повністю визначеного доменного імені API:

    $ export LE_API=$(oc whoami --show-server | cut -f 2 -d ':' | cut -f 3 -d '/' | sed 's/-api././')

  3. Встановіть другу змінну LE_WILDCARD для вашого Wildcard Domain:

    $ export LE_WILDCARD=$(oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath='{.status.domain}')

  4. Запустіть скрипт acme.sh:

    $ ${HOME}/acme.sh/acme.sh --issue -d ${LE_API} -d *.${LE_WILDCARD} --dns
    Приклад отриманої відповіді
    $  ./acme.sh --issue -d  ${LE_API} -d \*.${LE_WILDCARD} --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
[Wed Jul 28 18:37:33 EEST 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Jul 28 18:37:33 EEST 2021] Creating domain key
[Wed Jul 28 18:37:33 EEST 2021] The domain key is here: $HOME/.acme.sh/api.e954.ocp4.opentlc.com/api.e954.ocp4.opentlc.com.key
[Wed Jul 28 18:37:33 EEST 2021] Multi domain='DNS:api.e954.ocp4.opentlc.com,DNS:*.apps.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:33 EEST 2021] Getting domain auth token for each domain
[Wed Jul 28 18:37:37 EEST 2021] Getting webroot for domain='cluster-e954-api.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:37 EEST 2021] Getting webroot for domain=‘*.apps.cluster-e954-api.e954.ocp4.opentlc.com’
[Wed Jul 28 18:37:38 EEST 2021] Add the following TXT record:
[Wed Jul 28 18:37:38 EEST 2021] Domain: '_acme-challenge.api.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:38 EEST 2021] TXT value: 'VZ2z3XUe4cdNLwYF7UplBj7ZTD8lO9Een0yTD7m_Bbo'
[Wed Jul 28 18:37:38 EEST 2021] Please be aware that you prepend _acme-challenge. before your domain
[Wed Jul 28 18:37:38 EEST 2021] so the resulting subdomain will be: _acme-challenge.api.e954.ocp4.opentlc.com
[Wed Jul 28 18:37:38 EEST 2021] Add the following TXT record:
[Wed Jul 28 18:37:38 EEST 2021] Domain: '_acme-challenge.apps.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:38 EEST 2021] TXT value: 'f4KeyXkpSissmiLbIIoDHm5BJ6tOBTA0D8DyK5sl46g'
[Wed Jul 28 18:37:38 EEST 2021] Please be aware that you prepend _acme-challenge. before your domain
[Wed Jul 28 18:37:38 EEST 2021] so the resulting subdomain will be: _acme-challenge.apps.e954.ocp4.opentlc.com
[Wed Jul 28 18:37:38 EEST 2021] Please add the TXT records to the domains, and re-run with --renew.
[Wed Jul 28 18:37:38 EEST 2021] Please add '--debug' or '--log' to check more details.
    DNS-записи з попередньої відповіді необхідно додати на DNS-сервері, що відповідає за зону e954.ocp4.opentlc.com (значення зони тут є прикладом). Таким чином, TXT-записи повинні мати наступний вигляд:
    TXT-запис 1
    _acme-challenge.api.e954.ocp4.opentlc.com TXT value: 'VZ2z3XUe4cdNLwYF7UplBj7ZTD8lO9Een0yTD7m_Bbo'
    TXT-запис 2
    _acme-challenge.apps.e954.ocp4.opentlc.com TXT value: 'f4KeyXkpSissmiLbIIoDHm5BJ6tOBTA0D8DyK5sl46g'

  5. Після цього необхідно повторно запустити команду acme.sh:

    $ acme.sh --renew -d e954.ocp4.opentlc.com --yes-I-know-dns-manual-mode-enough-go-ahead-please

  6. Після успішного виконання попередніх пунктів необхідно запустити наступні команди.

    Зазвичай, хорошим підходом є перенесення сертифікатів зі шляху acme.sh за замовчуванням (default path) до більш зручної директорії. Для цього можна використати —install-cert-ключ скрипту acme.sh для копіювання сертифікатів до $HOME/certificates, для прикладу:

    $ export CERTDIR=$HOME/certificates

$ mkdir -p ${CERTDIR} ${HOME}/acme.sh/acme.sh --install-cert -d ${LE_API} -d *.${LE_WILDCARD} --cert-file ${CERTDIR}/cert.pem --key-file ${CERTDIR}/key.pem --fullchain-file ${CERTDIR}/fullchain.pem --ca-file ${CERTDIR}/ca.cer

5.2.1. Встановлення сертифікатів для Router

  • Необхідно створити секрет. Для цього виконайте наступну команду:

$ oc create secret tls router-certs --cert=${CERTDIR}/fullchain.pem --key=${CERTDIR}/key.pem -n openshift-ingress

  • Після виконання попередніх кроків, необхідно оновити Custom Resource:

$ oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec": 	{ "defaultCertificate": { "name": "router-certs" }}}'

6. Створення MachineSet для інфраструктури Ceph

Ресурси MachineSet — це групи машин. Набори машин призначені для машин як набори копій (реплік) для Pods, в яких розгорнуто контейнери. Якщо вам потрібно більше машин або, навпаки, необхідно зменшити їх кількість, можна змінити значенням поля реплік на рівні MachineSet, щоб задовольнити ваші обчислювальні потреби. Для детальної інформації щодо створення MachineSet зверніться до офіційного джерела.

Для розгортання Платформи необхідно створити MachineSet для системи зберігання даних Ceph. Для цього необхідно використати конфігураційний файл machine-set-ceph.yaml, в якому необхідно змінити назву кластера.

Приклад конфігураційного файлу machine-set-ceph.yaml 
kind: MachineSet
metadata:
  name: mdtuddm-b86zw-ceph
  namespace: openshift-machine-api
  labels:
    machine.openshift.io/cluster-api-cluster: mdtuddm-b86zw
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: mdtuddm-b86zw
      machine.openshift.io/cluster-api-machineset: mdtuddm-b86zw-ceph
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: mdtuddm-b86zw
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: mdtuddm-b86zw-ceph
    spec:
      taints:
        - effect: NoSchedule
          key: node.ocs.openshift.io/storage
          value: 'true'
      metadata:
        labels:
          cluster.ocs.openshift.io/openshift-storage: ''
      providerSpec:
        value:
          numCoresPerSocket: 1
          diskGiB: 120
          snapshot: ''
          userDataSecret:
            name: worker-user-data
          memoryMiB: 73728
          credentialsSecret:
            name: vsphere-cloud-credentials
          network:
            devices:
              - networkName: EPAM_OKD_Vlan9_EPG
          metadata:
            creationTimestamp: null
          numCPUs: 16
          kind: VSphereMachineProviderSpec
          workspace:
            datacenter: HXDP-02
            datastore: NCR_Data2
            folder: /HXDP-02/vm/mdtuddm-b86zw
            resourcePool: /HXDP-02/host/HX-02/Resources
            server: vcsa.ncr.loc
          template: mdtuddm-b86zw-rhcos
          apiVersion: vsphereprovider.openshift.io/v1beta1

Після редагування файлу відповідно до назви кластера, необхідно виконати команду, що створить необхідний MachineSet та відповідну кількість нод для розгортання сховища даних Ceph.

У нашому випадку назва кластера визначена в .yaml-файлі як mdtuddm-b86zw.

7. Підготовка та запуск Інсталера для розгортання Платформи на цільовому OKD-кластері

Інсталер — набір команд (скрипт) для розгортання Платформи.

Для запуску Інсталера, необхідно виконати ряд умов з підготовки робочої станції, з якої запускатиметься Інсталер. Нижче розглянуто приклад такої підготовки на базі Ubuntu 20.04 LTS.

7.1. Передумови

Встановіть Docker з офіційного джерела: https://docs.docker.com/engine/install/.

7.2. Розгортання та оновлення Платформи

7.2.1. Розгортання Платформи з нуля

7.2.1.1. Передумови
Переконайтеся, що встановлено необхідні пакети: docker, wget, unzip.

  1. Завантажте необхідну версію інсталера.

    сd /tmp
wget -O mdtu-ddm-platform-<version>.zip https://nexus-public-mdtu-ddm-edp-cicd.apps.cicd2.mdtu-ddm.projects.epam.com/nexus/repository/edp-maven-releases/ua/gov/mdtu/ddm/infrastructure/mdtu-ddm-platform/<version>/mdtu-ddm-platform-<version>.zip

  2. Розпакуйте архів у домашній директорії.

    unzip /tmp/mdtu-ddm-platform-<version>.zip -d /home/<user>/workdir/installer-<version>

  3. Перенесіть kubeconfig після встановлення кластера:

    cd /home/<user>/workdir/installer-<version>
cp /path/to/kubeconfig ./

  4. Перенесіть папку certificates для DSO:

    cp /path/to/folder/certificates ./
7.2.1.2. Додавання окремого конфігураційного файлу для розгортання у середовищі vSphere

  1. Відредагуйте exports.list для vSphere.

    Усі значення необхідно взяти після інсталяції кластера. Також необхідно уточнити актуальні значенння для idgovuaClientId та idgovuaClientSecret.

    vi exports.list

### vSphere Credentials ###
export VSPHERE_SERVER=""
export VSPHERE_USER=""
export VSPHERE_PASSWORD=""
export VSPHERE_CLUSTER=""
export VSPHERE_DATASTORE=""
export VSPHERE_DATACENTER=""
export VSPHERE_NETWORK=""
export VSPHERE_NETWORK_GATEWAY=""
export VSPHERE_RESOURCE_POOL="" #якщо не використовується, ставимо "/"
export VSPHERE_FOLDER=""

### Minio and Vault IPs ###
export VSPHERE_VAULT_INSTANCE_IP=""
export VSPHERE_MINIO_INSTANCE_IP=""

### id.gov.ua ###
export idgovuaClientId=""
export idgovuaClientSecret=""

  2. Відредагуйте install.sh, а саме після source ./functions.sh додайте source ./exports.list.

    vi install.sh

    Це виглядатиме наступним чином:

    #!/usr/bin/env bash
set -e
#Include function file
source ./functions.sh
source ./exports.list
7.2.1.3. Розгортання Інсталера

  1. Виконайте наступні команди:

    IMAGE_CHECKSUM=$(sudo docker load -i control-plane-installer.img | sed -r "s#.*sha256:(.*)#\\1#" | tr -d '\n');
echo $IMAGE_CHECKSUM
sudo docker tag ${IMAGE_CHECKSUM} control-plane-installer:<version>;

  2. Розгорніть нову версію Платформи з образами з нуля:

    sudo docker run --rm --name control-plane-installer-<version> --user root:$(id -g) --net host -v $(pwd):/tmp/installer --env KUBECONFIG=/tmp/installer/kubeconfig --env idgovuaClientId=mock --env idgovuaClientSecret=mock --env deploymentMode=development --entrypoint "/bin/bash" control-plane-installer:<version> -c "./install.sh -i"

    • де deploymentMode може бути development чи production.

7.2.2. Оновлення Платформи

7.2.2.1. Передумови
Переконайтеся, що встановлено необхідні пакети: docker, wget, unzip.

  1. Завантажте необхідну версію інсталера.

    сd /tmp
wget -O mdtu-ddm-platform-<version>.zip https://nexus-public-mdtu-ddm-edp-cicd.apps.cicd2.mdtu-ddm.projects.epam.com/nexus/repository/edp-maven-releases/ua/gov/mdtu/ddm/infrastructure/mdtu-ddm-platform/<version>/mdtu-ddm-platform-<version>.zip

  2. Розпакуйте архів у домашній директорії.

    unzip /tmp/mdtu-ddm-platform-<version>.zip -d /home/<user>/workdir/installer-<version>

  3. Перенесіть kubeconfig після встановлення кластера:

    cd /home/<user>/workdir/installer-<version>
cp /path/to/kubeconfig ./

  4. Перенесіть папку certificates для DSO.

    Якщо сертифікати не змінювалися, даний крок можна пропустити. 
    cp /path/to/folder/certificates ./
7.2.2.2. Додавання окремого конфігураційного файлу для розгортання у середовищі vSphere

  1. Перенесіть exports.list з минулого релізу.

    cp /home/<user>/workdir/installer-<previous_version>/exports.list ./

    Також необхідно уточнити актуальні значенння для idgovuaClientId та idgovuaClientSecret.

  2. Відредагуйте install.sh, а саме після source ./functions.sh додайте source ./exports.list.

    vi install.sh

    Це виглядатиме наступним чином:

    #!/usr/bin/env bash
set -e
#Include function file
source ./functions.sh
source ./exports.list
7.2.2.3. Налаштування компонента MinIO при оновленні кластера у середовищі vSphere

  1. Перенесіть tfstate MinIO з минулого релізу для vSphere.

    cp /home/<user>/workdir/installer-<version>/terraform/minio/vsphere/terraform.tfstate ./terraform/minio/vsphere/

  2. Перенесіть tfstate MinIO (Packer) з минулого релізу для vSphere.

    сp /home/<user>/workdir/installer-<version>/terraform/minio/vsphere/packer/terraform.tfstate ./terraform/minio/vsphere/packer/
7.2.2.4. Налаштування компонента Vault при оновленні кластера у середовищі vSphere

  1. Перенесіть tfstate Vault з минулого релізу.

    cp /home/<user>/workdir/installer-<version>/terraform/vault/vsphere/terraform.tfstate ./terraform/vault/vsphere/

  2. Перенесіть tfstate Vault (Packer) з минулого релізу.

    сp /home/<user>/workdir/installer-<version>/terraform/vault/vsphere/packer/terraform.tfstate ./terraform/vault/vsphere/packer/
7.2.2.5. Розгортання Інсталера

  1. Виконайте наступні команди:

    IMAGE_CHECKSUM=$(sudo docker load -i control-plane-installer.img | sed -r "s#.*sha256:(.*)#\\1#" | tr -d '\n');
echo $IMAGE_CHECKSUM
sudo docker tag ${IMAGE_CHECKSUM} control-plane-installer:<version>;

  2. Оновіть версію Платформи з образами оновлення.

    sudo docker run --rm --name control-plane-installer-<version> --user root:$(id -g) --net host -v $(pwd):/tmp/installer --env KUBECONFIG=/tmp/installer/kubeconfig --env idgovuaClientId=mock --env idgovuaClientSecret=mock --env deploymentMode=development --entrypoint "/bin/bash" control-plane-installer:<version> -c "./install.sh -u"
    де deploymentMode може бути development чи production, залежно від попереднього запуску.

8. Управління налаштуваннями Платформи

Управління кластером відбувається за методологією GitOps. Це означає, що будь-які зміни в конфігурації кластера, компонентів кластера та компонентів Платформи відбувається через зміну конфігурації кластера в git-гілці відповідного компонента.

Метадані усіх компонентів, для яких реалізовано управління через GitOps-підхід, зберігаються в компоненті cluster-mgmt.

Нижче представлено список компонентів, для яких наразі імплементований GitOps-підхід:

  • catalog-source

  • monitoring

  • storage

  • logging

  • service-mesh

  • backup-management

  • user-management

  • control-plane-nexus

  • external-integration-mocks

  • cluster-kafka-operator

  • smtp-server

  • redis-operator

  • postgres-operator