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

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

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

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

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

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

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


kubernetes jenkins-plugins aws-ebs
person Arpit Goyal    schedule 12.11.2018    source источник
comment
4 МБ / с не кажется мне очень высокой пропускной способностью для твердотельных накопителей gp2, но вы можете ознакомиться с рекомендациями Amazon по производительности здесь, чтобы проверить размер / тип вашего диска. Обратите внимание, что вы также можете быть ограничены IOPS вместо пропускной способности, поэтому, возможно, будет полезно собрать эту информацию и в Grafana, если это возможно.   -  person Dan    schedule 12.11.2018

Ответы (2)


arrow_upward
2
arrow_downward

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

Истина, если узел исправен и готов принять поды, Ложь, если узел не исправен и не принимает поды, и Неизвестно, если контроллер узла не слышал от узла в последнем периоде отсчета-монитора узла (по умолчанию 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 конечных точках.

person Rico    schedule 12.11.2018

arrow_upward
1
arrow_downward

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

/etc/init.d/kubelet restart

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

person Prateek Sen    schedule 15.05.2019