Ныряем в готовые кластеры Kubernetes с Deckhouse и werf20.12.2022 15:47

Российские облачные провайдеры начали предоставлять неплохие managed-решения для Kubernetes. Однако многие из них требуют доводки до ума и установки большого количества компонентов, направленных на сбор логов, мониторинг и доступ к кластеру. Это вынуждает пользователей собирать свой собственный бандл с Prometheus, Grafana и т.д., что крайне неудобно и требует дополнительных усилий.

Вот и я, столкнувшись с Managed Kubernetes от Selectel, захотел использовать что-то готовое, желательно от российских разработчиков. Я обратил внимание на платформу Deckhouse, которую к тому моменту можно уже было ставить в готовые кластеры k8s. В этой статье я расскажу про свой путь интеграции D8 и werf в инфраструктуру Selectel и те проблемы, с которыми столкнулся в процессе.

Я прекрасно осведомлен, что EE-версия не требует столько усилий и запускается поверх облака Selectel с cloud provider OpenStack, однако данная опция мне недоступна. Поэтому работать будем с тем, что есть, а именно — с облачной платформой, Managed Kubernetes и Container Registry.

Подсчет инфраструктуры

Будем считать, что у нас уже есть Git-хранилище. Я предпочитаю использовать GitLab, поэтому дальнейшая интеграция будет именно с ним.

Для начала рассчитаем ресурсы. В идеологии Deckhouse есть разделение узлов на конкретные роли:

Master — узлы Control Plane. На них крутится ETCD и K8S Apiserver. В Selectel они будут от нас скрыты.
System — узлы для системных компонентов. Сюда встанут различные компоненты мониторинга. Сюда же стоит вынести и другие кластерные компоненты — например, контроллер Container Storage Interface (CSI). Скорее всего это будут узлы со значительным объемом памяти.
Frontend — узлы для ingress и всяческого приема трафика. На них запускается Ingress, VPN и тому подобное.
Worker — узлы общего назначения, для приложений.

Чтобы просто запустить приложение, то есть для минимального кластера, будет достаточно нескольких нод из группы Worker. Однако создание продакшена потребует разделения ролей, а также настройку автоскейлинга. Именно поэтому важно создание нод группы System — в отличие от Worker, на них будет постоянный набор компонентов и эта группа будет относительно стабильна.

В различных примерах конфигурации, которые я приведу в статье, будут показаны примеры как для минимального кластера, так и production-ready решения. Они будут разделены по файлам с суффиксами:

simple — для простого кластера,
ha — для отказоустойчивого решения.

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

два Frontend-узла,
три Worker-узла,
один System-узел.

Создание инфраструктуры

При создании инфраструктуры я решил сосредоточиться на повторяемости своих действий. Поэтому меньше действий руками, больше — через утилиты!

Воспользуемся Terraform — стандартом индустрии. Тем более у облака Selectel есть свой terraform provider в актуальном состоянии. Он поможет нам исключительно с PaaS-сервисами, такими как базы, кластера k8s. Для работы с виртуальными машинами и сетью в облаке нам потребуется еще и OpenStack terraform provider. Также у Selectel есть отличный репозиторий с примерами — его мы и будем использовать при создании виртуальной инфраструктуры.

В ходе работ я выяснил, что пример создания проекта с ключом не работает. О чем впоследствии был заведен issue.

Запустим наш проект и получим готовый кластер:

terraform init
env TF_VAR_sel_token=yyy_xxx TF_VAR_user_password=xxx terraform plan
env TF_VAR_sel_token=yyy_xxx TF_VAR_user_password=xxx terraform apply

Подготовка кластера Deckhouse

Теперь, когда мы получили готовый кластер, можно подготовить его к установке Deckhouse. Чтобы провести установку, нам потребуется создать Storage Class для нашего региона. Я собрал все это в один Chart, который:

при первичной установке создает Storage Class для кластера, исходя из зоны,
при повторной установке создает Ingress, Auth provider и другие ресурсы D8.

Скачаем конфигурацию кластера из панели Selectel:

Установим Сhart в кластер:

export KUBECONFIG=~/.kube/d8test.yaml
werf converge --skip-build

Установка Deckhouse

Теперь установим Deckhouse. Вы всегда можете воспользоваться официальной документацией, однако я подготовил готовый конфиг для нашего кластера:

apiVersion: deckhouse.io/v1
kind: InitConfiguration
deckhouse:
  releaseChannel: Alpha
  bundle: Managed
  configOverrides:
    global:
      modules:
        publicDomainTemplate: '%s.d8test.example.com'
      storageClass: "fast.ru-3a"
    certManagerEnabled: true
    deckhouseWebEnabled: true
    chronyEnabled: false
    userAuthnCrdEnabled: true
    userAuthnEnabled: true
    userAuthzEnabled: true
    namespaceConfiguratorEnabled: true
    namespaceConfigurator:
      configurations:
      - annotations:
          extended-monitoring.flant.com/enabled: "true"
        includeNames:
        - "production"
        - "loki-logging"
    dashboard:
      accessLevel: ClusterAdmin
      auth:
        allowScale: true
        externalAuthentication:
          authURL: http://auth.dashboard-auth.svc.cluster.local/_tech/is_auth
          authSignInURL: https://dashboard.d8test.example.com/_tech/auth
          useBearerTokens: true

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

Произведем установку:

docker run --pull=always -it -v "$PWD/config.yml:/config.yml" \
  -v "$HOME/.kube/d8test.yaml:/kubeconfig" registry.deckhouse.io/deckhouse/ce/install:alpha bash
dhctl bootstrap-phase install-deckhouse --kubeconfig=/kubeconfig --config=/config.yml

Deckhouse устанавливается без проблем за 5 минут.

Установим Сhart в кластер еще раз, чтобы развернулись недостающие ресурсы:

export KUBECONFIG=~/.kube/d8test.yaml
werf converge --skip-build

После применения оставшихся ресурсов останется дождаться получения прямого IP нашим кластером:

export KUBECONFIG=~/.kube/d8test.yaml
kubectl –n d8-ingress get svc

После чего потребуется направить на него DNS-запись *.d8test.example.com для компонентов.

Но что мы получим на выходе?

Managed K8S + D8 = ❤

А на выходе — полнофункциональный кластер с мониторингом, cert-manager, Ingress на основе nginx и возможностью сбора логов встроенным агентом на базе Vector.

Конечно, не обошлось и без ложки дегтя. Так как control plane контролирует Selectel, у нас нет возможности настроить multitenancy или же сконфигурировать Dex как OIDC-провайдер. Итого, что не работает:

Периодически отваливается сбор логов с ошибкой версии объекта:
Watcher Stream received an error. Retrying. error=WatchError (ErrorResponse { status: «Failure», message: «too old resource version: 114794284 (114797507)», reason: «Expired», code: 410 }).
Нет авторизации в Kubernetes API через Dex.
Не работает incluster VPN.

К счастью, это можно обойти. В Dashboard есть возможность внешней авторизации — именно ее я и использовал, сделав специальный Chart c nginx, который возвращает в Dashboard token. Установить его можно командой werf converge.

С логами я разобрался аналогичным образом — создав Chart, который раз в час перезапускает поды.

Документация по обоим чартам находится в связанных репозиториях.

Продолжим погружение

Чего же нам не хватает для полной утилизации инфраструктуры Selectel? Конечно же, быстрой сборки и доставки приложений в новоиспеченный кластер.

На текущий момент ноды кластера Selectel работают на относительно старом образе с Ubuntu 18.04 и ядром четвертой ветки. Это не позволит нам полностью раскрыть werf вкупе с Gitlab Kubernetes runner. По имеющейся у меня информации, вскоре образ для нод будет обновлен. До тех пор сборку будем производить на выделенных виртуальных машинах с Gitlab Runner. Чтобы их настроить, укажите количество раннеров в Terraform. Также потребуется активировать создание bastion хоста. Сами раннеры можно легко сконфигурировать с помощью Ansible. Шаг с установкой werf на Gitlab Runner я намеренно пропускаю, так как он и так отлично расписан в официальной документации.

Когда сборочная инфраструктура будет готова, перейдем к созданию Kubeconfig для работы werf. Можно воспользоваться статьей на сайте Deckhouse.

С начала года Selectel начал предоставлять Container Registry as a Service (CRaaS) в облаке. Это значит, что доставка приложений будет еще быстрее, ведь скачка образов происходит в рамках одной инфраструктуры по быстрым сетям провайдера. Но не все так просто — об этом сервисе мы поговорим отдельно.

werf и CRaaS

Статья писалась продолжительное время, во время бета-тестирования CRaaS. Описанные проблемы были успешно решены с техподдержкой Selectel. В werf добавлены подсказки для работы с Container Registry от Selectel.

Создадим реестр и получим к нему доступ. Подробнее в документации Selectel.

Создадим простейший проект с Pipeline в Gitlab:

variables:
  WERF_REPO: ${SEL_REGISTRY_DOMAIN}/${SEL_REGISTRY}

before_script:
  - type trdl && . $(trdl use werf 1.2 ea)
  - werf version
  - type werf && source $(werf ci-env gitlab --as-file)
  - werf cr login ${SEL_REGISTRY_DOMAIN}

after_script:
  - werf cr logout ${SEL_REGISTRY_DOMAIN}

stages:
  - deploy

.base_deploy:
  stage: deploy
  script:
    - werf converge
  except: [schedules]
  tags: [werf]

Deploy to test:
  extends: .base_deploy
  environment:
    name: test
  when: manual

Deploy to production:
  extends: .base_deploy
  environment:
    name: production
  when: manual

Кроме того, нам потребуются несколько переменных в CI/CD GitLab:

WERF_KUBECONFIG_BASE64 — его мы получили в предыдущем параграфе,
SEL_REGISTRY_DOMAIN со значением cr.selcloud.ru
SEL_REGISTRY c именем реестра — в нашем случае example,
WERF_USERNAME со значением token,
WERF_PASSWORD с токеном, который мы получили из панели Selectel.

На удивление, все заработало сразу и без проблем. Однако на первых порах образы были не оптимизированы и предоставленные в рамках беты бесплатные 20 ГБ довольно быстро закончились. Встал вопрос очистки.

В Pipeline добавился блок очистки, аналогичный представленному в документации werf:

stages:
  - deploy
  - cleanup

.base_clean_up:
  stage: cleanup
  script:
    - werf cleanup
             rules:
             - if: $CI_PIPELINE_SOURCE == "schedule"
               when: always
  tags: [werf]
  resource_group: cleanup

Clean up:
  extends: .base_clean_up

В этот момент стало понятно, что werf не поддерживает очистку данной реализации Registry.

К счастью, это можно исправить. У CRaaS был развитый API, который позволял сделать очистку. API позволяло:

быстро получить список тегов и репозиториев,
сделать очистку образов,
получить токен для доступа к Registry.

Сходу нашлась и проблема, которую можно отнести к проблемам реализации Container Registry от Selectel: werf позволял класть образы в корень репозитория — например, cr.selcloud.ru/example:67a03ef931a263cd83c0fd3dcd7d4468f12d44e13755dad35e3f, но ни API, ни личный кабинет облака не отображали подобные образы. Баг-репорт я отправил в техподдержку Selectel, а в werf добавил подсказку.

К слову, на стороне Selectel сейчас тоже существует проверка:

Мне же в тот момент пришлось пересоздать реестр — других вариантов не было.
Пришлось скорректировать Pipeline, исправив переменную WERF_REPO:

variables:
  WERF_REPO: ${SEL_REGISTRY_DOMAIN}/${SEL_REGISTRY}/${CI_PROJECT_PATH}

Так и появилась первая реализация CRaaS в werf и добавлен раздел в документацию.

На этом приключения не закончились. В реализации были не учтены некоторые вещи:

работа с лимитами на запросы к API,
работа у новых юзеров, у которых нет токенов, — сборка могла выдать ошибку.

Если вторую ошибку можно легко побороть, ведь достаточно поменять работу стадии очистки, то для решения вопроса с лимитами придется отказаться от многопоточности при очистке. Секция очистки станет выглядеть следующим образом:

.base_clean_up:
  stage: cleanup
  variables:
    WERF_PARALLEL: 0
  script:
    - werf cleanup
  rules:
  - if: $CI_PIPELINE_SOURCE == "schedule"
    when: always
  tags: [werf]
  resource_group: cleanup

Добавилась переменная WERF_PARALLEL, которая ограничивают количество одновременных задач. А для беспроблемной работы у новых пользователей появилась вторая реализация, которая учитывала ошибки первой.

Осенью столкнулся с другой бедой — любое удаление образа из Registry приводило к полной блокировке реестра. Пришлось перенастроить работу garbage collector на стороне GitLab, перенеся очистку на глубокую ночь по Москве. Сообщил о проблеме техподдержке Selectel, и они оперативно ее исправили.

Неделю назад CRaaS вышел в коммерческий релиз, что сопровождается обновлением API. Поэтому в разработке третья версия работы с CRaaS для werf. Stay tuned!

Итоговый Pipeline, который я использую у себя в проекте, вы сможете найти на GitHub.

В заключение хочу поблагодарить команду werf (в особенности aigrychev), которые быстро отвечали на вопросы по работе с утилитой, и команду DevShop, с чьего разрешения я и публикую эти наработки.