Что делает узел kubernetes нездоровым? - PullRequest
Новая
       0

Что делает узел kubernetes нездоровым?

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

За последние 1 месяц мы столкнулись с 4 AUTO_REPAIR_NODES событиями (показанными командой gcloud container operations list) в нашем кластере GKE. Следствием автоматического восстановления узла является то, что узел воссоздается и получает новый внешний IP-адрес, а новый внешний IP-адрес, который не был добавлен в белый список сторонними службами, в конечном итоге вызывал сбой служб, работающих на этом новом узле.

Я заметил, что в нашем кластере Kubernetes у нас включено " Автоматическое восстановление узла ", и мне хотелось отключить это, но прежде чем я это сделаю, мне нужно больше узнать о ситуации.

Мои вопросы:

  1. Какие распространенные причины делают нездоровый узел в первую очередь? Мне известна эта статья https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_process, в которой говорится, что "узел сообщает о состоянии NotReady при последовательных проверках в течение заданного временного порога", что приведет к автоматическому восстановлению. Но что может заставить узел стать NotReady ?
  2. Мне также известна эта статья https://kubernetes.io/docs/concepts/architecture/nodes/#node-status, в которой упоминается полный список состояний узлов: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Интересно, если какой-либо из {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} станет истинным для узла, станет ли этот узел NotReady?
  3. Какие негативные последствия я могу получить после отключения «Автоматического восстановления узла» в кластере? Мне в основном интересно, можем ли мы в конечном итоге оказаться в худшем положении, чем автоматически ремонтируемые узлы и недавно присоединенный, но не в белый список, IP . Если «Автоматическое восстановление узла» отключено, то для модулей, работающих на нездоровом узле, который был бы автоматически восстановлен, Kubernetes будет создавать новые модули на других узлах?

1 Ответ

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

Путаница заключается в том, что существуют состояния «Готово» и «Не готово», которые отображаются при запуске kubectl get nodes, о которых сообщает kube-apiserver. Но они независимы и неясны из документов, как они связаны с состояниями кубелетов, описанными здесь Вы также можете видеть состояния кубелетов (в событиях) при запуске kubectl describe nodes

Чтобы ответить на некоторые части вопросов:

  1. Как сообщает kube-apiserver

    • Кубеле вниз
    • докер, контейнер или пух (в зависимости от используемой вами прокладки)
    • Состояния Кубеле - неясно.

  2. Для них kubelet начнет выселять или не планировать блоки, кроме как для Ready (https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/). Из документов неясно, как они поступают с сервера kubeapi.

    • У вас могут быть узлы в вашем кластере, которые не используются, и вы будете платить за это.
    • Да, k8s перепланирует стручки после сбоя определенных проб готовности (настраивается). Если кублет не работает или узел не работает, k8s будет считать, что стручки не работают.
    • Предполагая, что ваши узлы выйдут из строя, вы можете получить меньшую емкость, чем то, что вам нужно для планирования ваших рабочих нагрузок, чтобы k8s не смог их запланировать в любом случае.

Надеюсь, это поможет!

...