Справочник по приложению Tenant

Тенант — это основная единица безопасности на платформе. Ближайшая аналогия — пространства имён ядра Linux.

Тенанты могут создаваться рекурсивно и подчиняются следующим правилам:

Именование тенантов

Имена тенантов должны быть буквенно-цифровыми:

• Только строчные буквы (a-z) и цифры (0-9)
• Должны начинаться со строчной буквы
• Дефисы (-) не допускаются, в отличие от других сервисов
• Максимальная длина зависит от конфигурации кластера (префикс Helm-релиза и корневой домен)

Это ограничение существует для поддержания согласованного именования в тенантах, вложенных тенантах и развёрнутых в них сервисах. Тенант нельзя назвать foo-bar, потому что разбор внутренних имён ресурсов вроде tenant-foo-bar был бы неоднозначным.

Например:

• Корневой тенант называется root, но внутри он обозначается как tenant-root.
• Вложенный тенант может называться foo, что даст tenant-foo в именах сервисов и URL.

Уникальные домены

Каждый тенант имеет собственный домен. По умолчанию (если не указано иное) он наследует домен своего родителя с префиксом из своего имени. Например, если у родителя был домен example.org, то tenant-foo по умолчанию получит домен foo.example.org.

Кластеры Kubernetes, созданные в пространстве имён этого тенанта, получат домены вида: kubernetes-cluster.foo.example.org

Пример:

tenant-root (example.org)
└── tenant-foo (foo.example.org)
    └── kubernetes-cluster1 (kubernetes-cluster1.foo.example.org)

Вложенность тенантов и переиспользование родительских сервисов

Тенанты могут быть вложенными. Администратор тенанта может создавать вложенные тенанты с помощью приложения «Tenant» из каталога.

Тенанты более высокого уровня могут просматривать приложения всех своих дочерних тенантов и управлять ими. Если тенант не запускает собственные кластерные сервисы, он может использовать сервисы своего родителя.

Например, вы создаёте:

• Тенант tenant-u1 с набором сервисов, таких как etcd, ingress, monitoring.
• Тенант tenant-u2, вложенный в tenant-u1.

Посмотрим, что произойдёт, когда вы запустите Kubernetes и Postgres в пространстве имён tenant-u2.

Поскольку у tenant-u2 нет собственных кластерных сервисов, таких как etcd, ingress и monitoring, приложения, работающие в tenant-u2, будут использовать кластерные сервисы родительского тенанта.

Это, в свою очередь, означает:

• Данные кластера Kubernetes будут храниться в etcd тенанта tenant-u1.
• Доступ к кластеру будет осуществляться через общий ingress тенанта tenant-u1.
• По сути, все метрики будут собираться в monitoring тенанта tenant-u1, и только этот тенант будет иметь к ним доступ.

Пример:

tenant-u1
├── etcd
├── ingress
├── monitoring
└── tenant-u2
    ├── kubernetes-cluster1
    └── postgres-db1

Параметры

Общие параметры

Конфигурация

Квоты ресурсов

Параметр resourceQuotas позволяет ограничить ресурсы, доступные тенанту. Поддерживаемые ключи:

Вычислительные ресурсы (преобразуются в requests.X и limits.X):

• cpu — Суммарное число ядер CPU (например, "4" или "500m")
• memory — Суммарный объём памяти (например, "4Gi" или "512Mi")
• ephemeral-storage — Лимит эфемерного хранилища (например, "10Gi")
• storage — Суммарный объём постоянного хранилища (например, "100Gi")

Квоты на количество объектов (передаются как есть):

• pods — Максимальное число подов
• services — Максимальное число сервисов
• services.loadbalancers — Максимальное число сервисов типа LoadBalancer
• services.nodeports — Максимальное число сервисов типа NodePort
• configmaps — Максимальное число ConfigMap
• secrets — Максимальное число Secret
• persistentvolumeclaims — Максимальное число PVC

Пример:

resourceQuotas:
  cpu: 4
  memory: 4Gi
  storage: 10Gi
  services.loadbalancers: "3"
  pods: "50"