Перестали работать разрешения DNS в кластере GKE - PullRequest
0 голосов
/ 25 октября 2019

Так что это работает вечно. У меня есть несколько простых служб, работающих в 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-gke.14

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

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

Ответы [ 3 ]

1 голос
/ 26 октября 2019

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

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

resource.type = "container"

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

Не забудьте проверить журналы для каждого контейнера. Поскольку точные имена и номера контейнеров могут меняться в зависимости от версии 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 система кубов -l k8s-app = kube-dns -o \

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

Модуль kube-dns содержит четыре контейнера: *Процесс 1028 *

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

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

resource.type = "container"resource.labels.cluster_name =»"resource.labels.namespace_id = "Kube-система"LogName = "проекты // Журналы / Dnsmasq»«Достигнуто максимальное количество одновременных DNS-запросов»

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

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

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

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

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

0 голосов
/ 27 октября 2019

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

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

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

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

0 голосов
/ 26 октября 2019

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

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

...