5. Развёртывание управляемых приложений, ВМ и Kubernetes-кластера tenant'а

Цели

Это руководство поможет вам подготовить окружение для запуска типичного веб-приложения с распространёнными сервисными зависимостями — PostgreSQL и Redis — в Cozystack, PaaS-платформе на базе Kubernetes.

Вы научитесь:

• Развёртывать управляемые приложения в своём tenant’е: базу данных PostgreSQL и кэш Redis.
• Создавать управляемый Kubernetes-кластер, настраивать DNS и получать доступ к кластеру.
• Развёртывать контейнеризованное приложение в новом кластере.

Для прохождения этого руководства вам не нужны глубокие знания Kubernetes — большая часть шагов выполняется через веб-интерфейс Cozystack.

Это быстрый способ выполнить первое успешное развёртывание в Cozystack. После завершения у вас будет рабочее окружение для собственных приложений и надёжная база, на которую можно опираться и показывать команде.

Предварительные требования

Перед началом:

• Кластер Cozystack уже должен быть установлен и работать. На уровне инфраструктуры ничего устанавливать или настраивать не потребуется — это руководство предполагает, что эта часть уже сделана вами или кем-то из вашей команды.
• Tenant и учётные данные: у вас должен быть доступ к своему tenant’у в Cozystack. Это может быть либо kubeconfig, либо вход в дашборд через OIDC. Если доступа нет, обратитесь к своей Ops-команде или воспользуйтесь руководством по созданию tenant’а.
• DNS для dev/test: чтобы открыть развернутое приложение по HTTPS, нужно заранее настроить DNS-запись. Предпочтительнее использовать wildcard-запись, так как это удобнее.

🛠️ CLI необязателен. Использовать kubectl или helm необязательно. Все основные шаги, включая создание Kubernetes-кластера и управляемых сервисов, можно полностью выполнить через дашборд Cozystack. CLI понадобится только на этапе развёртывания приложения в Kubernetes-кластере.

1. Вход в дашборд Cozystack

Откройте дашборд Cozystack в браузере. Обычно ссылка выглядит так: https://dashboard.<cozystack_domain>.

В зависимости от того, как в вашем кластере Cozystack настроена аутентификация, вы увидите один из следующих вариантов:

• Экран входа через OIDC с кнопкой, которая перенаправляет в Keycloak.
• Экран входа по токену, где нужно вручную вставить токен из файла kubeconfig.

Выберите подходящий способ входа:

• OIDC
• kubeconfig

После входа дашборд автоматически откроется в контексте вашего tenant’а.

Вы можете увидеть уже работающие системные приложения, например ingress или monitoring — ими управляет администратор кластера. Как пользователь tenant’а вы не можете устанавливать или изменять их, но ваши собственные приложения будут работать рядом с ними в изолированном tenant-окружении.

2. Создание управляемого PostgreSQL

Cozystack позволяет разворачивать управляемые базы данных прямо на уровне оборудования для максимальной производительности. Каждая база создаётся внутри namespace tenant’а и автоматически доступна из вашего вложенного Kubernetes-кластера.

Если вы знакомы с сервисами вроде AWS RDS или GCP Cloud SQL, опыт будет похожим — с той разницей, что здесь всё полностью интегрировано в Cozystack и изолировано внутри вашего tenant’а.

По ходу этого руководства вы сможете выбирать между дашбордом Cozystack (UI) и kubectl:

• Дашборд Cozystack — самый быстрый и простой вариант, особенно если вы впервые работаете с Cozystack.
• kubectl даёт более глубокое понимание того, как управляемые сервисы разворачиваются под капотом.

Хотя ни один из этих подходов не отражает типичный production-процесс развёртывания сервисов, оба хорошо подходят для обучения и экспериментов, поэтому отлично подходят для этого руководства.

2.1 Развёртывание PostgreSQL

• Дашборд Cozystack
• kubectl

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: postgres-instaphoto-dev
  namespace: tenant-team1
spec:
  chart:
    spec:
      chart: postgres
      reconcileStrategy: Revision
      sourceRef:
        kind: HelmRepository
        name: cozystack-apps
        namespace: cozy-public
      version: 0.10.0
  interval: 0s
  values:
    databases:
      myapp:
        roles:
          admin:
            - user1
    external: true
    replicas: 2
    resourcesPreset: nano
    size: 5Gi
    users:
      user1:
        password: strongpassword

kubectl apply -f postgres.yaml

2.2 Получение параметров подключения

Перейдите на вкладку Applications, затем найдите и откройте приложение instaphoto-postgres. После установки и готовности приложения параметры подключения появятся в разделе Application Resources в дашборде.

• На вкладке Secrets находятся пароли базы данных для каждого созданного вами пользователя.
• На вкладке Services перечислены внутренние сервисные endpoints:
  • Используйте postgres-<name>-ro для подключения к read-only replica.
  • Используйте postgres-<name>-rw для подключения к primary (read-write) инстансу.

Эти имена сервисов резолвятся изнутри вложенного Kubernetes-кластера и могут использоваться в конфигурации вашего приложения.

Если нужно подключаться к базе данных извне кластера, можно включить внешнюю публикацию, установив параметр external в true. Это создаст сервис postgres-<name>-external-write с публичным IP-адресом.

⚠️ Включайте внешний доступ только при реальной необходимости. Публикация баз данных в интернет повышает риски безопасности и в большинстве случаев её следует избегать.

3. Создание сервиса кэширования

Начиная с этого момента, для доступа к платформе используйте учётные данные tenant’а. Для kubectl используйте kubeconfig tenant’а, а для входа в дашборд — токен из него.

• Дашборд Cozystack
• kubectl

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis-instaphoto
  namespace: tenant-team1
spec:
  chart:
    spec:
      chart: redis
      reconcileStrategy: Revision
      sourceRef:
        kind: HelmRepository
        name: cozystack-apps
        namespace: cozy-public
      version: 0.6.0
  interval: 0s
  values:
    authEnabled: true
    external: false
    replicas: 2
    resources: {}
    resourcesPreset: nano
    size: 1Gi

kubectl apply -f redis.yaml

Через некоторое время приложение Redis будет установлено в tenant team1. Сгенерированный пароль можно посмотреть в дашборде.

• Дашборд Cozystack
• kubectl

# Используйте kubeconfig tenant'а
export KUBECONFIG=./kubeconfig-tenant-team1
# Получите пароль
kubectl -n tenant-team1 get secret redis-instaphoto-auth

4. Развёртывание вложенного Kubernetes-кластера

Вложенный Kubernetes-кластер создаётся так же, как база данных и кэш. Однако здесь есть несколько важных дополнительных моментов:

• В tenant’е должен быть включён etcd
  Сервис etcd обязателен для запуска вложенного Kubernetes-кластера и может быть включён только администратором Cozystack.
• Проверьте свою квоту.
  Убедитесь, что в tenant’е достаточно CPU, RAM и дисковых ресурсов для создания и работы кластера.
• Выберите подходящий пресет инстанса.
  Избегайте слишком маленьких пресетов. Один узел Kubernetes потребляет примерно 2.5 ГБ RAM только на системные компоненты. Например, если выбрать пресет с 4 ГБ RAM, под реальные рабочие нагрузки останется около 1.5 ГБ. Для тестов 4 ГБ достаточно, но в целом лучше выделить меньше узлов с большим объёмом памяти, чем много узлов с минимальной RAM.
• При необходимости включите ingress и cert-manager.
  Если вы планируете развёртывать веб-приложения, почти наверняка понадобятся ingress и управление сертификатами. Оба параметра можно включить флажками при настройке приложения вложенного Kubernetes в Cozystack.

Когда вложенный Kubernetes-кластер будет готов, его kubeconfig-файлы появятся на вкладке Secrets на странице приложения в дашборде. Будут доступны несколько вариантов:

• admin.conf — стандартный kubeconfig для доступа к новому кластеру. С его помощью можно создавать дополнительных пользователей Kubernetes.
• admin.svc — тот же токен, что и в admin.conf, но адрес API server указывает на внутреннее имя сервиса. Используйте его для приложений, которым нужен доступ к API изнутри кластера.
• super-admin.conf — аналог admin.conf, но с расширенными административными правами. Предназначен для диагностики и задач обслуживания кластера.
• super-admin.svc — то же, что и super-admin.conf, но с внутренним адресом API server.

5. Обновление DNS и доступ к кластеру

После развёртывания вложенный Kubernetes-кластер автоматически получит один из floating IP-адресов основного кластера.

Узнать назначенное DNS-имя и IP-адрес можно двумя способами:

• Откройте страницу приложения кластера в дашборде.
• Проверьте статус ingress через kubectl.

После того как вы узнаете правильные DNS-имя и IP-адрес, обновите DNS-настройки так, чтобы ваш домен или поддомен указывал на этот IP.

После обновления и распространения DNS-записей вы сможете подключиться к вложенному Kubernetes-кластеру с помощью скачанного kubeconfig.

Пример настройки и использования:

1. Сохраните содержимое admin.conf в файл, например ~/.kube/kubeconfig-team1.example.org:

   $ cat ~/.kube/kubeconfig-team1.example.org
   apiVersion: v1
   clusters:
   - cluster:
       certificate-authority-data: LS0tL
       ...
   

2. Укажите этот файл в переменной окружения KUBECONFIG и убедитесь, что узлы готовы:

   $ export KUBECONFIG=~/.kube/kubeconfig-team1.example.org
   $ kubectl get nodes
   NAME                             STATUS   ROLES           AGE   VERSION
   kubernetes-dev-md0-vn8dh-jjbm9   Ready    ingress-nginx   29m   v1.30.11
   kubernetes-dev-md0-vn8dh-xhsvl   Ready    ingress-nginx   25m   v1.30.11
   

6. Развёртывание приложения с помощью Helm

Начиная с этого момента, работа с вашим кластером ничем не отличается от работы с обычным Kubernetes-окружением.

Для развёртывания Kubernetes-native приложений можно использовать kubectl, helm или ваш CI/CD pipeline.

Чтобы развернуть приложение:

1. Обновите значения Helm chart, указав корректные учётные данные для базы данных и кэша.

2. Выполните обычную команду Helm для развёртывания, например:

   helm upgrade --install <release-name> <chart-path> -f values.yaml
   

Имена сервисов, например базы данных и кэша, не требуют DNS-суффиксов. В пределах одного namespace к ним можно обращаться напрямую по имени сервиса.