Режимы

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

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

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

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

установить два кластера управления с внешним балансировщиком для Ingress и указать общее имя Ingress (балансировщик смотрит на основной кластер управления). Для Kube API должен быть использован другой экземпляр внешнего балансировщика либо без использования внешнего балансировщика;
установить два кластера управления с внутренним балансировщиком, указывая разные IP для Ingress, но общее имя Ingress.

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

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

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

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

Может потребоваться несколько минут для восстановления работы кластеров.

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

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

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

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

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

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

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

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

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

перенастроить Kube-APIServer на всех Control Plane-узлах клиентских серверов, указав oidc-issuer-url на необходимый кластер управления;
перенастроить параметры авторизации для сервисов чартов на 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

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

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

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

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

Пример сетевого взаимодействия Shturval v2 DR-платформы с внутренним балансировщиком для KubeAPI и внешним балансировщиком для Ingress приведен на рисунке 28.

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

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

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

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

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

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

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

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

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

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

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