Неочевидные проблемы Kubernetes, которые вы могли пропустить

На вебинаре разбираем типовые ошибки, которые можно допустить при деплое сервисов в кластер: от некорректной настройки лимитов ресурсов до сложных кейсов с admission webhooks.

В конце вебинара будут даны рекомендации по настройке вашего кластера и приложений для безотказной работы.

Запись доклада:
https://vk.com/video-59405817_456239816
https://rutube.ru/video/9b354b74f4ec5c72d4b2e1a5d0ade6a5/

Transcript

2. ВЕДУЩИЙ Виталий Лихачев SRE в нидерландском travel.tech ex-Avito Senior Software Engineer • 10+ лет в коммерческой разработке • Анамнез: php, python, golang, java, k8s, postgresql, etc. • Шатаю инфраструктуру по запросам • Автор канала про Kubernetes Kubernetes и кот Лихачева
3. ЭКСПЕРТ Руслан Гайнанов Главный инженер DevOps, ИТХолдинг T1 • Больше 10 лет в IT • Спикер DevOops, Импульс-Т1, UDW • Тимлид команды DevOps
4. 1. Классификация проблем 2. Основные ошибки, последствия и способы защиты 3. 7 рекомендаций, чтобы спать спокойно О чем поговорим?
5. Ваши варианты в комментариях Какая ошибка от k8s вам чаще всего попадается? (больше всего бесит?
6. Что имеем Кластер
7. Что имеем Кластер Разработчик
8. Что имеем Кластер Приложение Разработчик пишет
9. Что имеем Кластер Приложение Разработчик пишет деплоится
10. Что имеем Админ Кластер Приложение Разработчик пишет деплоится обслуживает
11. Что имеем Админ Кластер Приложение Разработчик Клиент пишет деплоится обслуживает обращается
12. Проблемы? Админ Кластер Приложение Разработчик Клиент пишет деплоится обслуживает обращается
13. Классификация проблем 1
14. 1. Проблемы конфигурации Классификация проблем 2. Проблемы сетевой конфигурации 3. Проблемы безопасности 4. Проблемы хранения данных 5. Проблемы обновлений и управления версиями 6. Проблемы масштабирования 7. Проблемы вокруг инфраструктуры 8. Антипаттерны управления кластером
15. Основные ошибки, последствия и способы защиты 2
16. Ошибки неправильной конфигурации сервиса 1. Некорректные ресурсные ограничения (CPU/RAM) a. Не указаны requests и limits → приводит нехватке ресурсов. b. Слишком жесткие лимиты → контейнеры убиваются OOMKiller, возникает троттлинг CPU 2. Неправильные настройки Health Check Liveness & Readiness Probes) a. Долгие/частые проверки → сервис не успевает стартовать. b. Отсутствие проб → Kubernetes не понимает состояние пода. 3. Ошибки в манифестах (YAML/JSON) a. Некорректные отступы, опечатки в полях. b. Использование latest-тега для образов → проблемы с версионностью. 4. Заигрались с affinity/anti affinity a. Не найдется ноды на этапе scheduling Но есть нюансы
17. Можно ли задать limits больше ресурсов ноды?
18. ✅ Управляйте параметрами requests и limits. Мониторьте OOM, троттлинг • https://cloud.vk.com/blog/kak-poluchit-dostup-k-resursam-kubernetes-pod/ • https://learnkube.com/setting-cpu-memory-limits-requests • https://dnastacio.medium.com/why-you-should-keep-using-cpu-limits ✅ Устанавливайте Liveness & Readiness Probes • https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices • https://www.baeldung.com/spring-liveness-readiness-probes ✅ Используйте линтеры, validation-webhooks, OPA • https://habr.com/ru/companies/slurm/articles/688268/ • https://www.wiz.io/academy/kubernetes-admission-controllers 🚨 Не устанавливайте все подряд из интернета (helm install …, kubectl apply -f URL) Как избежать ошибок конфигурирования?
20. Ошибки сетевой конфигурации 1. Неправильные Network Policies или их отсутствие a. Излишне строгие правила → сервисы не могут общаться. b. Отсутствие ограничений → уязвимости безопасности. 2. Проблемы с DNS и Service Discovery a. Неправильное имени/неймспейс → недоступность сервиса. b. Кэширование DNS в CoreDNS → задержки. c. Неправильная балансировка (например, в gRPC) → перегрузка отдельных реплик d. Отсутствие рефреша адресов подов для headless сервиса → потеря коннектов e. Неправильные настройки sidecar в service mesh → больше ретраев, чем нужно 3. Неправильный выбор типа Service a. NodePort/LoadBalancer для внешнего доступа → уязвимости безопасности.
21. Можно ли обращаться к сервисам по ingress-url внутри кластера?
22. ✅ Мониторинг трафика кластера. Визуализация и тестирование Network Policies • https://habr.com/ru/companies/slurm/articles/337088/ • https://github.com/Tufin/test-network-policies • https://habr.com/ru/companies/ruvds/articles/712536/ ✅ Валидация и мониторинг Services & DNS • https://www.nslookup.io/learning/the-life-of-a-dns-query-in-kubernetes/ • https://grafana.com/grafana/dashboards/14981-coredns/ Как избежать ошибок сетевой конфигурации
23. Ошибки безопасности 1. Избыточные права (RBAC) a. Сервисные аккаунты с правами cluster-admin. b. Отсутствие ограничений на get/list/watch в кластере. 2. Работа под root в контейнерах a. Уязвимости из-за запуска с privileged: true – взлом одного пода = доступ ко всему кластеру (но не совсем) 3. Хранение секретов в plaintext a. ConfigMap вместо Secrets → утечка чувствительных данных b. Лучше использовать vault в разных вариантах интеграции с k8s. В том числе с полным пропуском хранения секретов в etcd. Но - новая точка отказа.
24. Ошибки безопасности Доступ на ноду не значит доступ сразу ко всем секретам kubectl --kubeconfig /var/lib/kubelet/kubeconfig -n default get secret my-app-secret # Secret не принадлежит ни одному поду для узла кластера Error from server (Forbidden): secrets "my-app-secret" is forbidden: User "system:node:minikube" cannot get resource "secrets" in API group "" in the namespace "default": no relationship found between node 'minikube' and this object # Секрет примонтирован в любой под узла кластера NAME TYPE DATA AGE my-app-secret Opaque 2 5s
26. Ошибки хранения данных 1. Неправильная настройка Persistent Volumes PV/PVC a. PVC висят в статусе Pending. b. Неверный storageClass или режим доступа (RWO vs RWM). 2. Проблемы с динамическим провижинингом Диск не освобождается после удаления PVC. 3. Отсутствие бэкапов данных Удалении StatefulSet → потеря данных 4. Использование emptyDir с medium=memory Больше скорость, но файлы в volume учитываются в limits volumes: - name: cache-volume emptyDir: sizeLimit: 500Mi medium: Memory
27. Ошибки обновлений и управления версиями 1. Rollout без стратегии (Rolling Update vs Blue-Green) a. Приложение «падает» из-за одновременного обновления всех реплик. b. Можно рассмотреть argo rollouts для более сложных деплоев, которых нет из коробки в k8s 2. Отсутствие rollback-стратегии Невозможность быстро откатить деплой. Либо снять с него трафик без отката. 3. Несовместимость версий Kubernetes APIизменения (extensions/v1beta1 → apps/v1). 4. Несовместимость версия приложения Клиенты не могут работать с одной из версий → 5xx или другие варианты ошибок
28. Ошибки масштабирования 1. Некорректные метрики для масштабирования Использование CPU вместо релевантных метрик (RPS, очереди сообщений). 2. Слишком агрессивные/медленные параметры (scaleUp / scaleDown) a. scaleUp без задержки → резкий рост подов и перегрузка кластера. b. scaleDown слишком медленный → лишние поды тратят ресурсы. 3. Отсутствие ограничений (minReplicas / maxReplicas) maxReplicas не задан → исчерпание ресурсов. 4. Невнимание к лимитам нод Поды не могут быть размещены из-за taints/tolerations или nodeSelector. 5. Игнорирование Node Autoscaler Нехватка или перерасход ресурсов. 6. Неправильные ResourceQuotas и LimitRanges a. Сервисы не могут масштабироваться. b. Eviction подов из-за нехватки ресурсов.
29. Как избежать ошибок масштабирования? ✅ Автоматизируйте – используйте HPA, VPA и CA. ✅ Тестируйте – проверяйте поведение при нагрузке (например, через k6 или Locust). ✅ Мониторьте – следите за метриками (kubectl top, Prometheus). ✅ Ограничивайте – выставляйте ResourceQuotas и LimitRanges. Если масштабирование настроено правильно, Kubernetes сам справится с нагрузкой. Если нет – готовьтесь к ночным звонкам из-за упавшего продакшена. 🚨
31. Проблемы вокруг инфраструктуры Mutating admission webhook a. При переезде пода может не отработать (failurePolicy=Fail) b. Неожиданно может не применить изменения (failurePolicy=Ignore) apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration webhooks: - name: my-webhook.example.com failurePolicy: Fail
32. Проблемы вокруг инфраструктуры 1. Container registry недоступен При переезде пода не получится скачать образ ⇒ использовать registry cache 2. Медленные диски для etcd Риски частого перевыбора лидера 3. Много разных типов нод Непредсказуемая производительность. Даже в рамках одного типа нод в облаке могут использоваться разные CPU.
34. Антипаттерны управления кластером 1. Ручные изменения в обход GitOps kubectl edit без фиксации в репозитории → дрифт конфигурации. 2. Игнорирование drain нод перед обслуживанием Перезагрузка ноды без drain → недоступные сервисы. 3. Отсутствие резервного копирования etcd Потеря данных кластера при сбое. 4. Отсутствие мониторинга и алертинга a. Нет Prometheus/Grafana или логирования (Loki, ELK)→ проблемы обнаруживаются слишком поздно – сервис уже упал. b. Нет логов и метрик → невозможно анализировать инциденты.
35. 7 рекомендаций, чтобы спать спокойно 3
36. ТОП7 рекомендаций для безотказной работы 1. Всегда указывать requests и limits для CPU/RAM Предотвращает оверсабскрайбинг и OOM убийства подов. 2. Настраивать Liveness и Readiness пробы Корректно управляем жизненным циклом подов через Kubernetes. 3. Использовать теги образов, отличные от latest Избегаем неожиданных изменений при деплое. 4. Хранить секреты в Secrets, а не в ConfigMaps (а еще лучше Vault + ротация) Обеспечиваем безопасное управление чувствительными данными 5. Автоматизировать деплой через инструменты СI/GitOps ArgoCD/Flux) Исключаем дрифт конфигурации и ручные правки через kubectl. 6. Планировать обновления с RollingUpdate и стратегией rollback Минимизируем downtime при деплое. 7. Использовать PodDisruptionBudget и drain ноды перед обслуживанием Гарантируем, что критичные сервисы останутся доступными.
37. т в о й у н и в е р с и т е т б у д у щ е г о www.slurm.io