Проблемы с DNS в пуле вытесняемых узлов в GKE: конечные точки службы kube-dns сохраняют неисправные модули

У меня есть кластер GKE k8s (k8s 1.22), состоящий из вытесняемых узлов. Только, который включает в себя критически важные службы, такие как kube-dns. Это машина для разработки, которая может выдержать несколько минут в день. Каждый раз, когда отключается узел, на котором размещен модуль kube-dns, я сталкиваюсь с проблемами разрешения DNS, которые сохраняются до тех пор, пока я не удалю неисправный модуль (в версии 1.21 модули остаются «Статус: сбой» / «Причина: завершение работы», пока не будут удалены вручную) .

Хотя я ожидаю некоторых проблем с вытесняемыми узлами во время их повторного использования, я ожидаю, что это самовосстанавливается через несколько минут. Основная причина постоянных проблем, по-видимому, заключается в том, что неисправный модуль не удаляется из k8s. Оказание услуг / Конечная точка. Вот что я вижу в системе:

Статус подов через kubectl -n kube-system get po -l k8s-app=kube-dns

ИМЯ ГОТОВ СТАТУС ПЕРЕЗАПУСКА ВОЗРАСТ
kube-dns-697dc8fc8b-47rxd 4/4 прекращено 0 43h
kube-dns-697dc8fc8b-mkfrp 4/4 Бег 0 78м
kube-dns-697dc8fc8b-zfvn8 4/4 работает 0 19ч

IP-адрес отказавшего модуля — 192.168.144.2 — и он по-прежнему указан как одна из конечных точек службы:

kubectl -n kube-system описать ep kube-dns приносит это:

Имя: kube-dns
Пространство имен: kube-system
Ярлыки: addonmanager.kubernetes.io/mode=Согласовать
              k8s-приложение = кубе-dns
              kubernetes.io/cluster-service=true
              kubernetes.io/name=КубеDNS
Аннотации: endpoints.kubernetes.io/last-change-trigger-time: 2022-02-21T10:15:54Z
Подмножества:
  Адреса: 192.168.144.2,192.168.144.7,192.168.146.29
  NotReadyAddresses: <нет>
  Порты:
    Имя Порт Протокол
    ---- ---- --------
    DNS-TCP 53 TCP
    DNS 53 UDP

События: <нет>

Я знаю, что другие работали над решением этих проблем, Планирование kube-dns для других модулей, но я бы предпочел вместо этого сделать это самовосстановлением, поскольку сбои узлов все еще могут происходить на невытесняемых узлах, просто они менее вероятны.

Мои вопросы:

• Почему отказавший модуль по-прежнему указан как одна из конечных точек службы даже через несколько часов после сбоя первоначального узла?
• Что я могу сделать, чтобы смягчить проблему (кроме добавления некоторых неэфемерных узлов)?

Кажется, что kube-dns в развертывании по умолчанию в GKE не имеет зонда готовности, подключенного к dnsmasq (порт 53), который предназначен для службы kube-dns, и это может решить проблему, но я подозреваю, что это не так. там по причине, которую я пока не понимаю.

РЕДАКТИРОВАТЬ: по-видимому, это делает нет бывает на 1.21.6-гке.1500 (обычный канал), но бывает и на 1.22.6-гке.1500 (быстрый канал). У меня нет хорошего объяснения, но, несмотря на то, что сегодня у меня было несколько неудачных модулей, служба kube-dns содержит только рабочие.

Вытесняемые узлы не рекомендуются для выполнения критических рабочих нагрузок, таких как kube-dns (1), так что таких ситуаций следует ожидать.

Вы можете попытаться смягчить проблему, пометив pod как критический (2), используя автоматическую подготовку узла (3) или PodDisruptionBudget (4).
Дополнительная информация по этой теме содержится в этом документе (5).

Кроме того, некоторые предложения уже поступили в Google (6).

Если ни один из них не решит вашу проблему, вы можете сообщить об этом через Отслеживание общедоступных проблем.

Это начало происходить и на моем env (вытесняемые узлы на gke), и это происходит со всеми развертываниями, но kube-dns является наиболее важным. Я думаю, это может быть связано с ревизияHistoryLimit параметр. Значение по умолчанию — 10, поэтому старые реплики до 10 будут присутствовать в течение некоторого периода времени. Я установил его на 0 и ожидаю, что узлы будут заменены, посмотрим :)