Дистрибутив Kubernetes отдельно от облака
Выбор дистрибутива не должен быть заодно выбором поставщика. Talos по умолчанию, upstream из штатных компонентов или облегчённый дистрибутив — локально и в любом облаке.
Обычно выбор облака и выбор Kubernetes — одно решение. Взяли управляемый сервис поставщика, получили его версию, его сетевой плагин, его модель обновлений и его способ доступа к узлам.
Это удобно ровно до момента, когда надо уехать. Тогда обнаруживается, что уезжает не только машина, но и весь способ работы с кластером.
Производственный трек разделяет эти решения.
Что можно выбрать
По умолчанию — Talos Linux: неизменяемая операционная система, управляемая по API, без SSH и без пакетного менеджера. Для кластера это правильная база: узел нельзя «поправить руками», а значит он не расходится с описанием.
Можно поднять обычный upstream Kubernetes из штатных компонентов: сервер API, контроллер-менеджер, планировщик, kubelet, kube-proxy, плюс etcd и containerd. Это вариант для тех, кому нужен контроль над каждым компонентом или совместимость с существующими процедурами.
Можно взять любой из распространённых облегчённых дистрибутивов.
Локально или в любом облаке — одинаково.
Зачем это нужно на практике
Первое: воспроизводимость стенда. Локальный кластер и производственный на одном дистрибутиве ведут себя одинаково. Отладка «у меня работает, в облаке нет» перестаёт начинаться с вопроса, какая там версия.
Второе: переезд перестаёт быть переписыванием. Если кластер — это Talos на виртуальных машинах, то смена облака означает смену того, кто эти машины предоставляет. Манифесты, сетевой плагин, процедуры обновления остаются.
Третье: срок жизни решения. Управляемый сервис поставщика меняется по расписанию поставщика. Дистрибутив, который вы поднимаете сами, меняется по вашему.
Чем за это платят
Управляемый Kubernetes снимает работу: обновление управляющего слоя, резервное копирование etcd, замену узлов. Поднимая кластер сам, вы берёте эту работу себе.
Это честный обмен, и он не всегда выгоден. Для команды из трёх человек с одним приложением управляемый сервис почти наверняка правильный выбор. Разделение начинает окупаться там, где кластеров больше одного, или где есть требование к размещению, или где переезд — не гипотеза.
Высокая доступность в том же описании
Количество управляющих и рабочих узлов задаётся параметрами конфигурации проекта. То есть переход от одноузлового стенда к отказоустойчивому кластеру — правка описания, а не другой инструмент и не другая процедура.
Для многомашинной сборки есть отдельная пошаговая инструкция. Мы упоминаем это, потому что «поддерживается конфигурацией» и «есть проверенная процедура» — разные уровни готовности, и их стоит различать.
Кто владеет нагрузками
Отдельно от дистрибутива: на производственном треке всеми нагрузками владеет ArgoCD, а жизненным циклом кластера — Cluster API. Инструмент выступает дирижёром.
Это означает, что смена дистрибутива не затрагивает способ доставки приложений. Границы между слоями — инфраструктура, сервисы, край — не перекрываются, и это правило, а не сложившаяся практика.