Kubernetes: что хайп замалчивает об операционной стороне
Kubernetes решает реальные задачи на масштабе. Он также создаёт новую операционную поверхность, к которой большинство команд не готовы. Реалистичный взгляд до принятия решения.
Kubernetes так быстро стал ответом по умолчанию на вопрос «как запускать контейнеры», что сам вопрос редко исследуется. Каждый конференционный доклад показывает преимущества. Операционные сложности появляются позже, тихо - в виде инцидентов и инженеров, уходящих из команды, потому что дежурства стали невыносимы.
Я не выступаю против Kubernetes. Я его использую. Я рекомендую его в правильных контекстах. Но «правильные контексты» - фраза, которую стоит воспринимать серьёзно.
Что Kubernetes решает действительно хорошо
Основная ценность искренняя: декларативная конфигурация того, как должны работать ваши нагрузки, автоматическое планирование по кластеру, самовосстановление при сбоях контейнеров и стандартная модель для сети и хранилищ, не зависящая от конкретного облачного провайдера.
На определённом масштабе - много сервисов, много команд, высокая частота деплоев - это окупается существенно. Альтернатива, управление парком серверов самодельными скриптами, не масштабируется и не компонуется.
Вторая ценность - переносимость. Кластер на собственном железе и кластер на управляемом облачном сервисе имеют один и тот же API и одну ментальную модель. Это снижает привязанность, по крайней мере на уровне нагрузок.
Что доклады умалчивают
Сложность Kubernetes не только в первоначальной настройке. Она живёт в постоянных операциях.
Сетевые технологии в Kubernetes - уровень абстракции поверх сети хоста, и когда что-то ломается - а что-то сломается - отладка требует понимания обоих уровней одновременно. CNI-плагины, service mesh если он есть, сетевые политики, ingress-контроллеры: каждый добавляет конфигурационную поверхность и режимы отказов.
Хранилище сложнее вычислений. Стейтфул-нагрузки в Kubernetes требуют постоянных томов, классов хранилищ и понимания того, как бэкенд хранилища ведёт себя при вытеснении или отказе узла. Команды, переносящие базы данных в Kubernetes без опыта в этой области, как правило, обнаруживают граничные случаи во время инцидентов.
Управление сертификатами, RBAC, обработка секретов, обновления версий - каждое является отдельной дисциплиной. Обновление Kubernetes - не однокомандная операция; оно требует тщательной последовательности обновлений control plane и узлов с проверенным планом отката.
Вопрос о кадрах
Честный вопрос перед принятием Kubernetes: у кого в команде есть опыт эксплуатации его в продакшене?
«Эксплуатация» означает: реагировал на инцидент в 2 ночи, диагностировал узел, переставший планировать поды без потери запущенных нагрузок, обновлял кластер без даунтайма и настраивал запросы ресурсов и лимиты в десятках сервисов так, чтобы автомасштабирование работало.
Если ответ «никто, но мы научимся» - это законный выбор, но он должен быть осознанным, с реалистичными сроками и признанием того, что в первый год будут болезненные инциденты, которых более опытная команда избежала бы.
Когда более простая модель - правильная модель
Хорошо настроенная виртуальная машина с менеджером процессов обрабатывает большинство нагрузок до нескольких сотен запросов в секунду. Управляемый контейнерный сервис - тот, что полностью абстрагирует кластер, - обрабатывает среднесложные деплои без полной операционной поверхности Kubernetes.
Kubernetes становится правильным выбором, когда у вас много сервисов с разными профилями масштабирования, когда нужен точный контроль деплоев, когда команда имеет или готова развить операционную экспертизу, и когда стоимость кривой обучения оправдана масштабом работы.
Практическая отправная точка
Если вы впервые оцениваете Kubernetes, используйте управляемый сервис, а не самостоятельно размещённый. Пусть кто-то другой обслуживает control plane. Сосредоточьте обучение команды на конфигурации нагрузок и наблюдаемости. Избегайте стейтфул-нагрузок в кластере до появления опыта со стейтлесс-нагрузками.
Цель - соотнести операционную сложность, которую вы принимаете на себя, с задачей, которую вы реально решаете. Kubernetes - мощный инструмент. Это также одна из наиболее сложных инфраструктурных систем, которые когда-либо запускали многие команды.