AndrewLucky
New member
За последние пару лет я прошёл путь от восторженного изучения всех возможностей Kubernetes до состояния, которое называю усталой эксплуатацией. Когда кластеров становится больше, а ночей меньше, начинаешь ценить не количество CRD, а предсказуемость. В этой статье хочу рассказать, какой минимальный набор реально закрывает задачи небольшой команды и не превращает поддержку во второй проект.
Мой базовый набор выглядит скучно, и это комплимент. Managed-кластер от облака, kubectl для ручных проверок, k9s для быстрого взгляда на поды и логи, Helm для установки типовых зависимостей, ingress-nginx для входа, cert-manager для сертификатов, metrics-server для базовых метрик и External Secrets Operator для секретов. Всё. Этого хватает, чтобы запускать сервисы, обновлять их и не изобретать платформу на каждый чих.
Чего я советую не тащить в первый год: service mesh, сложный GitOps с десятью окружениями, операторы для всего подряд, самописные контроллеры и огромный стек наблюдаемости из двадцати компонентов. Это не значит, что инструменты плохие. Просто они решают проблемы, которых у уставшей команды часто ещё нет. А вот операционные расходы создают сразу.
По рабочим нагрузкам минимум такой: deployment, service, ingress, configmap и secret. Обязательно указывайте requests и limits, иначе планировщик и HPA будут жить в мире фантазий. Liveness и readiness probes нужны не для галочки, а чтобы кластер сам выводил из балансировки сломанные поды. HPA по CPU или памяти спасает от ручного масштабирования, но только если метрики действительно есть.
Секреты — отдельная боль. Я стараюсь не хранить их в Git в открытом виде и не плодить самодельные шифровалки. Внешний секрет-оператор, который тянет значения из облачного хранилища, закрывает большинство сценариев. Конфигурацию лучше держать в ConfigMap и версионировать вместе с манифестами. Если для изменения переменной нужно заходить в кластер руками, значит процесс уже сломан.
Наблюдаемость тоже можно начать с малого. metrics-server для kubectl top, централизованные логи в облаке, пара алертов на недоступность сервиса и заполнение диска. Полноценный Prometheus с Grafana можно добавить позже, когда появятся вопросы, на которые не ответить глазами. Мой главный вывод: Kubernetes — это не цель, а способ доставлять ценность. Чем меньше слоёв между кодом и пользователем, тем спокойнее дежурства.
Если вы тоже устали от бесконечной платформенной инженерии, начните с managed-кластера, Helm, ingress, cert-manager, metrics-server и внешних секретов. Добавляйте остальное только после реальной боли. Такой подход не выглядит модно, зато работает и оставляет время на жизнь. А какой минимальный набор Kubernetes прижился у вас лучше всего, и что вы однажды выкинули из кластера без сожалений?
Мой базовый набор выглядит скучно, и это комплимент. Managed-кластер от облака, kubectl для ручных проверок, k9s для быстрого взгляда на поды и логи, Helm для установки типовых зависимостей, ingress-nginx для входа, cert-manager для сертификатов, metrics-server для базовых метрик и External Secrets Operator для секретов. Всё. Этого хватает, чтобы запускать сервисы, обновлять их и не изобретать платформу на каждый чих.
Чего я советую не тащить в первый год: service mesh, сложный GitOps с десятью окружениями, операторы для всего подряд, самописные контроллеры и огромный стек наблюдаемости из двадцати компонентов. Это не значит, что инструменты плохие. Просто они решают проблемы, которых у уставшей команды часто ещё нет. А вот операционные расходы создают сразу.
По рабочим нагрузкам минимум такой: deployment, service, ingress, configmap и secret. Обязательно указывайте requests и limits, иначе планировщик и HPA будут жить в мире фантазий. Liveness и readiness probes нужны не для галочки, а чтобы кластер сам выводил из балансировки сломанные поды. HPA по CPU или памяти спасает от ручного масштабирования, но только если метрики действительно есть.
Секреты — отдельная боль. Я стараюсь не хранить их в Git в открытом виде и не плодить самодельные шифровалки. Внешний секрет-оператор, который тянет значения из облачного хранилища, закрывает большинство сценариев. Конфигурацию лучше держать в ConfigMap и версионировать вместе с манифестами. Если для изменения переменной нужно заходить в кластер руками, значит процесс уже сломан.
Наблюдаемость тоже можно начать с малого. metrics-server для kubectl top, централизованные логи в облаке, пара алертов на недоступность сервиса и заполнение диска. Полноценный Prometheus с Grafana можно добавить позже, когда появятся вопросы, на которые не ответить глазами. Мой главный вывод: Kubernetes — это не цель, а способ доставлять ценность. Чем меньше слоёв между кодом и пользователем, тем спокойнее дежурства.
Если вы тоже устали от бесконечной платформенной инженерии, начните с managed-кластера, Helm, ingress, cert-manager, metrics-server и внешних секретов. Добавляйте остальное только после реальной боли. Такой подход не выглядит модно, зато работает и оставляет время на жизнь. А какой минимальный набор Kubernetes прижился у вас лучше всего, и что вы однажды выкинули из кластера без сожалений?