Назад | Перейти на главную страницу

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

Мы испытали 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 который говорит: "узел сообщает о Не готов статус при последовательных проверках в течение заданного порогового времени "вызовет автоматическое восстановление. Но что может привести к тому, что узел станет Не готов?
  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. По сути, мастер выполняет проверку работоспособности узла. если узел не может ответить или если узел объявляет себя NotReady, он будет отремонтирован с помощью авторемонта узла. На узлах GKE также есть детектор проблем с узлами, который может обнаруживать проблемы в ОС.

  2. Любое из упомянутых условий может привести к переходу узла в NotReady. Есть и другие возможные факторы, такие как повторяющиеся ошибки на уровне ОС.

  3. Отключение автоматического восстановления узлов может привести к тому, что узлы перейдут в состояние NotReady и останутся в таком состоянии. Хотя во многих случаях узел пытается решить проблему, убивая модули или процессы, возможно, что узел застревает в NotReady.

Вместо того, чтобы отключать автоматическое восстановление узлов, я бы порекомендовал изменить вашу настройку из-за требования о внесении в белый список. Вместо этого вы можете настроить шлюз NAT для всего исходящего трафика GKE; вы можете назначить статический IP-адрес для NAT и просто беспокоиться о добавлении этого IP-адреса в белый список. Вам больше не придется беспокоиться о том, что узлы меняют IP-адреса.