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

Я запускаю кластер Kubernetes, используя контейнерный движок Azure. У меня проблема с одной из служб kubernetes, которая выполняет мониторинг ресурсов heapster. Стручок перезапускается каждую минуту или что-то в этом роде. Я попытался удалить развертывание кучи, набор реплик и поды и воссоздать развертывание. Это мгновенно возвращается к тому же самому поведению.

Когда я смотрю на ресурсы с меткой кучи, это выглядит немного странно:

$ kubectl get deploy,rs,po -l k8s-app=heapster --namespace=kube-system
NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/heapster   1         1         1            1           17h

NAME                     DESIRED   CURRENT   READY     AGE
rs/heapster-2708163903   1         1         1         17h
rs/heapster-867061013    0         0         0         17h

NAME                           READY     STATUS    RESTARTS   AGE
po/heapster-2708163903-vvs1d   2/2       Running   0          0s

Почему-то есть два набора реплик. Тот, который называется rs/heapster-867061013, продолжает появляться, даже когда я удаляю все ресурсы и повторно развертываю их. Выше также показано, что модуль только что запущен, и это проблема, которую он продолжает создавать, затем он запускается в течение нескольких секунд и создается новый. Я новичок в использовании кубернетов, поэтому не уверен, какие файлы журналов имеют отношение к этой проблеме.

Журналы из контейнера heapster

heapster.go:72] /heapster source=kubernetes.summary_api:""
heapster.go:73] Heapster version v1.3.0
configs.go:61] Using Kubernetes client with master "https://10.0.0.1:443" and version v1
configs.go:62] Using kubelet port 10255
heapster.go:196] Starting with Metric Sink
heapster.go:106] Starting heapster on port 8082

Журналы из контейнера heapster-nanny

pod_nanny.go:56] Invoked by [/pod_nanny --cpu=80m --extra-cpu=0.5m --memory=140Mi --extra-memory=4Mi --threshold=5 --deployment=heapster --container=heapster --poll-period=300000 --estimator=exponential]
pod_nanny.go:68] Watching namespace: kube-system, pod: heapster-2708163903-mqlsq, container: heapster.
pod_nanny.go:69] cpu: 80m, extra_cpu: 0.5m, memory: 140Mi, extra_memory: 4Mi, storage: MISSING, extra_storage: 0Gi
pod_nanny.go:110] Resources: [{Base:{i:{value:80 scale:-3} d:{Dec:<nil>} s:80m Format:DecimalSI} ExtraPerNode:{i:{value:5 scale:-4} d:{Dec:<nil>} s: Format:DecimalSI} Name:cpu} {Base:{i:{value:146800640 scale:0} d:{Dec:<nil>} s:140Mi Format:BinarySI} ExtraPerNode:{i:{value:4194304 scale:0} d:{Dec:<nil>} s:4Mi Format:BinarySI} Name:memory}]

person Benjamin Hammer Nørgaard    schedule 08.09.2017    source источник
comment
Что говорят журналы модуля heapster? Выходит из-за какой-то ошибки? Также какой restartPolicy установлен для этого модуля?   -  person fishi0x01    schedule 09.09.2017
comment
@fishi Я добавил логи к вопросу   -  person Benjamin Hammer Nørgaard    schedule 10.09.2017
comment
У модуля была RestartPolicy Always.   -  person Benjamin Hammer Nørgaard    schedule 10.09.2017


Ответы (2)


Совершенно нормально и важно, чтобы контроллер развертывания сохранял старые ресурсы ReplicaSet для быстрого отката.

Ресурс развертывания управляет ресурсами ReplicaSet. Развертывание кучи настроено для запуска 1 модуля - это означает, что он всегда будет пытаться создать один ReplicaSet с 1 модулем. Если вы обновляете развертывание (скажем, новую версию кучи), тогда ресурс развертывания создает новый ReplicaSet, который будет планировать модуль с новой версией. В то же время старый ресурс ReplicaSet устанавливает для своих желаемых модулей значение 0, но сам ресурс по-прежнему сохраняется для упрощения откатов. Как видите, в старом ReplicaSet rs/heapster-867061013 запущено 0 модулей. Если вы сделаете откат, развертывание deploy/heapster увеличит количество модулей в rs/heapster-867061013 до 1 и уменьшит количество в rs/heapster-2708163903 обратно до 0. Вам также следует проверить документация о контроллере развертывания (на случай, если вы еще этого не сделали).

Тем не менее, мне кажется странным, почему ваш недавно созданный контроллер развертывания мгновенно создает 2 ReplicaSet. Вы подождали несколько секунд (скажем, 20) после удаления контроллера развертывания и перед созданием нового? Для меня иногда требуется некоторое время, прежде чем удаления распространятся по всему кластеру, и если я воссоздаю слишком быстро, то один и тот же ресурс будет повторно использован.

Относительно воссоздания контейнера heapster, о котором вы упомянули: модули имеют restartPolicy < / а>. Если установлено значение Never, модуль будет воссоздан его ReplicaSet в случае его выхода (это означает, что создается новый ресурс модуля, а старый удаляется). Я предполагаю, что для вашего модуля heapster задана эта Never политика. Он может выйти из-за какой-то ошибки и достичь состояния Failed (вам нужно проверить это с помощью журналов). Затем через некоторое время ReplicaSet создает новый модуль.

person fishi0x01    schedule 08.09.2017

Хорошо, значит, это проблема в конфигурации кубернетов по умолчанию для службы контейнеров Azure. Мне помог один сторонник лазурного.

Проблема устраняется добавлением метки addonmanager.kubernetes.io/mode: EnsureExists к развертыванию кучи. Вот запрос на вытягивание, на который ссылается сторонник: https://github.com/Azure/acs-engine/pull/1133

person Benjamin Hammer Nørgaard    schedule 19.09.2017