Сегодня у нас партнерский пост от DevOps FM. Замечали, что определенные ошибки в настройке подов неизбежно ведут к инцидентам? Собрали для вас подборку плохих практик, которые ни в коем случае нельзя повторять в работе с оркестратором.
⚪️ Не учитывайте тип трафика при балансировке нагрузки для подов
По умолчанию поведение Kubernetes при трафике HTTP/2 отличается от HTTP/1. Без настройки маршрутизации на L7 один под берет на себя всю нагрузку CPU, в то время как другие простаивают.
Good practices:
⁃ При HTTP/2 заранее проверяйте балансировку в кластере (L4 vs L7)
⁃ Проводите нагрузочное тестирование с теми же настройками (connection pooling/keep-alive), что будут в проде
⁃ Отслеживайте распределение connections и latency по pod-ам
⚪️ Kubernetes сам синхронизируется с внешними сервисами
При использовании внешних тулзов и сервисов, таких как Argo CD, возникают проблемы. Используйте скейлинг для обнаружения.
Good practices:
⁃ В GitOps-кластерах не правьте поля, которые управляются контроллерами (HPA, VerticalPodAutoscaler)
⁃ В работе избегайте client-side внедрений и удаляйте реплики из манифестов деплоя при использовании HPA
⚪️ Всегда задавайте лимиты CPU — троттлинг лишним не бывает
В приложении возникают таймауты из-за CFS троттлинга.
Good practices: не задавайте CPU лимиты без необходимости, а при использовании проводите тест нагрузки
⚪️ Не задавайте приоритет нагрузкам
Если приоритет не задан, kubelet избавится от любого пода.
Good practices:
⁃ Всегда задавайте PriorityClass для системных контроллеров
⁃ Отслеживайте приоритет и его использование
⁃ Тестируйте поведение в staging
⚪️ Удаляйте контроллеры до управляемых ресурсов, поды скажут «спасибо»
Смело удаляйте контроллер, если хотите очередей. Поды застревают в «Terminating» из-за финализаторов, в EKS они по-прежнему удерживают IP-шники и исчерпывают пул адресов подсети.
Good practices:
⁃ Никогда не удаляйте контроллер, пока не удалили управляемые им ресурсы
⁃ Относитесь к финализаторам как к «постоянным» до удаления
⁃ Настройте мониторинг и алерты на: число Terminating подов, долю занятых IP в подсети, количество подов в обработке
⚪️ Храните большие логи локально
Если хранить логи на локальном диске ноды, их станет слишком много, диск заполнится, нода уйдет в DiskPressure. Kubelet удалит поды, а новые просто не запустятся.
Good practices:
⁃ Не храните временные логи только на локальном диске. Используйте централизованную систему: Fluentd, Logstash, облако
⁃ Устанавливайте запросы и лимиты для ephemeral-storage у контейнеров, чтобы избежать неограниченного потребления диска
⁃ Включите ротацию логов и ограничение размера
⁃ Настройте алерты на рост использованного диска в связке с подами — disk usage per pod
Какие худшие практики в работе с Kubernetes встречались вам? Отправляйте свои идеи предложенным постом через бота — если соберем достаточно, опубликуем подборку здесь.
@DevOpsKaz 😛