English

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

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

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

Создать namespace.
```
kubectl create namespace codescoring
```
Создать 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>"}}}
```
Установить Helm предпочтительным способом.
Выполнить следующие команды для добавления актуального Helm-репозитория на локальную машину:
```
helm repo add codescoring-org https://{REGISTRY_URL}/repository/helm/ --username USERNAME --password PASSWORD
helm repo update
```

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

Важно

Настоятельно рекомендуется вносить необходимые изменения до установки CodeScoring, в противном случае может потребоваться полная переустановка системы. Данные инструкции предполагают, что специалист имеет опыт работы с кластером Kubernetes и утилитой Helm.

Note

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

Для удобного редактирования параметров 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 необходимо выполнять с использованием пулера соединений.

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

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

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"

Передать созданные в пункте 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, в следующее поле:

Допустимо указание неограниченного количества файлов, href="#__codelineno-16-1">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¶

Важно

Если использовалась встроенная PostgreSQL, перед любыми манипуляциями необходимо сделать бэкап.

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

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

Удалить все ресурсы Deployment kubectl delete deployment --all -n codescoring
Удалить все ресурсы Service kubectl delete service --all -n codescoring
Выполнить 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
```

Страница была полезна?