#Работа системы в Kubernetes

#Установка с помощью Helm-чарта

Порядок установки:

1. Создать namespace.

   kubectl create namespace codescoring

2. Создать secret для доступа к приватному реестру Docker-образов системы "CodeScoring", используя адрес (REGISTRY_URL), логин (USERNAME) и пароль (PASSWORD), полученные от вендора.

   kubectl create secret docker-registry codescoring-regcred --docker-server=REGISTRY_URL --docker-username=USERNAME --docker-password=PASSWORD -n codescoring

   Альтернативно, можно создать секрет для доступа к реестру с помощью values.yaml, добавив в поле .Values.imagePullSecrets запись вида

   registry.org: |
     {"auths":{"registry.org":{"auth":"<base64>"}}}

3. Установить Helm предпочтительным способом.

4. Выполнить следующие команды для добавления актуального Helm-репозитория на локальную машину:

   helm repo add codescoring-org https://{REGISTRY_URL}/repository/helm/ --username USERNAME --password PASSWORD
   helm repo update

#Настройки параметров Helm-чарта

Для удобного редактирования параметров CodeScoring можно скачать и распаковать исходный код Helm-чарта командой:

helm pull codescoring-org/codescoring-helm --version CHART_VERSION --untar --untardir codescoring-src && cd codescoring-src

В файле values.yaml можно отредактировать нужные переменные, и после этого, находясь в каталоге с исходным кодом Helm-чарта, выполнить команду установки:

helm install codescoring . -f values.yaml -n codescoring --atomic --version CHART_VERSION

Структура чарта предполагает, что абсолютно вся конфигурация, вплоть до описания Kubernetes-ресурсов, описывается в values.yaml, из-за чего данный файл является довольно объемным и его редактирование может быть не столь удобно. Вполне допустимо и даже рекомендуется, при необходимости в переопределении каких-либо параметров, создать дополнительный файл с произвольным именем, например, values-override.yaml (здесь и далее этот файл будет называться именно так), в котором и переопределить значения необходимых полей. Для удобства с чартом поставляется шаблон файла values-override.yaml.

В таком случае команда установки будет выглядеть так (порядок указания файлов имеет значение):

helm install codescoring . -f values.yaml -f values-override.yaml -n codescoring --atomic --version CHART_VERSION

#Установка с использованием встроенных PostgreSQL и Redis

Чарт предусматривает возможность развертывания PostgreSQL и Redis. Для этого предусмотрены ресурсы StatefulSet. Чтобы активировать установку PostgreSQL и Redis, необходимо определить следующие параметры в values-override.yaml:

statefulSets:
  codescoring-postgresql:
    enabled: true
    containers:
      postgresql:
        resources:
          limits:
            cpu: 2000m
            memory: 12Gi
          requests:
            cpu: 1m
            memory: 500Mi

  codescoring-redis:
    enabled: true
    containers:
      redis:
        resources:
          limits:
            cpu: 2000m
            memory: 4Gi

pvcs:
  codescoring-postgresql:
    accessModes:
      - ReadWriteOnce
    size: 20Gi
    storageClassName: "default"
  codescoring-redis:
    accessModes:
      - ReadWriteOnce
    size: 1Gi
    storageClassName: "default"

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

#Подключение к внешним базам данных

#Подключение к внешнему Redis

Для подключения к внешнему Redis, необходимо указать соответствующие строки подключения в следующих полях, соблюдая соответствие номеров баз данных:

configMaps:
  ipcs-backend-env:
    data:
      DJANGO_CACHES_REDIS_URL: "redis://codescoring-redis:6379/1"
      HUEY_REDIS_URL: "redis://codescoring-redis:6379/0"
      CELERY_BROKER_URL: "redis://codescoring-redis:6379/2"
      CELERY_RESULT_BACKEND: "redis://codescoring-redis:6379/2"

#Подключение к PostgreSQL через пулер Pgbouncer

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

1. Сконфигурировать пулер соединений, указав соответствующие данные в следующих полях:

   secrets:
     pgbouncer-secrets:
       data:
         # секреты для подключения pgbouncer к PostgreSQL
         POSTGRES_DB: "codescoring_db"
         POSTGRES_USER: "codescoring_user"
         POSTGRES_PASSWORD: "changeme"
         # секреты для внутренних пулов pgbouncer
         TRANSACTION_POOL_PASSWORD: "changeme"
         SESSION_POOL_PASSWORD: "changeme"
         STATS_USER: "codescoring_user-stats"
         STATS_PASSWORD: "changeme"
         ADMIN_USER: "codescoring_user-admin"
         ADMIN_PASSWORD: "changeme"
   
   configMaps:
     pgbouncer-env:
       data:
         # параметры подключения pgbouncer к PostgreSQL
         POSTGRES_HOST: "codescoring-postgresql"
         POSTGRES_PORT: "5432"
         # параметры для внутренних пулов pgbouncer
         TRANSACTION_POOL_USER: "codescoring_user"
         SESSION_POOL_USER: "codescoring_user-session"
         TRANSACTION_POOL_SIZE: "50"
         TRANSACTION_POOL_MIN_SIZE: "1"
         SESSION_POOL_SIZE: "50"
         SESSION_POOL_MIN_SIZE: "1"
         # виртуальные базы данных pgbouncer, существуют только внутри него
         TRANSACTION_POOL_DATABASE_NAME: "codescoring_generic"
         SESSION_POOL_DATABASE_NAME: "codescoring_generic-session"
         MAX_CLIENT_CONN: "500"

2. Передать созданные в пункте 1 конфигурационные параметры компонентам CodeScoring:

   secrets:
     ipcs-secrets:
       data:
         # секреты для подключения к пулам из pgbouncer-secrets
         TRANSACTION_POOL_PASSWORD: "changeme"
         SESSION_POOL_PASSWORD: "changeme"
         DATABASE_PASSWORD: "changeme" # соответствует TRANSACTION_POOL_PASSWORD
   
   configMaps:
     ipcs-backend-env:
       data:
         # параметры подключения osa-api и judge
         DATABASE_HOST: "pgbouncer"
         DATABASE_PORT: "6432"
         DATABASE_USERNAME: "codescoring_user" # соответствует TRANSACTION_POOL_USER
         DATABASE_NAME: "codescoring_db" # соответствует TRANSACTION_POOL_DATABASE_NAME
   
         TRANSACTION_POOL_HOST: "pgbouncer"
         TRANSACTION_POOL_PORT: "6432"
         TRANSACTION_POOL_USER: "codescoring_user"
         TRANSACTION_POOL_DATABASE_NAME: "codescoring_db"
   
         SESSION_POOL_HOST: "pgbouncer"
         SESSION_POOL_PORT: "6432"
         SESSION_POOL_USER: "codescoring_user-session"
         SESSION_POOL_DATABASE_NAME: "codescoring_generic-session"

#Настройка томов

#Dynamic Volume Provisioning с использованием требуемого StorageClass

Чарт создает необходимые тома через Dynamic Volume Provisioning с использованием указанного явно StorageClass.

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

pvcs:
  # storageClassName необходимо заменить на используемый в кластере
  codescoring-ipcs-django-static:
    accessModes:
      - ReadWriteOnce
    size: 10Gi
    storageClassName: "default"
  codescoring-ipcs-analysis-root:
    accessModes:
      - ReadWriteOnce
    size: 10Gi
    storageClassName: "default"
  codescoring-ipcs-media-root:
    accessModes:
      - ReadWriteOnce
    size: 10Gi
    storageClassName: "default"

Если кластер поддерживает тома с типом доступа ReadWriteMany (RWX), то рекомендуется использовать именно его, так как в этом случае допустимо размещение компонентов инсталляции на разных нодах кластера. Если же поддержки RWX в кластере нет, либо есть необходимость в использовании RWO по иным причинам, рекомендуется настроить podAffinity, чтобы поды, использующие одни и те же тома были назначены на одну ноду: Для этого необходимо добавить следующий блок в values-override.yaml:

deploymentsGeneral:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: codescoring-component
                operator: In
                values:
                  - backend
                  - frontend
                  - huey
                  - celery
          topologyKey: kubernetes.io/hostname

#PersistentVolumeClaim для заранее созданных PersistentVolume

Названия предварительно созданных PersistentVolume можно указать в поле volumeName, например:

pvcs:
  codescoring-ipcs-analysis-root:
    accessModes:
      - ReadWriteOnce
    size: 10Gi
    storageClassName: "default"
    volumeName: "codescoring-precreated-pv"

#Настройка ограничения ресурсов (resource limits)

По умолчанию requests и limits заданы в демонстрационных объемах, не предназначенных для продуктивного использования. Это сделано для обеспечения возможности запуска системы CodeScoring в кластерах с малым количеством ресурсов (например, minikube) c целью тестирования. При запуске в production-окружении может потребоваться настроить ограничение ресурсов. Это можно сделать, отредактировав следующие поля:

#Ограничение ресурсов для init-контейнеров

# ограничения, применяемые ко всем init-контейнерам
# редактирование данного поля возможно только в values.yaml, override невозможен из-за ограничений yaml-структур
init-container-resources: &init-container-resources
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 1m
      memory: 100Mi

# отдельно настраиваются ограничения init-контейнеров компонента backend
deployments:
  ipcs-backend:
    initContainers:
      ipcs-collectstatic:
        resources:
          limits:
            cpu: 1000m
            memory: 2Gi
          requests:
            cpu: 1m
            memory: 500Mi
      ipcs-migrate:
        resources:
          limits:
            cpu: 1000m
            memory: 2Gi
          requests:
            cpu: 1m
            memory: 500Mi

#Настройка ограничений ресурсов для основных контейнеров компонентов

В общем виде ресурсы конфигурируются по следующему шаблону:

deployments:
  <deployment-name>:
    containers:
      <container-name>:
        resources:
          limits:
            cpu: 8000m
            memory: 12Gi
          requests:
            cpu: 1m
            memory: 500Mi

Возможно указание как requests и limits вместе, так и по отдельности. Однако, при указании только limits, Kubernetes автоматически выставит requests в таком же объеме, что может негативно сказаться на назначении подов на ноды.

#Добавление сертификата удостоверяющего центра (CA)

Для доступа CodeScoring к ресурсам с TLS-сертификатами, подписанными корпоративным удостоверяющим центром (CA) необходимо добавить корневой сертификат удостоверяющего центра (RootCA) в values.yaml в формате ключ: значение, где ключ - имя файла сертификата, включая расширение .crt, значение - сертификат в формате PEM, в следующее поле:

secrets:
  ca-certificates:
    data:
      my-root-CA.crt: |-
        -----BEGIN CERTIFICATE-----
        MIIDTDCCAjSgAwIBAgIBATANBgkqhkiG9w0BAQUFADA3MQswCQYDVQQGEwJERTEP
        MA0GA1UEChMGZWR1UEtJMRcwFQYDVQQDEw5lZHVQS0kgVGVzdCBDQTAeFw0xMDAz
        MzExMjIwMjRaFw0zMDAzMjYxMjIwMjRaMDcxCzAJBgNVBAYTAkRFMQ8wDQYDVQQK
        EwZlZHVQS0kxFzAVBgNVBAMTDmVkdVBLSSBUZXN0IENBMIIBIjANBgkqhkiG9w0B
        AQEFAAOCAQ8AMIIBCgKCAQEAt5IxCk/NQPOLqeA1lGuB3pvqHGQPxRQ1udYGcXQY
        t7EuSMFymUR9m5TsifG1ktktJTtOWyaWFC4ac0vai49wGVeuDYptfZBoHLIUvCwN
        DOofLYHxk04WzfrtSiUTptn1o6QPOw8YR0XH30MEi1zgD8fLMZmVTJ+XwA5Eus6c
        XtTmI4XhNrHUtvWt4UsNgLmp5/djUgRMpNqxIdrpFQzl+XycRJRAaoAwUzHFl14t
        49qwBhGChxQ8AdDMQGA7kv6VR8o0ktCPv3a4GQbs8+z0cX0w5dC+XhJ1xpqW6TOg
        qAY9XBFIDe5j21hjKmNZ39rsODVGUS2wUtNEhSz+3YqxLwIDAQABo2MwYTAdBgNV
        HQ4EFgQUqHe3saMjZZLan8RlFJs+Xuz4yiAwHwYDVR0jBBgwFoAUqHe3saMjZZLa
        n8RlFJs+Xuz4yiAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwDQYJ
        KoZIhvcNAQEFBQADggEBAEjQGyHZQis47c2kf+zXJJoDDlRgFzr9xfcnrHFaJvYx
        nuqNE0T+xmujnwGm3VrgddeAQJuW3sD6y0Ox8NgL4z886VFeaDQ0GmFPI6HEVtg6
        mixMhi+YzdkC+PFrEdYUeVNNwVO+bvJb1Rc08BYU4v7VtTkssHjru76E2/ahn/Ct
        kaVTEojEWeRaxsw5/0VLkgyf8SwDaukM2aamqgEzfsw5GTdSAh7ERZKc+zF7Sr5s
        DY8c5lOmyCwuNh9ODuw4cAThICrn7G8bh8ZyxLyj4Znxh0X45SwMZKTmYLfy9ab8
        b/j7FK8uBNRL+pXl9HGBWAFA01uJw4HkYK+Uo+RcAzo=
        -----END CERTIFICATE-----

Допустимо указание неограниченного количества файлов, но критически важно, чтобы каждый сертификат был в отдельном файле.

#Переменные окружения

#Управление переменными окружения через values

Переменные окружения, а также конфигурационные файлы, используемые компонентами инсталляции, описаны в блоках configMaps и secrets в values.yaml. В values-override.yaml вынесены наиболее часто переопределяемые параметры конфигурации.

#Управление переменными окружения через External Secret

Также присутствует возможность подключать внешние хранилища секретов. Для этого в кластере должен быть установлен External Secrets Operator (ESO). Он добавляет в кластер необходимые CRD (Custom Resource Definition) и обеспечивает связь с хранилищем секретов.

Для создания ресурса ExternalSecret и подключения его к существующему SecretStore необходимо добавить соответствующую запись в блок vaults:

vaults:
  ipcs-backend-secret-external: # название секрета, который будет создан в результате
    apiVersion: external-secrets.io/v1 # по умолчанию external-secrets.io/v1beta1
    enabled: true
    store:
      name: vault-backend # имя предварительно созданного SecretStore
      kind: ClusterSecretStore # тип предварительно созданного SecretStore
    path: secret/data/my-vault-secret # путь до секрета в Vault

Для передачи созданного секрета всем ресурсам Deployment, в поле deploymentsGeneral.envSecrets необходимо добавить в список название ресурса из блока vaults, например:

deploymentsGeneral:
  envConfigmaps:
    - ipcs-backend-env
  envSecrets:
    - ipcs-secrets
    - ipcs-backend-secret-external # имя ресурса из vaults

Для передачи секрета только одному ресурсу Deployment, необходимо указать его в блоке deployments наряду со всеми секретами, которые уже используются данным ресурсом, например:

deployments:
  ipcs-backend:
    envSecrets:
      - ipcs-secrets
      - ipcs-backend-secret-external

#Миграция с Helm Chart 2.x.x

Во время миграции инсталляция будет недоступна, поэтому рекомендуется выделять технологическое окно. Для проведения работ потребуется суммарно 5-10 минут.

Шаги для миграции:

1. Удалить все ресурсы Deployment kubectl delete deployment --all -n codescoring

2. Удалить все ресурсы Service kubectl delete service --all -n codescoring

3. Выполнить helm upgrade, предварительно заполнив values.yaml и values-override.yaml согласно пункту Настройки параметров Helm-чарта:

   helm upgrade codescoring codescoring-org/codescoring-helm --version <CHART_VERSION> -f values.yaml -f values-override.yaml -n codescoring