Множественные инстансы одного пакета

Что нужно знать перед уроком

M5 урок 6 — Application как namespace-scoped установленный инстанс одной версии пакета. Здесь — что происходит, когда один и тот же пакет нужно установить несколько раз.

Теория

Официальный пример: два инстанса Redis

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: redis-cache
  namespace: team-alpha
spec:
  packageName: redis
  packageRepositoryName: my-registry
  packageVersion: "v7.2.0"
  settings:
    maxmemory: "512mb"
---
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: redis-sessions
  namespace: team-alpha
spec:
  packageName: redis
  packageRepositoryName: my-registry
  packageVersion: "v7.2.0"
  settings:
    maxmemory: "128mb"

Один и тот же пакет (redis, одна и та же версия v7.2.0) устанавливается дважды в одном и том же namespace team-alpha, но как два независимых Application с разными именами (redis-cache/redis-sessions) и, что важно, разными настройками (maxmemory) под разные бизнес-задачи — один инстанс используется как кэш приложения, другой — для хранения сессий, у каждого свои требования к объёму памяти.

Изоляция ресурсов между инстансами

Благодаря конвенции именования из M5 урока 4 ({{ .Application.Instance.Name }}-<component>), ресурсы двух инстансов не конфликтуют между собой даже в одном namespace: redis-cache-deployment/redis-cache-service и redis-sessions-deployment/redis-sessions-service — совершенно разные объекты Kubernetes, несмотря на то что они порождены одним и тем же шаблоном одного и того же пакета. Это прямое следствие того, что .Application.Instance.Name — часть контекста шаблона, зависящая от конкретного установленного Application, а не от самого пакета.

Изоляция настроек — каждый инстанс независим

Настройки (spec.settings) каждого Application полностью независимы — изменение maxmemory у redis-cache никак не влияет на redis-sessions, даже если оба ссылаются на один и тот же packageName/packageVersion. Это следует из самой модели: каждый Application — отдельный namespace-scoped объект со своим собственным spec, независимо валидируемым по одному и тому же openapi/config-values.yaml пакета (M5 урок 3), но с разными фактическими значениями.

Практическое применение для Umami

Хотя типичный сценарий Umami — один инстанс на команду/проект, множественные инстансы уместны, например, если разным продуктовым командам одной организации нужна раздельная веб-аналитика (изоляция данных между командами) при этом без необходимости заводить отдельный namespace для каждой — два Application пакета umami в одном namespace с разными hostname в настройках дают такую изоляцию на уровне приложения, а не namespace.

Частые ошибки и подводные камни

• Забыть про изоляцию имён и получить конфликт ресурсов между инстансами. Если шаблон не использует {{ .Application.Instance.Name }} в именах ресурсов, а хардкодит фиксированное имя (например, просто redis-deployment), второй инстанс того же пакета в том же namespace попытается создать ресурс с уже существующим именем — конфликт, который проявится как ошибка на стадии Apply (M4 урок 4).
• Ожидать, что настройки одного инстанса как-то наследуются другим. Каждый Application полностью независим — нет механизма «общих» настроек между инстансами одного пакета, даже в одном namespace.
• Путать множественные инстансы одного пакета с зависимостью от двух разных Module. Это разные концепции: множественные инстансы — про повторную установку одного Application-пакета; зависимость от нескольких модулей (M6 урок 3) — про то, что один Application зависит сразу от нескольких cluster-wide Module.

Практика в кластере

1. Установите два независимых инстанса пакета Umami в одном namespace с разными настройками:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

d8 k apply -n course-m5-umami -f - <<'EOF'
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: umami-product-a
spec:
  packageName: umami
  packageRepositoryName: my-registry
  packageVersion: "v0.1.0"
  settings:
    hostname: "analytics-a.local"
    replicas: 1
---
apiVersion: deckhouse.io/v1alpha1
kind: Application
metadata:
  name: umami-product-b
spec:
  packageName: umami
  packageRepositoryName: my-registry
  packageVersion: "v0.1.0"
  settings:
    hostname: "analytics-b.local"
    replicas: 2
EOF

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

1
2

d8 k get app -n course-m5-umami
d8 k get deployment -n course-m5-umami -l app.kubernetes.io/name=umami

3. Проверьте, что каждый Deployment имеет уникальное имя, содержащее имя своего инстанса, и правильное количество реплик согласно своим настройкам:

1

d8 k get deployment -n course-m5-umami -o custom-columns=NAME:.metadata.name,REPLICAS:.spec.replicas,INSTANCE:.metadata.labels.app\\.kubernetes\\.io/instance

Практика разработки

Практики разработки в этом уроке нет — важно лишь удостовериться, что шаблоны Umami из предыдущих уроков M5 уже используют {{ .Application.Instance.Name }} во всех именах ресурсов (проверено на предыдущем шаге).

Шпаргалка команд урока

1
2

d8 k get app -n <ns>
d8 k get <resource> -n <ns> -l app.kubernetes.io/instance=<instance-name>

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Работа с Application

Статьи и блоги

• Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf — Flant на Habr.
• Готовим Gitea со вкусом werf CI/CD в кластере Deckhouse. Часть 3 — Flant на Habr.
• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.

Книги

• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M5.06 — CRD платформы вокруг Application.
• Следующий урок: M5.08 — Go-хуки Application.
• Конвенция именования ресурсов: M5 урок 4.

✓ Урок пройден — все вопросы самопроверки отвечены верно