Kubernetes

Оркестрация контейнеров с Kubernetes

Kubernetes (K8s) представляет собой open source платформу оркестрации контейнеров, запущенную Google и управляемую Cloud Native Computing Foundation. Она позволяет определять, развертывать и управлять десятками, сотнями или даже тысячами контейнеров через единую панель управления.

В Detartech мы используем Kubernetes для корпоративных проектов, требующих высокой доступности и нулевого простоя. Автоматическая реакция на всплески трафика с помощью Horizontal Pod Autoscaler, оптимизация затрат с помощью пулов узлов. Мы версионируем конфигурации сервисов с помощью Helm chart и создаем декларативные пайплайны развертывания с инструментами GitOps, такими как ArgoCD.

Где Detartech использует Kubernetes?

Мы не считаем Kubernetes обязательной частью каждого проекта. Как написано на странице услуги DevOps и CI/CD, оркестрация является отдельным решением, которое принимается независимо от контейнеризации. Для контейнеров по умолчанию используется Docker, а Kubernetes подключается, когда для этого есть основание: несколько сервисов, потребность в независимом масштабировании или корпоративная облачная политика. Где будет размещение, решает клиент, а не мы. Критерием служит не техническая мода, а то, хватит ли проекту эксплуатационных ресурсов, чтобы поддерживать этот слой.

Когда Kubernetes подходит?

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

Когда Kubernetes не нужен?

Для приложения из одного сервиса с предсказуемым трафиком Kubernetes дает больше эксплуатационной нагрузки, чем пользы: управление кластером, обновления версий и мониторинг превращаются в отдельные статьи работ. В таком проекте обычно достаточно версионированного образа, правильно выстроенного конвейера поставки и отката в один шаг. Если узкое место вызвано нагрузкой, оркестрация его тоже не устранит: сначала на стороне масштабирования бэкенда изучаются запросы, кеш и очередь, потому что медленная работа обычно связана с одним запросом или синхронным шагом, а не с мощностью машины.