Какую проблему решает Kubernetes

Что проверяют

Понимаете ли вы, какую боль Kubernetes снимает, а не только список его объектов. Для Go-разработчика следом почти всегда идут вопросы о том, как сервис должен вести себя в кластере: пробы, graceful shutdown, лимиты ресурсов.

Как отвечать

Проблема в одной фразе: запускать много контейнеров на многих машинах и держать их в нужном состоянии без ручной работы. Разложите на части:

• желаемое состояние: в манифесте описано, сколько реплик Deployment нужно и с каким образом, а контроллеры постоянно сверяют реальность с описанием и устраняют расхождение;
• планирование: kube-scheduler сам решает, на какой узел поставить под, с учётом requests по CPU и памяти;
• самовосстановление: упавший контейнер перезапускается, под с умершего узла пересоздаётся на другом;
• сеть: Service даёт стабильное имя и балансировку между подами, Ingress или Gateway API выводят трафик наружу;
• выкатка и масштабирование: rolling update с откатом, HorizontalPodAutoscaler по метрикам;
• конфигурация: ConfigMap и Secret отдельно от образа.

Дальше привяжите к Go. Сам Kubernetes написан на Go, операторы и контроллеры пишут на client-go и controller-runtime. Сервис должен ловить SIGTERM и корректно завершаться через http.Server.Shutdown, по умолчанию на это даётся 30 секунд. Readiness и liveness пробы отдают разные ручки. Под лимит памяти ставят GOMEMLIMIT, а GOMAXPROCS начиная с Go 1.25 сам учитывает CPU-лимит контейнера, на старых версиях для этого подключают automaxprocs.

Где спотыкаются

Путают Kubernetes с Docker. Docker собирает и запускает контейнер на одной машине, Kubernetes оркестрирует контейнеры на кластере.

Считают Secret защищённым хранилищем. По умолчанию это base64, а шифрование в etcd и ограничение доступа через RBAC настраивают отдельно.

Делают liveness-пробу, которая проверяет базу. База начинает тормозить, и кластер перезапускает все поды разом, превращая проблему в аварию.