K3s on-prem Kubernetes становится управляемым через декларативный подход k0rdent и BYOT. Разбираем, как собрать воспроизводимый кластер без скриптов и ручной сборки.
Проблема проявляется не сразу — до момента, когда on-prem Kubernetes начинает масштабироваться. Кластеры, собранные вручную, теряют воспроизводимость. Любое изменение требует скриптов или ручной настройки. В таких условиях растёт стоимость сопровождения и падает предсказуемость системы. Особенно это заметно в средах, где нет готовых managed-решений и приходится опираться на Proxmox или аналогичную инфраструктуру.
В этом кейсе выбрали связку K3s on-prem Kubernetes + k0rdent + Proxmox. Основная идея — перейти от императивного управления к декларативному. Вместо описания шагов система получает описание желаемого состояния. k0rdent берёт на себя reconciliation loop и следит за соответствием. Это компромисс: больше начальной настройки, но существенно меньше ручной работы в долгосрочной перспективе. K3s здесь выступает как облегчённый дистрибутив Kubernetes, оптимизированный под on-prem и edge.
Архитектура выстроена послойно. Поток выглядит так: пользователь задаёт состояние через k0rdent, далее создаются виртуальные машины в Proxmox через BYOT (Bring Your Own Template), затем подключаются Control Plane Provider и Bootstrap Provider для K3s. Каждый слой решает одну задачу. Это снижает связанность (coupling) и упрощает отладку.
Ключевой момент — отсутствие нативного провайдера Proxmox в k0rdent. Вместо этого был реализован собственный Infrastructure Provider через Helm chart. Он отвечает только за создание VM. Kubernetes-логика в него не добавляется. Такой разрыв ответственности делает систему прозрачной: инфраструктура и оркестрация не смешиваются.
В реализации использовались заранее подготовленные шаблоны виртуальных машин в Proxmox. В них уже включены cloud-init, SSH-доступ и базовые пакеты. Это убирает необходимость собирать образы при каждом provisioning. В результате ускоряется запуск и уменьшается количество точек отказа. Но есть trade-off: нужно поддерживать актуальность шаблонов вручную.
После создания VM управление переходит к Control Plane Provider. Он назначает роли нод и формирует control plane. Здесь важно, что роли задаются декларативно. Кластер становится предсказуемым: каждая нода имеет чётко определённую функцию. Это снижает риск конфигурационных ошибок, которые часто возникают при ручной сборке.
Bootstrap Provider отвечает за установку K3s. Он управляет жизненным циклом кластера: установка, обновление, конфигурация. K3s выбран из-за минимальных зависимостей и быстрой установки. Это особенно важно для on-prem, где ресурсы и сеть могут быть ограничены.
После завершения всех этапов система входит в режим постоянной сверки состояния (reconciliation). Если что-то отклоняется от декларации, k0rdent исправляет это автоматически. Это ключевое отличие от традиционного подхода, где drift остаётся незамеченным до инцидента.
Результат — полностью декларативный K3s on-prem Kubernetes кластер. Масштабирование больше не требует ручной подготовки. Пересоздание кластера становится повторяемой операцией. Однако в исходных данных нет количественных метрик по времени развертывания или снижению ошибок, поэтому оценка остаётся качественной.
Важно отметить, что подход BYOT делает систему гибкой. Если инфраструктура не поддерживается из коробки, её можно интегрировать через шаблоны и Helm. Это расширяет применимость, но требует инженерной дисциплины: ошибки в шаблонах напрямую влияют на весь кластер.
В индустрии подобный переход к декларативному управлению давно обсуждается. Но в on-prem средах он реализуется сложнее из-за отсутствия стандартных провайдеров. В этом смысле связка k0rdent, Proxmox и K3s выглядит как прагматичный путь к унификации управления инфраструктурой.