Какое DNS-имя для сервисов в разных пространствах имен в k8s?

Question

В пространстве имен A у меня запущена служба nginx. В пространстве имен B я могу использовать nginx.A или nginx.A.svc.cluster.local, чтобы получить доступ к nginx в пространстве имен A.

Так в чем же разница между этими двумя? Какой из них больше рекомендуется? Почему?

Answer 1

Обе формы считаются правильными (сравните с этой статьей) и в большинстве случаев работают нормально, однако я мог найти несколько проблем на github когда люди сталкивались с проблемами, связанными только с разрешением коротких имен, например:

https://github.com/kubernetes/dns/issues/109

https://github.com/kubernetes/kubernetes/issues/10014

Как вы можете прочитать на официальном сайте Kubernetes В документации ( ref1 , ref2 ) рекомендуется использовать длинную форму для доступа к службам в пространствах имен:

При создании службы онасоздает соответствующую запись DNS. Эта запись имеет вид <service-name>.<namespace-name>.svc.cluster.local, что означает, что если контейнер просто использует <service-name>, он будет преобразован в службу, локальную для пространства имен. Это полезно для использования одной и той же конфигурации в нескольких пространствах имен, таких как разработка, подготовка и производство. Если вы хотите охватить пространства имен, вам нужно использовать полное доменное имя (FQDN) .

На мой взгляд, гораздо лучше придерживаться FQDN (полное доменное имя) стандартное и часто явное, считается лучшей практикой, чем неявное.

Answer 2

Это эквивалентно. Если вы посмотрите на файл resolv.conf по умолчанию, который внедряется в каждый контейнер:

search mynamespace.svc.cluster.local svc.cluster.local cluster.local mydomain
options ndots:5

, вы увидите, что он автоматически запросит у вас цепочку. Это предполагает, что вы используете поведение DNS-клиента Linux по умолчанию. Если у вас есть свой собственный распознаватель, он может не понимать синтаксис частичного поиска, хотя большинство проверяет resolv.conf.