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

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

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

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

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

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

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

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

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

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

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

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

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

  • На втором кластере управления (DR) настройте подключение к S3-хранилищу.
  • Подключите службу централизованного каталога (LDAP).
  • Дождитесь, пока резервные копии, созданные в основном кластере управления, отобразятся в интерфейсе. Восстановите резервные копии в указанной очередности:
  1. провайдеры инфраструктуры;
  2. неймспейсы клиентских кластеров;
  3. 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": "clustername.ip-XX-XX-XXX-XX.shturval.link",
    "hosts": [
        "*.clustername.ip-XX-XX-XXX-XX.shturval.link",
        "*.clustername.ip-XX-XX-XXX-XXY.shturval.link",
        "*.clustername.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

capsmdrextingress2

← Деинсталляция платформы
Отдельно стоящий кластер →
×