Статус узла меняется на неизвестный в модуле с высокими требованиями к ресурсам - PullRequest
Новая
       35

Статус узла меняется на неизвестный в модуле с высокими требованиями к ресурсам

0 голосов
/ 12 ноября 2018

У меня есть конвейер развертывания Jenkins, который включает плагин kubernetes.Используя плагин kubernetes, я создаю подчиненный модуль для построения приложения узла, используя yarn .Запросы и ограничения для ЦП и памяти установлены.

Когда мастер Jenkins планирует подчиненное устройство, иногда (как я не видел шаблон на данный момент) модуль делает весь узел недоступным и меняетстатус узла должен быть неизвестен.При тщательном осмотре в Grafana ресурсы процессора и памяти, похоже, находятся в пределах досягаемости без видимых всплесков.Единственный всплеск, который происходит с дисковым вводом / выводом, который достигает ~ 4 МБ.

Я не уверен, является ли это причиной того, что узел не может называть себя членом кластера.Мне понадобилась бы помощь в нескольких моментах:

a) Как подробно диагностировать причины выхода узла из кластера.

b) Если причина в дисковых IOPS, есть ликакие-либо запросы по умолчанию, ограничения для IOPS на уровне Kubernetes?

PS: я использую EBS (gp2)

Ответы [ 2 ]

0 голосов
/ 15 мая 2019

Учитывая, что узел ранее работал и недавно перестал отображать состояние готовности, перезапустите службу kubelet. Просто вставьте ssh в уязвимый узел и выполните: 

/etc/init.d/kubelet restart

Вернитесь к своему главному узлу и запустите kubectl get, чтобы проверить, работает ли узел сейчас

0 голосов
/ 13 ноября 2018

Согласно документам , для узла должен быть «Готов»:

Истинно, если узел исправен и готов к приему стручков, Ложно, если узел не исправен и не принимает стручки, и Неизвестно, если контроллер узла не слышал от узла в последнем периоде отсрочки узла-монитора. (по умолчанию 40 секунд)

Если вам кажется, что когда вы запускаете свои рабочие нагрузки, ваш kube-apiserver не слышит от вашего узла (kubelet) в течение 40 секунд. Там может быть несколько причин, некоторые вещи, которые вы можете попробовать:

  • Чтобы увидеть «События» в вашем узле, выполните: 

    $ kubectl describe node <node-name>

  • Чтобы увидеть, видите ли вы что-нибудь необычное на вашем kube-apiserver. На вашем активном главном прогоне: 

    $ docker logs <container-id-of-kube-apiserver>

  • Чтобы увидеть, видите ли вы что-то необычное в вашем kube-controller-manager, когда ваш узел переходит в состояние «Неизвестно». На вашем активном главном прогоне: 

    $ docker logs <container-id-of-kube-controller-manager>

  • Увеличьте значение --node-monitor-grace-period в вашем kube-controller-manager. Вы можете добавить его в командную строку в /etc/kubernetes/manifests/kube-controller-manager.yaml и перезапустить контейнер kube-controller-manager.

  • Когда узел находится в состоянии «Неизвестно», можете ли вы ssh войти в него и посмотреть, сможете ли вы достичь kubeapi-server? Как на <master-ip>:6443, так и на kubernetes.default.svc.cluster.local:443 конечных точках.

...