База знаний
Войти

Режимы

DR-Кластер управления

C внешним балансировщиком или DNS-записями

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

  1. Создать общее Ingress-имя для кластеров управления и сертификат для него.
  2. Установить кластеры с созданным общим Ingress-сертификатом (это необходимо, чтобы был единый доверенный сервис аутентификации независимо от кластера управления). Здесь возможно два варианта:
  • установить два кластера управления с внешним балансировщиком для Ingress и указать общее имя Ingress (балансировщик смотрит на основной кластер управления). Для Kube API должен быть использован другой экземпляр внешнего балансировщика либо без использования внешнего балансировщика;
  • установить два кластера управления с внутренним балансировщиком, указывая разные IP для Ingress, но общее имя Ingress.

На основном кластере управления:

  1. настроить подключение к S3-хранилищу для резервного копирования (п. Управление резервными копиями);
  2. настроить провайдеры инфраструктуры для создания клиентских кластеров;
  3. создать клиентские кластеры;
  4. подключить службу централизованного каталога (LDAP);
  5. при необходимости создать платформенные или кластерные назначения ролей на группы/пользователей.
  6. на дашбордах кластеров нажать кнопку Приостановить для реконсиляции инфраструктуры и создать резервные копии провайдеров, пространств имен клиентских кластеров, назначенных ролей в кластере управления.
  7. в случае возникновения аварии или для проведения теста переключить балансировщик (или изменить IP-адрес у DNS-записи) на второй кластер управления.

На резервном кластере управления:

  1. на втором кластере управления настроить подключение к S3-хранилищу для резервного копирования;
  2. дождаться, пока резервные копии, созданные в основном кластере управления, отобразятся в интерфейсе. Восстановите резервные копии в указанной очередности:
  • провайдеры инфраструктуры;
  • пространства имен клиентских кластеров;
  • UserRoles, GroupRoles.
  1. дождаться, пока клиентские кластеры отобразятся в интерфейсе. На дашбордах кластеров нажать кнопку Возобновить для реконсиляции инфраструктуры. Может потребоваться несколько минут для восстановления работы кластеров.

Все должно функционировать так же, как и на основном кластере управления.

Два раздельных кластера управления

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

  1. Создать общий сертификат для Ingress на два кластера управления (иначе после переключения на резервный кластер управления потребуется на каждом Master-узле клиентских кластеров обновить CA сертификат).
  2. Установить 2 кластера управления с общим сертификатом для Ingress. Один кластер считать основным, второй ‒ DR.

На основном кластере управления:

  1. настроить подключение к S3-хранилищу для резервного копирования. Доступ к этому же хранилищу необходимо настроить для DR-кластера;
  2. настроить провайдеры инфраструктуры для создания клиентских кластеров;
  3. создать клиентские кластеры;
  4. подключить службу централизованного каталога (LDAP);
  5. при необходимости создать платформенные или кластерные назначения ролей на группы/пользователей;
  6. на дашбордах кластеров нажать кнопку Приостановить для реконсиляции инфраструктуры и создать резервные копии провайдеров, пространств имен клиентских кластеров, назначенных ролей в кластере управления.

На резервном кластере управления:

  1. на втором кластере управления (DR) настроить подключение к S3-хранилищу.
  2. подключить службу централизованного каталога (LDAP);
  3. дождаться, пока резервные копии, созданные в основном кластере управления, отобразятся в интерфейсе. Восстановить резервные копии в указанной очередности:
  • провайдеры инфраструктуры;
  • пространства имен клиентских кластеров;
  • UserRoles, GroupRoles.
  1. дождаться, пока клиентские кластеры отобразятся в интерфейсе. На дашбордах кластеров нажать кнопку Возобновить для реконсиляции инфраструктуры. Может потребоваться несколько минут для восстановления работы кластеров.

Для авторизации с помощью kubeconfig необходимо дополнительно:

  1. перенастроить Kube-APIServer на всех Master-узлах клиентских серверов, указав oidc-issuer-url на необходимый кластер управления;
  2. перенастроить параметры авторизации для сервисов чартов на IP-адрес Ingress: shturval-cd, shturval-dashboards, shturval-log-collector, shturval-metrics-collector.

Примеры создания сертификатов

Для создания сертификатов в примерах использована утилита cfssl.

Создание сертификата ca.json:

{
"CN": "Yourcompany Root CA",
"key": {
"algo": "ecdsa",
"size": 256
},
"ca": {
"expiry": "175200h"
},
"names": [
{
"C": "RU",
"L": "Moscow",
"ST": "Moscow",
"O": "yourcompany.ru",
"OU": "Yourcompany Root CA"
}
]
}

Создание сертификата cfssl.json:

{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"intermediate_ca": {
"usages": [
"signing",
"digital signature",
"key encipherment",
"cert sign",
"crl sign",
"server auth",
"client auth"
],
"expiry": "87600h",
"ca_constraint": {
"is_ca": true,
"max_path_len": 0,
"max_path_len_zero": true
}
},
"peer": {
"usages": [
"signing",
"digital signature",
"key encipherment",
"client auth",
"server auth"
],
"expiry": "8760h"
},
"server": {
"usages": [
"signing",
"digital signing",
"key encipherment",
"server auth"
],
"expiry": "8760h"
},
"client": {
"usages": [
"signing",
"digital signature",
"key encipherment",
"client auth"
],
"expiry": "8760h"
}
}
}
}

Создание сертификата interm-ca.json:

{
"CN": "Shturval Intermediate CA 2",
"key": {
"algo": "ecdsa",
"size": 256
},
"ca": {
"expiry": "87600h"
},
"names": [
{
"C": "RU",
"L": "Moscow",
"ST": "Moscow",
"O": "shturval.tech",
"OU": "Shturval Intermediate CA 2"
}
]
}

Создание сертификата server-csr.json:

{
"CN": "apps.ip-XX-XX-XXX-XX.shturval.link",
"hosts": [
"*.apps.ip-XX-XX-XXX-XX.shturval.link",
"*.apps.ip-XX-XX-XXX-XXY.shturval.link",
"*.apps.ip-XX-XX-XXX-XXZ.shturval.link"
],
"key": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"C": "RU",
"ST": "Moscow",
"L": "Moscow",
"O": "Multi cluster manage cert",
"OU": "Multi cluster manage cert"
}
]
}

Создание CA:

cfssl gencert -initca ca.json | cfssljson -bare ca

Создание промежуточного сертификата:

cfssl gencert -initca interm-ca.json | cfssljson -bare interm-ca

Подписание промежуточного сертификата с помощью СА:

cfssl sign -ca ca.pem -ca-key ca-key.pem -config cfssl.json -profile intermediate_ca interm-ca.csr | cfssljson -bare interm-ca

Создание и подписание конечного (wildcard) сертификата:

cfssl gencert -ca=interm-ca.pem -ca-key=interm-ca-key.pem \
--config=cfssl.json -profile=server \
server-csr.json | cfssljson -bare server

Получение цепочки сертификатов:

cat server.pem interm-ca.pem ca.pem >server-chain.pem

Примеры установки кластеров

Установка первого кластера управления:

./bin/stc_2.9.0 install management --cluster-name test-cluster --ssh-user=root --ssh-private-key=~/.ssh/stc \
--master-nodes=XX.XX.AAA.AAB,XX.XX.AAA.ABB,XX.XX.AAA.BBB \
--worker-nodes=XX.XX.AAA.CC,XX.XX.AAA.CD \
--api-endpoint=XX.XX.AAA.DD \
--use-external-ingress-lb \
--ingress=apps.ip-YY-YY-YYY-YY.shturval.link \
--ca-cert=/home/shturval/Downloads/projects/cert-test/multi/interm-ca.pem \
--ca-key=/home/shturval/Downloads/projects/cert-test/multi/interm-ca-key.pem \
--ingress-cert=/home/shturval/Downloads/projects/cert-test/multi/server-chain.pem \
--ingress-key=/home/shturval/Downloads/projects/cert-test/multi/server-key.pem \
--license=licensenumber \
--ntp-servers=0.ru.pool.ntp.org,1.ru.pool.ntp.org \
--registry=yourregistry \
--debug \
--skip-check=true \
--platform-version 2.10.0 \
--secure=true

Установка второго кластера управления:

./bin/stc_2.7.0 install management --cluster-name test-cluster2 --ssh-user=root --ssh-private-key=~/.ssh/stc \
--master-nodes=XX.XX.BBB.AAB,XX.XX.BBB.ABB,XX.XX.BBB.BBB \
--worker-nodes=XX.XX.BBB.CC,XX.XX.BBB.CD \
--api-endpoint=XX.XX.BBB.DD \
--use-external-ingress-lb \
--ingress=apps.ip-YY-YY-YYY-YY.shturval.link \
--ca-cert=/home/shturval/Downloads/projects/cert-test/multi/interm-ca.pem \
--ca-key=/home/shturval/Downloads/projects/cert-test/multi/interm-ca-key.pem \
--ingress-cert=/home/shturval/Downloads/projects/cert-test/multi/server-chain.pem \
--ingress-key=/home/shturval/Downloads/projects/cert-test/multi/server-key.pem \
--license=licensenumber \
--ntp-servers=0.ru.pool.ntp.org,1.ru.pool.ntp.org \
--registry=yourregistry \
--debug \
--skip-check=true \
--platform-version 2.10.0 \
--secure=true

Примеры создания резервных копий

Манифест резервной копии провайдеров инфраструктуры:

apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/resource-timeout: 10m0s
velero.io/source-cluster-k8s-gitversion: v1.29.1
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "29"
labels:
velero.io/storage-location: s3
name: backup-platform-providers
namespace: velero
spec:
csiSnapshotTimeout: 24h
defaultVolumesToFsBackup: false
hooks: {}
includedNamespaces:
‒ capv-system
‒ capov-system
‒ capbd-system
‒ shturval-capsm
includedClusterScopedResources:
‒ vspherefailuredomains.infrastructure.cluster.x-k8s.io
‒ vspheredeploymentzones.infrastructure.cluster.x-k8s.io
‒ vsphereclusteridentities.infrastructure.cluster.x-k8s.io
‒ ovirtproviders.infrastructure.cluster.x-k8s.io
‒ basisproviders.infrastructure.cluster.x-k8s.io
‒ shturvalproviders.infrastructure.cluster.x-k8s.io
‒ shturvalhosts.infrastructure.cluster.x-k8s.io
metadata: {}
snapshotMoveData: false
storageLocation: s3
ttl: 24h

Манифест резервной копии объектов пространств имен клиентских кластеров:

apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/resource-timeout: 10m0s
velero.io/source-cluster-k8s-gitversion: v1.29.1
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "29"
labels:
velero.io/storage-location: s3
name: backup-clusters
namespace: velero
spec:
csiSnapshotTimeout: 24h
defaultVolumesToFsBackup: false
hooks: {}
includedNamespaces:
‒ shturval-myclustername-client1
‒ shturval-myclustername-client2
metadata: {}
snapshotMoveData: false
storageLocation: s3
ttl: 24h

Манифест резервной копии ролей, назначенных на пользователей и группы:

apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/resource-timeout: 10m0s
velero.io/source-cluster-k8s-gitversion: v1.29.1
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "29"
labels:
velero.io/storage-location: s3
name: backup-platform-roles
namespace: velero
spec:
csiSnapshotTimeout: 10m0s
defaultVolumesToFsBackup: false
hooks: {}
includedNamespaces:
‒ shturval-backend
includedResources:
‒ GroupRole
‒ UserRole
metadata: {}
snapshotMoveData: false
storageLocation: s3
ttl: 24h

Пример сетевого взаимодействия

Пример сетевого взаимодействия приведен на рисунке 14.

Рисунок 14 ‒ Shturval v2 DR-платформа с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress

Отдельно стоящий кластер

Кластер управления может быть использован как отдельно стоящий кластер для полнофункционального запуска рабочих нагрузок. После установки в Комплексе будет доступен экземпляр провайдера инфраструктуры shturval v2 (п. С провайдером Shturval V2) с именем кластера, присвоенным в процессе установки. В интерфейсе провайдера будут доступны хосты, на которых развернут кластер управления. При необходимости масштабирования кластера управления можно добавить дополнительные хосты в этот экземпляр провайдера.

Интерфейс кластера управления будет доступен в разделе "Кластеры → Кластер управления" (рисунок 15).

Рисунок 15 ‒ Интерфейс кластера управления

Функционал отдельно стоящего кластера управления отличается от клиентского кластера только разделом "Оповещения" ‒ в кластере управления он отсутствует (рисунок 16).

Рисунок 16 ‒ Интерфейс отдельно стоящего кластера управления

Для преобразования отдельно стоящего кластера управления в полнофункциональную платформу управления множеством кластеров никаких дополнительных настроек не требуется.

Примеры сетевого взаимодействия

Рисунок 17 ‒ Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и Ingress

Рисунок 18 ‒ Shturval v2 stand-alone кластер с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress