Проблема с DNS на AWS EKS при работе в частных подсетях

Question

У меня есть настройка кластера EKS в VPC. Рабочие узлы запускаются в частных подсетях. Я могу успешно развертывать модули и службы.

Однако я не могу выполнить разрешение DNS из модулей. (Он отлично работает на рабочих узлах вне контейнера.)

Устранение неполадок при использовании https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ приводит к следующему из nslookup (время ожидания примерно через минуту):

Сервер: 172.20.0.10 Адрес 1: 172.20.0.10

nslookup: не удается разрешить 'kubernetes.default'

Когда я запускаю кластер в общедоступном VPC, у меня нет этой проблемы. Я пропускаю какие-либо необходимые шаги для разрешения DNS из частной подсети?

Большое спасибо, Daniel

Answer 1

Так что я боролся пару часов, думаю, потерял счет времени, и с этой проблемой.

Поскольку я использую VPC по умолчанию, но с рабочими узлами в частной подсети, он не работал.

Я прошел amazon-vpc-cni-k8s и нашел решение.

Мы должны сохранить переменную окружения демона набора aws-узла AWS_VPC_K8S_CNI_EXTERNALSNAT=true.

Вы можете либо получить новый yaml и применить его, либо просто исправить его через панель инструментов. Однако, чтобы это работало, вы должны перезапустить экземпляр рабочего узла, чтобы обновить таблицы маршрутизации ip.

ссылка на номер здесь

thankz

Answer 2

Чтобы уточнить комментарий от @Daniel, вам нужно:

1. правило входа для UDP-порта 53
2. правило входа для UDP на эфемерных портах (например, 1025–65535)

Я не добавил (2) и вижу, что CoreDNS получает запросы и пытается ответить, но ответ не возвращался запрашивающей стороне.

Некоторые советы для других, имеющих дело с подобными проблемами, включите ведение журнала CoreDNS, добавив конфигурацию log в configmap, что я смог сделать с kubectl edit configmap -n kube-system coredns. См. Документы CoreDNS по этому https://github.com/coredns/coredns/blob/master/README.md#examples. Это может помочь вам выяснить, является ли проблема в том, что CoreDNS получает запросы или отправляет ответ обратно.

Answer 3

Я чувствую, что должен дать правильный ответ, потому что ответ на этот вопрос стал для меня ответом на 10 часов отладки. Как сказал @Daniel в своем комментарии, проблема, с которой я столкнулся, заключалась в том, что мой ACL блокировал исходящий трафик через UDP-порт 53, который, очевидно, использует kubernetes для разрешения DNS-записей.

Этот процесс был особенно запутанным для меня, потому что один из моих модулей работал на самом деле все время, так как (я думаю?) Он оказался в той же зоне, что и DNS-преобразователь kubernetes.