Перестали работать разрешения DNS в кластере GKE

Question

Так что это работает вечно. У меня есть несколько простых служб, работающих в GKE, и они ссылаются друг на друга через стандартные DNS-имена service.namespace.

Сегодня перестало работать все разрешение имен DNS. Я ничего не менял, хотя это могло быть вызвано главным обновлением.

/ambassador # nslookup ambassador-monitor.default
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'ambassador-monitor.default': Try again


/ambassador # cat /etc/resolv.conf  
search default.svc.cluster.local svc.cluster.local cluster.local c.snowcloud-01.internal google.internal 
nameserver 10.207.0.10 
options ndots:5

Мастер версия 1.14.7-гке.14

Я могу говорить о кросс-сервисах, используя их IP-адреса, просто DNS не работает.

Не совсем уверен, что с этим делать...

Answer 1

Самый простой способ проверить, есть ли проблема с вашим Kube DNS, - это просмотреть журналы StackDriver [https://cloud.google.com/logging/docs/view/overview].

Вы сможете найти сбои разрешения DNS в журналах для модулей с помощью следующего фильтра:

resource.type="контейнер"

("UnknownHost" ИЛИ "ошибка поиска" ИЛИ "ошибка")

Обязательно проверьте журналы для каждого контейнера. Поскольку точные имена и номера контейнеров могут измениться с версией GKE, вы можете найти их так:

kubectl get pod -n kube-system -l k8s-app=kube-dns -o \

jsonpath='{range.items[*].spec.containers[*]}{.name}{"\n"}{end}' | sort -u kubectl get pods -n kube-system -l k8s-app=kube-dns

Модуль часто перезапускался? Ищите OOM в консоли узла. Узлы для каждого модуля можно найти так:

kubectl get pod -n kube-system -l k8s-app=kube-dns -o \

jsonpath='{range.items[*]}{.spec.nodeName} pod={.metadata.name}{"\n"}{end}'

В kube-dns стручок содержит четыре контейнера:

• kube-dns процесс наблюдает за изменениями в службах и конечных точках мастера Kubernetes и поддерживает структуры поиска в памяти для обслуживания запросов DNS,
• dnsmasq добавляет кеширование DNS для повышения производительности,
• sidecar обеспечивает единую конечную точку проверки работоспособности при выполнении двойной проверки работоспособности (для dnsmasq а также kubedns). Он также собирает метрики dnsmasq и предоставляет их в формате Prometheus,
• prometheus-to-sd очистка показателей, представленных sidecar и отправив их в Stackdriver.

По умолчанию dnsmasq контейнер принимает 150 одновременных запросов. Запросы сверх этого просто отбрасываются и приводят к неудачному разрешению DNS, включая разрешение для metadata. Чтобы проверить это, просмотрите журналы со следующим фильтром:

resource.type="container"
resource.labels.cluster_name =""
resource.labels.namespace_id ="kube-system"
logName ="projects // logs / dnsmasq"
"Максимальное количество достигнуты одновременные запросы DNS "

Если устаревшее ведение журнала stackdriver кластера отключено, используйте следующий фильтр:

resource.type="k8s_container"
resource.labels.cluster_name =""
resource.labels.namespace_name ="kube-system"
resource.labels.container_name ="dnsmasq"
"Достигнуто максимальное количество одновременных DNS-запросов"

Если ведение журнала Stackdriver отключено, выполните следующие действия:

журналы kubectl --tail=1000 --namespace=kube-system -l k8s-app=kube-dns -c dnsmasq | grep 'Достигнуто максимальное количество одновременных DNS-запросов'

Кроме того, вы можете попробовать использовать команду [dig ambassador-monitor.default @10.207.0.10] из каждого узла, чтобы проверить, влияет ли это только на один узел. Если это так, вы можете просто воссоздать затронутый узел.

Answer 2

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

Создание нового пула с предыдущей версией (1.14.7-gke.10) и переход на него исправили все.

Мне сказали, что исправление уже отправлено.

Спасибо вам за ваши предложения.

Answer 3

Начните с отладки ваших kubernetes-сервисов [1]. Это скажет вам, проблема ли связана с ресурсами k8s или сам кубернет дает сбой. Как только вы это поймете, можете приступить к исправлению. Вы можете опубликовать результаты здесь, если хотите следить.

[1] https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/