Kubernetes pods (некоторые) умирают после работы в течение дня

Question

Мы пробуем тестовую установку с версией Kubernetes версии 1.0.6 на AWS.

Эта настройка включает в себя стручки для Cassandra (2-х узлов), Spark (master, 2-worker, driver), RabbitMQ (1-node). Некоторые стручки этой установки умирают через день или около того

Есть ли способ получить журналы от Кубернеса о том, как/почему они умерли?

Когда вы пытаетесь перезапустить спрятанные стручки вручную, вы получаете статус некоторых элементов, поскольку категория «/ искровой рабочий готова, контейнер создает», и начало сборки никогда не завершается.

Только вариант в сценарии - «kube-down.sh, а затем kube-up.sh» и проходит всю установку с нуля.

Answer 1

kubectl describe ${POD_NAME} или kubectl logs ${POD_NAME} ${CONTAINER_NAME} должно предоставить вам дополнительную информацию для отладки.

Также см. https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/application-troubleshooting.md#debugging-pods для общих инструкций по устранению неисправностей.

EDIT:

После обсуждения в комментариях, я думаю, что проблема с вашим узлом является то, что узел был отвечать на запросах в течение> 5 минут (потенциально из-за интенсивное использование памяти influxdb). Затем контроллер узла считал узел не готовым и вынул все узлы на узле. Обратите внимание, что контейнеры, управляемые контроллерами репликации, будут воссозданы (с другим именем), но созданные вручную вручную не будут воссозданы.

Если вы подозреваете, что использование памяти в качестве источника infuxdb является основной причиной, вы можете попробовать не запускать этот модуль, чтобы убедиться, что проблема разрешилась сама. Кроме того, вы можете изменить предел памяти influxdb container на меньшее значение.

EDIT2:

Некоторые советы для выяснения того, что случилось с узлом:

1. Проверить /var/log/kubelet.log. Это самый простой подход.

2. kubectl describe nodes или kubectl get events | grep <node_name> (для старой версии kubernetes)

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

3. kubectl get node <node_name> -o yaml --watch позволяет контролировать объект узла, включая его статус в yaml. Это будет периодически обновляться.

Answer 2

Из-за an issue in Kubernetes у ваших узлов, вероятно, закончилось свободное место на диске.

Непрямое исправление доступно только недавно выпущенным Kubernetes v1.0.7.

AWS: Create one storage pool for aufs, not two #13803 (justinsb)

но, как описано в вышеупомянутой проблеме, в этой области все еще есть какая-то работа.