Управляемый (tenant) Kubernetes

Управляемый Kubernetes в Cozystack

Если вам нужно развернуть собственное контейнеризованное приложение в Cozystack, лучше всего размещать его в управляемом Kubernetes-кластере.

Cozystack разворачивает Kubernetes-as-a-Service и управляет им как самостоятельным приложением внутри изолированной среды каждого тенант. В Cozystack такие кластеры называются тенант-кластерами Kubernetes, а базовый кластер Cozystack — management-кластером или root-кластером. Тенант-кластеры полностью отделены от management-кластера и предназначены для приложений конкретного tenant или приложений, разработанных заказчиком.

Внутри тенант-кластера пользователи могут использовать сервисы LoadBalancer и быстро заказывать persistent volumes по мере необходимости. Control plane работает в контейнерах, а worker nodes разворачиваются как виртуальные машины; всем этим управляет приложение.

Kubernetes version in tenant clusters is independent of Kubernetes in the management cluster. Users can select the supported patch versions from 1.31 to 1.35.

Зачем использовать управляемый Kubernetes-кластер

Kubernetes стал отраслевым стандартом: он предоставляет единый и понятный API, а для конфигурации в основном использует YAML. Благодаря этому команды проще понимают Kubernetes и работают с ним, а управление инфраструктурой становится более предсказуемым.

Kubernetes использует устойчивые архитектурные паттерны и обеспечивает непрерывное восстановление системы в любых сценариях за счёт механизма reconciliation. Кроме того, он позволяет прозрачно масштабироваться на множество серверов и снимает проблемы, характерные для сложных и устаревших API традиционных платформ виртуализации. Управляемый сервис убирает необходимость разрабатывать собственные решения или изменять исходный код, экономя время и усилия.

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

Начало работы

Когда тенант-кластер Kubernetes готов, получите kubeconfig для работы с ним. Это можно сделать через UI или запросом kubectl:

• Откройте дашборд Cozystack, переключитесь в свой тенант, найдите и откройте страницу приложения. Скопируйте один из config-файлов из раздела Secrets.

• Выполните следующую команду, используя kubeconfig management-кластера:

  kubectl get secret -n tenant-<name> kubernetes-<clusterName>-admin-kubeconfig -o go-template='{{ printf "%s\n" (index .data "admin.conf" | base64decode) }}' > admin.conf
  

Доступно несколько вариантов kubeconfig:

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

Детали реализации

Тенант-кластер Kubernetes в Cozystack по сути является Kubernetes-in-Kubernetes. При его развертывании используются следующие компоненты:

• Kamaji Control Plane: Kamaji — open-source проект, который упрощает развертывание Kubernetes control planes в виде pod внутри root-кластера. Каждый control plane pod включает базовые компоненты вроде kube-apiserver, controller-manager и scheduler, что помогает эффективно использовать multi-tenancy и ресурсы.

• Etcd Cluster: A dedicated etcd cluster is deployed using the cozystack etcd-operator (etcd-operator.cozystack.io/v1alpha2). It provides reliable and scalable key-value storage for the Kubernetes control plane.

• Worker Nodes: виртуальные машины создаются через KubeVirt и используются как worker nodes. Эти ноды настроены на присоединение к тенант-кластеру Kubernetes, что позволяет разворачивать workload и управлять ими. Диски worker нод автоматически определяют размер блока базового тома и подстраиваются под него (blockSize.matchVolume), чтобы обеспечить совместимость с backend-системами хранения данных, которые используют секторы не по 512 байт, например LINSTOR DRBD с 4Kn-дисками.

• Cluster API: Cozystack использует Kubernetes Cluster API для подготовки компонентов кластера.

Такая архитектура обеспечивает изолированные, масштабируемые и эффективные тенант-среды Kubernetes.

Справочные материалы по компонентам, которые используются в этом сервисе:

• Kamaji Control Plane
• Kamaji — Cluster API
• github.com/clastix/kamaji
• KubeVirt
• github.com/kubevirt/kubevirt
• github.com/cozystack/etcd-operator
• Kubernetes Cluster API
• github.com/kubernetes-sigs/cluster-api-provider-kubevirt
• github.com/kubevirt/csi-driver

Изменения, нарушающие обратную совместимость

• ephemeralStorage переименовано в diskSize (v1.4): поле nodeGroups[name].ephemeralStorage было переименовано в nodeGroups[name].diskSize. Существующие кластеры прозрачно мигрируются платформенной миграцией 41 во время pre-upgrade хука — никаких ручных действий не требуется. Новые значения следует записывать в diskSize. Существующие ВМ обновляются поочерёдно (rolling-update) через CAPI при применении новых значений. С переходом воркеров на Talos в этом релизе поле теперь задаёт размер единственного системного диска (образ ОС Talos, потоково загружаемый с factory.talos.dev, состояние kubelet, кэш образов containerd, локальные PVC local-path) — макет с disk-kubelet PVC, использовавшийся до Talos, был удалён. Состояние на этом единственном диске сохраняется при перезапусках одной и той же ВМ (перезапуск virt-launcher, перезагрузка гостевой ОС, сбой узла); при замене ВМ через CAPI (например, изменение поля nodeGroup, устранение неисправности через MachineHealthCheck) выделяется новый диск.

• Изолированные (air-gapped) воркеры тенантов (Фаза 1 перехода на Talos): загрузка воркеров тенантов переходит с Ubuntu containerDisk + kubeadm на образ диска Talos OS, получаемый по HTTP через CDI, и ссылку на инсталлятор вида .../installer/.... Оба источника теперь можно переопределить — задайте talos.imageFactoryURL (по умолчанию https://factory.talos.dev) на самостоятельно размещённую Image Factory, кэширующее зеркало или внутренний HTTP-файловый сервер, а talos.installerRepository (по умолчанию factory.talos.dev/installer) — на зеркалированный реестр. Секрет *-patch-containerd, рендерящийся через Helm, который ранее передавал платформенную конфигурацию registries.mirrors воркерам тенантов (через монтирование сертификатов containerd certs.d в шаблоне kubeadm), не имеет потребителя в machineconfig Talos и был удалён в этом релизе; загрузка образов контейнеров внутри гостевой системы (поды, скачивающие образы из реестров внутри кластера тенанта) до сих пор не поддерживает переопределение registries.mirrors на уровне тенанта — это будет восстановлено в Фазе 2 через параметры machine.registries.mirrors. Таким образом тенант со строгим egress теперь может зеркалировать образ Talos OS и инсталлятор, но ограниченные по скорости загрузки образов реестра внутри гостевой системы остаются задачей Фазы 2 — заведите issue, если это вам необходимо, а функциональность ещё не реализована.

• Устранение неисправностей воркеров через MachineHealthCheck включено по умолчанию (Фаза 1 перехода на Talos): параметр maxUnhealthy в MHC для воркеров изменился с жёстко заданного 0 (устранение неисправностей фактически было отключено) на настраиваемый nodeHealthCheck.maxUnhealthy со значением по умолчанию "50%". Теперь CAPI автоматически устраняет неисправности (удаляет и заменяет) неисправные Machine воркеров, пока хотя бы 50% группы остаётся исправным. Значение "50%" намеренно оставляет запас для временно неисправных узлов во время перехода с kubeadm на Talos и медленной первой загрузки с factory.talos.dev; установите nodeHealthCheck.maxUnhealthy: "0%", чтобы сохранить прежнее поведение с отключённым устранением неисправностей, до тех пор пока ваш парк узлов не стабилизируется на воркерах Talos.

• Управляемые через GitOps ресурсы Kubernetes тенантов должны обновить spec.version в Git (Фаза 1 перехода на Talos): платформенная миграция 46 патчит существующие объекты kuberneteses.apps.cozystack.io с v1.30 на v1.31 (версия v1.30 вышла из матрицы поддержки Talos↔Kubernetes). Когда ресурс Kubernetes тенанта реконсилируется из Git (Flux/Argo), следующая реконсиляция источника повторно применяет version: v1.30 поверх патча миграции 46, что затем срабатывает на защите _versions.tpl чарта, и HelmRelease завершается с ошибкой. Обновите spec.version до v1.31 (или новее) в вашем Git-источнике до или вместе с обновлением платформы. Тенанты, управляемые через API или дашборд, не требуют никаких действий — миграция 46 обрабатывает их автоматически.

• StorageClass-ы LINSTOR с удалённым доступом автоматически распространяются на тенантов (v1.5): StorageClass-ы LINSTOR инфраструктурного кластера, у которых linstor.csi.linbit.com/allowRemoteVolumeAccess не равен "false", создаются внутри каждого тенанта под тем же именем (предоставляются через csi.kubevirt.io). Предупреждение при обновлении: удалите любой вручную созданный StorageClass тенанта, чьё имя совпадает с распространяемым инфраструктурным классом (например, самодельный replicated), перед обновлением, иначе распространяемый класс не сможет быть создан, и релиз CSI тенанта не сойдётся. Инфраструктурные классы, которые должны оставаться локальными для узла, должны явно иметь allowRemoteVolumeAccess: "false" — отсутствующая аннотация считается признаком доступности для удалённого доступа. Распространение вычисляется во время рендеринга HelmRelease, поэтому классы, добавленные или удалённые на инфраструктурном кластере после создания тенанта, распространяются только при следующей реконсиляции этого тенанта.

Поле верхнего уровня storageClass помечено в схеме чарта как неизменяемое (immutable) — описание контракта и того, какие потребители его применяют, см. в docs/storage-immutability.md. Поле уровня группы нод nodeGroups[name].storageClass намеренно не помечено неизменяемым: оно необязательное и не имеет значения по умолчанию, поэтому строгое правило self == oldSelf заблокировало бы любую будущую попытку задать его для уже существующей группы нод.

Параметры

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

Application-specific Parameters

Cluster Addons

Конфигурация Kubernetes Control Plane

Talos Worker Image

Node Health Check

OIDC

Parameter examples and reference

resources and resourcesPreset

resources задает явную конфигурацию CPU и memory для каждой реплики. Если значение пустое, применяется preset из resourcesPreset.

resources:
  cpu: 4000m
  memory: 4Gi

resourcesPreset задает именованную конфигурацию CPU и memory для каждой реплики. Эта настройка игнорируется, если задано соответствующее значение resources.

Ресурсы типа инстанса

В Cozystack доступны следующие ресурсы для типов инстансов:

Резервирование ресурсов Kubelet

Каждая группа нод поддерживает объект kubelet, который задает, сколько памяти и CPU kubelet резервирует для host OS и Kubernetes/system компонентов, работающих на worker ноде.

Если systemReservedMemory или kubeReservedMemory оставлены пустыми, они вычисляются автоматически по следующей формуле:

1. Определяется эффективный объем памяти ноды:
   • Если resources.memory задан явно, используется это значение.
   • Иначе ищется instanceType и используется его значение memory.guest.
   • Если недоступно ни то ни другое, используется минимальная резервация (256Mi).
2. Вычисляется 5% от эффективного объема памяти (в MiB, с округлением вниз).
3. Результат ограничивается диапазоном [256Mi, 1Gi]:
   • Ноды с 5 GiB или меньше получают минимальный резерв 256Mi.
   • Ноды с 20 GiB или больше получают максимальный резерв 1Gi.

По умолчанию systemReservedMemory и kubeReservedMemory получают одинаковое автоматически вычисленное значение.

CPU резервирование (systemReservedCpu, kubeReservedCpu) работают по той же схеме: 5% от effective CPU с ограничением диапазоном [50m, 500m]. Оба значения вычисляются автоматически, если оставлены пустыми.

Значения kubelet по умолчанию

Порог вытеснения можно задавать в процентах (например, 7%) или абсолютных значениях (например, 200Mi). Оба порога должны использовать один тип единиц. Жёсткий порог вытеснения должен быть строго меньше мягкого порога.

Параметры evictionSoftGracePeriod и evictionMinimumReclaim сейчас жёстко заданы в шаблоне и не могут быть переопределены через values.

Capacity Аннотации

Когда настроены резервации ресурсов kubelet, аннотации capacity.cluster-autoscaler.kubernetes.io/memory и capacity.cluster-autoscaler.kubernetes.io/cpu на MachineDeployments показывают распределяемые значения вместо полных ресурсов ноды. Доступная для подов память вычисляется как общий объём памяти за вычетом system-reserved, kube-reserved и eviction-hard. Доступное для подов CPU вычисляется как общее количество за вычетом system-reserved и kube-reserved. Так аннотации соответствуют значениям, которые cluster autoscaler использует в расчетах масштабирования.

При обновлении с версии без этой возможности autoscaler после обновления аннотации может увидеть уменьшенную капасити для каждой ноды, что способно запустить дополнительные операции scale-up. Обычно никаких действий не требуется — новые значения отражают фактическую память, доступную для scheduling workload.

Note: Если не задан ни resources.memory, ни instanceType, порог вытеснения (по умолчанию 7% hard / 10% soft) все равно применяются kubelet во время выполнения, но capacity аннотации не рендерится. Без этой аннотации cluster-autoscaler не учитывает эти резервации и может запланировать на ноду слишком много подов, что приведёт к срабатыванию вытеснения.

Пример: переопределение резерваций kubelet

nodeGroups:
  md0:
    instanceType: "u1.large"
    kubelet:
      systemReservedMemory: "256Mi"
      kubeReservedMemory: "256Mi"
      evictionHardMemory: "500Mi"
      evictionSoftMemory: "1Gi"

Серия U: Universal

Серия U имеет сбалансированный профиль и предоставляет ресурсы для приложений общего назначения.

U — сокращение от “Universal”, то есть серия рассчитана на универсальные рабочие нагрузки.

VM этих типов инстансов делят физические CPU-ядра с другими VM по принципу разделения процессорного времени.

Характеристики серии U

Особенности этой серии:

• Burstable CPU performance - рабочая нагрузка имеет базовый уровень вычислительной производительности, но может кратковременно превышать его при наличии свободных вычислительных ресурсов.
• vCPU-To-Memory Ratio (1:4) - соотношение vCPU к memory 1:4, чтобы снизить уровень шума на каждой ноде.

Серия O: Overcommitted

Серия O основана на серии U; единственное отличие — избыточное выделение памяти.

O — сокращение от “Overcommitted”.

Характеристики Серии O

Особенности этой серии:

• Burstable CPU performance - рабочая нагрузка имеет базовый уровень вычислительной производительности, но может кратковременно превышать его при наличии свободных ресурсов хоста.
• Overcommitted Memory - память используется с избытком, чтобы получить более высокую плотность размещения рабочей нагрузки.
• vCPU-To-Memory Ratio (1:4) - соотношение vCPU к memory 1:4, чтобы снизить уровень шума каждой ноды.

Серия CX: Compute Exclusive

Серия CX предоставляет выделенные вычислительные ресурсы для приложений с высокой нагрузкой на CPU.

CX — сокращение от “Compute Exclusive”.

Выделенные ресурсы предоставляются вычислительным потокам виртуальной машины. Чтобы это обеспечить, запрашиваются дополнительные ядра (в зависимости от количества дисков и NIC), которые разгружают IO потоки с ядрами, выделенных под рабочие нагрузки. Кроме того, в этой серии топологии NUMA используемых ядер передается в VM.

Характеристики серии CX

Особенности этой серии:

• Hugepages - hugepages используются для повышения производительности памяти.
• Dedicated CPU - физические ядра эксклюзивно назначаются каждому vCPU, чтобы дать рабочей нагрузки фиксированные и высокие гарантии вычислительной мощности.
• Isolated emulator threads - потоки эмулятора гипервизора изолируются от vCPU, чтобы снизить влияние эмуляции на рабочую нагрузку.
• vNUMA - физическая топология NUMA отражается внутри гостевой VM, чтобы оптимизировать использование кеша на стороне гостевой VM.
• vCPU-To-Memory Ratio (1:2) - соотношение vCPU к memory 1:2.

Серия M: Memory

Серия M предоставляет ресурсы для приложений с высокой нагрузкой на память.

M — сокращение от “Memory”.

Характеристики серии M

Особенности этой серии:

• Hugepages - hugepages используются для повышения производительности памяти.
• Burstable CPU performance - рабочая нагрузка имеет базовый уровень вычислительной производительности, но может кратковременно превышать его при наличии свободных ресурсов хоста.
• vCPU-To-Memory Ratio (1:8) - соотношение vCPU к memory 1:8, чтобы заметно снизить уровень шума каждой ноды.

Серия RT: RealTime

Серия RT предоставляет ресурсы для приложений реального времени, например Oslat.

RT — сокращение от “realtime”.

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

Характеристики серии RT

Особенности этой серии:

• Hugepages - hugepages используются для повышения производительности памяти.
• Dedicated CPU - физические ядра эксклюзивно назначаются каждому vCPU, чтобы дать рабочей нагрузки фиксированные и высокие гарантии вычислительной мощности.
• Isolated emulator threads - потоки эмулятора гипервизора изолируются от vCPU, чтобы снизить влияние эмуляции на рабочую нагрузку.
• vCPU-To-Memory Ratio (1:4) - соотношение vCPU к memory 1:4 начиная с размера medium.