Когда количество контейнеризированных сервисов растёт быстрее, чем команда платформы, узким местом становится не Kubernetes, а его эксплуатация. Generali решала именно эту проблему — и сместила фокус с управления кластером на управление приложениями.
Основной предел проявился не в производительности, а в операционке. Портфель микросервисов рос, появлялись мульти-тенант сценарии, и вместе с этим — ручное масштабирование, разрозненные практики безопасности и переизбыточное резервирование ресурсов. Разные команды — разные стандарты, что приводило к нестабильному security posture и усложняло соблюдение compliance. Kubernetes как платформа работал, но его сопровождение начинало съедать инженерное время.
Выбор в пользу Amazon EKS был ожидаем: зрелая интеграция с AWS и уже имеющийся опыт команды. Но ключевое решение — переход на EKS Auto Mode, где AWS берёт на себя управление нодами, обновлениями, аддонами и частью операционной модели. Это trade-off в пользу снижения контроля над инфраструктурой ради консистентности и уменьшения toil. Взамен — автоматическое масштабирование, унификация окружений и встроенные практики безопасности.
На практике это потребовало адаптации процессов. Auto Mode регулярно обновляет ноды (включая Bottlerocket), что означает их пересоздание. Чтобы не ловить деградации, команда ввела окна обслуживания и строго настроила Pod Disruption Budgets и Node Disruption Budgets. Архитектурные ограничения тоже стали частью стратегии: только stateless-сервисы, immutable pods, деплой через Helm, масштабирование через HPA. Секреты вынесены в AWS Secrets Manager с синхронизацией через External Secrets Operator — без вшивания в манифесты. Сетевая модель усилена через AWS Network Firewall с egress-фильтрацией по SNI, что закрывает типичную дыру с исходящими соединениями. Безопасность дополнена GuardDuty (включая runtime и audit сигналы) и Inspector, который сопоставляет уязвимости с реально запущенными контейнерами, а не просто образами в реестре.
Отдельный слой — наблюдаемость и финансы. Через связку CloudWatch и Managed Grafana команда получила разрез по namespace и проектам без управления самим Grafana. Для cost allocation используются теги уровня EKS (cluster, namespace, deployment), что позволяет соотносить затраты с бизнес-юнитами — критично в мульти-тенант среде.
Результат — не столько в raw-перфомансе, сколько в перераспределении усилий. Операционные задачи (патчи, апгрейды, масштабирование) ушли в платформу, команда сфокусировалась на поддержке продуктовых команд. Улучшилась консистентность безопасности, снизилось переизбыточное потребление ресурсов, упростилось расследование инцидентов за счёт корреляции сигналов. Метрики напрямую не раскрываются, но по описанию — это классический кейс уменьшения toil и повышения предсказуемости платформы за счёт управляемого Kubernetes.