Что делает узел kubernetes нездоровым?
Мы пережили 4 AUTO_REPAIR_NODES
события (раскрытые командой gcloud container operations list
) в нашем кластере GKE за последние 1 месяц. Следствием автоматического восстановления узла является то, что узел воссоздается и получает новый внешний IP-адрес, а новый внешний IP-адрес, который не был добавлен в белый список сторонними службами, в конечном итоге вызывал сбой служб, работающих на этом новом узле.
Я заметил, что в нашем кластере Kubernetes у нас включено " Автоматическое восстановление узла ", и мне хотелось отключить это, но прежде чем я это сделаю, мне нужно больше узнать о ситуации.
Мои вопросы:
- Каковы некоторые общие причины, которые делают узел нездоровым в первую очередь? Мне известна эта статья https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair которой говорится: "узел сообщает о состоянии NotReady при последовательных проверках заданного порог времени "вызовет авто ремонт. Но что может заставить узел стать NotReady?
- Мне также известна эта статья https://kubernetes.io/docs/concepts/architecture/nodes/ которой упоминается полный список состояний узлов: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Интересно, если какой-либо из {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} станет истинным для узла, станет ли этот узел NotReady?
- Какие негативные последствия я могу получить после отключения "Автоматического восстановления узла" в кластере? Я в основном задаюсь вопросом, можем ли мы в конечном итоге оказаться в худшем положении, чем автоматически ремонтируемые узлы и недавно подключенный, но не белый список IP. Как только "Автоматическое восстановление узла" отключено, тогда для модулей, работающих на нездоровом узле, который был бы автоматически восстановлен, Kubernetes будет создавать новые модули на других узлах?
1 ответ
Мастер по существу выполняет проверку работоспособности на узле. если узел не может ответить, или если узел объявляет себя NotReady, он будет восстановлен посредством авторемонта узла. На узлах GKE есть также детектор проблем узлов, который может обнаруживать проблемы в ОС.
Любое из упомянутых условий может привести к переходу узла в NotReady. Есть и другие возможные факторы, такие как повторяющиеся ошибки на уровне ОС.
Отключение автоматического восстановления узлов может привести к тому, что узлы перейдут на NotReady и останутся такими. Хотя во многих случаях узел пытается решить проблему, убивая модули или процессы, возможно, что узел застревает в NotReady
Вместо того, чтобы отключать автоматическое восстановление узла, я бы рекомендовал изменить настройки из-за требования белого списка. Вместо этого вы можете настроить шлюз NAT для всего исходящего трафика GKE; Вы можете назначить статический IP-адрес NAT и просто беспокоиться о внесении белого списка в этот IP-адрес. Вам больше не придется беспокоиться об изменении IP-адресов узлов.