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

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

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

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

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

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

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

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

1. провайдеры инфраструктуры;
2. неймспейсы клиентских кластеров;
3. UserRoles, GroupRoles.

• Дождитесь, пока клиентские кластеры отобразятся в интерфейсе. На дашбордах кластеров нажмите кнопку возобновить реконсиляцию инфраструктуры. Может потребоваться несколько минут для восстановления работы кластеров.

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

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

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

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

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

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

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

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

1. провайдеры инфраструктуры;
2. неймспейсы клиентских кластеров;
3. 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.7.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.7.0 \
--secure=true

Инсталляция второго кластер управления #

./bin/stc_2.7.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.7.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