DR-Кластер управления
- C внешним балансировщиком или DNS записями
- Два раздельных кластера управления
- Примеры
- Создание сертификата: ca.json
- Создание сертификата: cfssl.json
- Создание сертификата: interm-ca.json
- Создание сертификата: server-csr.json
- Создание CA
- Создание промежуточного
- Подписание промежуточного сертификата с помощью СА
- Создание и подписание конечного (wildcard) сертификата
- Получение цепочки сертификатов
- Инсталляция первого кластера управления
- Инсталляция второго кластер управления
- Примеры создания резервных копий
На этой странице
- C внешним балансировщиком или DNS записями
- Два раздельных кластера управления
- Примеры
- Создание сертификата: ca.json
- Создание сертификата: cfssl.json
- Создание сертификата: interm-ca.json
- Создание сертификата: server-csr.json
- Создание CA
- Создание промежуточного
- Подписание промежуточного сертификата с помощью СА
- Создание и подписание конечного (wildcard) сертификата
- Получение цепочки сертификатов
- Инсталляция первого кластера управления
- Инсталляция второго кластер управления
- Примеры создания резервных копий
C внешним балансировщиком или DNS записями
В один момент времени есть возможность получить доступ только к одному кластеру управления через графический интерфейс. При этом достигается полная прозрачность для пользователей и самих клиентских кластеров. Перенос данных клиентских кластеров на резервный кластер управления рекомендуется выполнять с сопровождением инженеров внедрения.
- Создайте общее Ingress имя для кластеров управления и сертификат для него.
- Инсталляция кластеров с созданным общим Ingress сертификатом (это необходимо, чтобы был единый доверенный сервис аутентификации назависимо от кластера управления). Здесь возможно два варианта:
- Инсталлируйте два кластера управления с внешним балансировщиком для Ingress и укажите общее имя Ingress (балансировщик смотрит на основной кластер управления). Для Kube API должен быть использован другой экземпляр внешнего балансировщика либо без использования внешнего балансировщика;
- Инсталлируйте два кластера управления с внутренним балансировщиком, указывая разные IP для Ingress, но общее имя Ingress.
На основном кластере управления
- На основном кластере управления настройте подключение к S3-хранилищу для резервного копирования.
- Настройте провайдеры инфраструктуры для создания клиентских кластеров.
- Создайте клиентские кластеры .
- Подключите службу централизованного каталога (LDAP).
- При необходимости создайте платформеные или кластерные назначения ролей на группы/пользователей.
- На дашбордах кластеров нажмите кнопку приостановить реконсиляцию инфраструктуры и создайте резервные копии провайдеров, неймспейсов клиентских кластеров, назначенных ролей в кластере управления.
- В случае возникновения аварии или для проведения теста переключите балансировщик (или измените IP у DNS записи) на второй кластер управления.
На резервном кластере управления
- На втором кластере управления настройте подключение к S3-хранилищу для резервного копирования.
- Дождитесь, пока резервные копии, созданные в основном кластере управления, отобразятся в интерфейсе. Восстанавите резервные копии в указанной очередности:
- провайдеры инфраструктуры;
- неймспейсы клиентских кластеров;
- UserRoles, GroupRoles.
- Дождитесь, пока клиентские кластеры отобразятся в интерфейсе. На дашбордах кластеров нажмите кнопку возобновить реконсиляцию инфраструктуры. Может потребоваться несколько минут для восстановления работы кластеров.
Всё должно функционировать так же, как и на основном кластере управления.
Два раздельных кластера управления
Преимущества подхода: сразу доступны обе платформы, не требуется внешний балансировщик. Перенос данных клиентских кластеров на резервный кластер управления рекомендуется выполнять с сопровождением инженеров внедрения.
- Создайте общий сертификат для Ingress на два кластера управления (иначе после переключения на резервный кластер управления потребуется на каждом Master-узле клиентских кластеров обновить CA сертификат)
- Инсталлируйте 2 кластера управления с общим сертификатом для Ingress. Один кластер считать основным, второй - DR.
На основном кластере управления
- На основном кластере управления настройте подключение к S3-хранилищу для резервного копирования . Доступ к этому же хранилищу необходимо настроить для DR-кластера.
- Настройте провайдеры инфраструктуры для создания клиентских кластеров.
- Создайте клиентские кластеры .
- Подключите службу централизованного каталога (LDAP).
- При необходимости создайте платформенные или кластерные назначения ролей на группы/пользователей.
- На дашбордах кластеров нажмите кнопку приостановить реконсиляцию инфраструктуры и создайте резервные копии провайдеров, неймспейсов клиентских кластеров, назначенных ролей в кластере управления.
На резервном кластере управления
- На втором кластере управления (DR) настройте подключение к S3-хранилищу.
- Подключите службу централизованного каталога (LDAP).
- Дождитесь, пока резервные копии, созданные в основном кластере управления, отобразятся в интерфейсе. Восстановите резервные копии в указанной очередности:
- провайдеры инфраструктуры;
- неймспейсы клиентских кластеров;
- UserRoles, GroupRoles.
- Дождитесь, пока клиентские кластеры отобразятся в интерфейсе. На дашбордах кластеров нажмите кнопку возобновить реконсиляцию инфраструктуры. Может потребоваться несколько минут для восстановления работы кластеров.
Для авторизации с помощью kubeconfig необходимо дополнительно:
- Перенастройте Kube-APIServer на всех Master-узлах клиентских серверов, указав oidc-issuer-url на необходимый кластер управления.
- Перенастройте параметры авторизации для сервисов чартов на IP Ingress: shturval-cd, shturval-dashboards, shturval-log-operator, shturval-metrics.
Примеры
Для создания сертификатов в примерах использована утилита 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.6.0 install management --cluster-name test-cluster --ssh-user=root --ssh-private-key=~/.ssh/stc --ha-type=ha \
--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.6.0 \
--secure=true
Инсталляция второго кластер управления
./bin/stc_2.6.0 install management --cluster-name test-cluster2 --ssh-user=root --ssh-private-key=~/.ssh/stc --ha-type=ha \
--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.6.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