Kubernetes: кластер работает, но не реагирует на изменения, не может получать журналы

У меня есть кластер с версией k8s 1.12.8 на AWS EC2. Кластер содержит несколько модулей - одни обслуживают веб-трафик, а другие настроены как запланированные CronJobs. Кластер работает нормально в своей текущей конфигурации не менее 6 месяцев, при этом CronJobs запускается каждые 5 минут.

В последнее время CronJobs просто прекратились. Просмотр модулей через kubectl показывает, что последний запуск всех запланированных CronJobs был примерно в одно и то же время. Журналы, отправленные в AWS Cloudwatch, не содержат сообщений об ошибках и останавливаются в то же время, когда kubectl отображается для последнего запуска.

Пытаясь диагностировать эту проблему, я обнаружил более широкую картину того, что кластер не реагирует на изменения, например: я не могу получить журналы или узлы через kubectl.

Я удалил модули из наборов реплик, и они больше не возвращаются. Я установил значения автомасштабирования для наборов реплик, и ничего не происходит.

Исследование kubelet журналов на главном экземпляре выявило повторяющиеся ошибки, совпадающие со временем, когда сбой был впервые обнаружен:

I0805 03:17:54.597295 2730 kubelet.go:1928] SyncLoop (PLEG): "kube-scheduler-ip-x-x-x-x.z-west-y.compute.internal_kube-system(181xxyyzz)", event: &pleg.PodLifecycleEvent{ID:"181xxyyzz", Type:"ContainerDied", Data:"405ayyzzz"}
        ...
E0805 03:18:10.867737 2730 kubelet_node_status.go:378] Error updating node status, will retry: failed to patch status "{\"status\":{\"$setElementOrder/conditions\":[{\"type\":\"NetworkUnavailable\"},{\"type\":\"OutOfDisk\"},{\"type\":\"MemoryPressure\"},{\"type\":\"DiskPressure\"},{\"type\":\"PIDPressure\"},{\"type\":\"Ready\"}],"conditions\":[{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"OutOfDisk\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"MemoryPressure\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"DiskPressure\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"PIDPressure\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"Ready\"}]}}" for node "ip-172-20-60-88.eu-west-2.compute.internal": Patch https://127.0.0.1/api/v1/nodes/ip-x-x-x-x.z-west-y.compute.internal/status?timeout=10s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
...
E0805 03:18:20.869436 2730 kubelet_node_status.go:378] Error updating node status, will retry: error getting node "ip-172-20-60-88.eu-west-2.compute.internal": Get https://127.0.0.1/api/v1/nodes/ip-172-20-60-88.eu-west-2.compute.internal?timeout=10s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Запуск docker ps на главном узле показывает, что оба контейнера k8s_kube-controller-manager_kube-controller-manager и k8s_kube-scheduler_kube-scheduler были запущены 6 дней назад, тогда как другие контейнеры k8s находятся на 8+ месяцев.

tl; dr Контейнер на моем основном узле (вероятно, kube-scheduler, kube-controller-manager или оба) умер. Контейнеры вернулись, но не могут связаться с существующими узлами - это мешает выполнению любых запланированных CronJobs или новых развертываний.

Как можно перенастроить kubelet и связанные службы на главном узле, чтобы снова обмениваться данными с рабочими узлами?


kubernetes docker kubernetes-cronjob amazon-web-services kubectl
person duncanhall    schedule 11.08.2020    source источник
comment
В этом случае вы могли бы начать с проверки вывода журнала кубелец, это было бы моим первым предположением. См. Также: kubernetes.io/docs/ задачи / отладка-приложение-кластер /   -  person Blokje5    schedule 11.08.2020
comment
@ Blokje5 Спасибо - я добавил много новых выводов выше - любая дополнительная помощь, которую вы можете оказать, очень ценится   -  person duncanhall    schedule 11.08.2020

Ответы (1)


arrow_upward
1
arrow_downward

Из документации по Устранение неполадок кластеров

Для более глубокого погружения в кластер необходимо войти в соответствующие машины. Вот расположение соответствующих файлов журналов. (обратите внимание, что в системах на основе systemd вам может потребоваться вместо этого использовать journalctl)

Главные узлы

/var/log/kube-apiserver.log - сервер API, отвечающий за обслуживание API

/var/log/kube-scheduler.log - Планировщик, отвечающий за принятие решений по расписанию

/var/log/kube-controller-manager.log - Контроллер, управляющий контроллерами репликации

Рабочие узлы

/var/log/kubelet.log - Kubelet, отвечает за запуск контейнеров на узле /var/log/kube-proxy.log - Kube Proxy, отвечает за балансировку нагрузки сервисов

Другой способ получить журналы - использовать docker ps, чтобы получить containerid, а затем использовать docker logs containerid

Если у вас есть (а вам необходимо) настройка системы мониторинга с использованием prometheus и Grafana, вы можете проверить такие показатели, как высокая загрузка процессора на подах сервера API.

person Arghya Sadhu    schedule 11.08.2020