Периодические 5xx идут только от Pod на одном узле — отделите узловую причину от прикладной.
Пользователи видят периодические 5xx. Доля ошибок, сгруппированная по узлу пода, около нуля везде, кроме одного узла. Поды крутят один образ и конфиг. Определите, узловая это проблема или баг приложения, и действуйте.
# доля 5xx по узлам (из логов запросов, join по spec.nodeName)
api-1 1/1 Running node-1 0.0% 5xx
api-2 1/1 Running node-3 0.1% 5xx
api-9 1/1 Running node-7 9.4% 5xx <-- ошибки скапливаются тут
$ kubectl describe node node-7 | grep -E 'Pressure|Ready'
MemoryPressure True
Ready TrueДиагностируйте и исправьте.
Один образ и конфиг, но ошибки только на node-7, изолируем к узлу, не к приложению. Группируйте по spec.nodeName: выделяется один узел — приложение оправдано. Подозреваемые: давление памяти/диска, плохой CoreDNS или kube-proxy, полный conntrack. Cordon и drain.
- ✗Винить приложение до группировки ошибок по
spec.nodeName - ✗Упускать давление памяти/диска узла, ведущее к OOM и вытеснению
- ✗Забывать про CoreDNS, kube-proxy и conntrack узла как подозреваемых
- →Почему полная таблица conntrack на узле даёт периодические, а не постоянные 5xx?
- →Что делает
kubectl cordonи чтоdrainдобавляет сверху?
Решение
1. Изоляция: узел или приложение
Один и тот же образ/конфиг на всех подах, но 5xx концентрируются на node-7. Логика: если бы виновато было приложение, ошибки распределились бы по узлам. Значит — узло-локальная причина. Группировка ошибок по spec.nodeName — ключевой шаг.
2. Узловые подозреваемые
$ kubectl describe node node-7 | grep Pressure # MemoryPressure True
$ kubectl get pods -n kube-system -o wide | grep node-7 # coredns/kube-proxy тут здоровы?
# на узле: conntrack -S | grep drop ; dmesg | grep -i 'oom\|conntrack'- давление памяти/диска (как здесь) → OOM/вытеснение подов;
- CoreDNS/kube-proxy на узле сбоят → таймауты/резолвы → 5xx;
- conntrack table full → часть новых соединений дропается (отсюда «периодически»).
3. Действие
kubectl cordon node-7 (не пускать новые поды) → kubectl drain node-7 (увести существующие). Трафик уходит на здоровые узлы, кровотечение остановлено; затем чините (память, перезапуск CoreDNS/kube-proxy, лимиты conntrack) или заменяйте узел.
