Table of Contents

Введение

Система доменных имен DNS — это система связи различных типов информации, например связи IP адресов с легко запоминающимися именами. По умолчанию большинство кластеров Kubernetes автоматически настраивают внутреннюю службу DNS в качестве компактного механизма поиска служб. Встроенная система обнаружения служб позволяет приложениям легко находить друг друга и взаимодействовать друг с другом на кластерах Kubernetes, даже в случае создания подов и служб, их удаления и перемещения между узлами.

В последних версиях Kubernetes изменены детали реализации службы DNS. В этой статье мы рассмотрим версии kube-dns и CoreDNS службы Kubernetes DNS. Мы расскажем о том, как они работают, и о генерируемых Kubernetes записях DNS.

Чтобы лучше понять принципы работы службы DNS прочитайте статью _«Введение в терминологию, компоненты и концепции DNS»_. Чтобы узнать больше о любых аспектах Kubernetes, с которыми вы не знакомы, вы можете прочитать статью _«Введение в Kubernetes»_.

Что предоставляет служба Kubernetes DNS?

kubernetes dns illustration for: Что предоставляет служба Kubernetes DNS?

До выпуска версии Kubernetes 1.11 служба Kubernetes DNS была основана на kube-dns. В версии 1.11 появилась версия службы CoreDNS, устраняющая ряд проблем kube-dns со стабильностью и безопасностью.

Вне зависимости от того, какое программное обеспечение обрабатывает записи DNS, оба варианта работают одинаково:

  • Создается служба с именем kube-dns и один или несколько подов.
  • Служба kube-dns прослушивает события службы и события конечных точек через Kubernetes API и обновляет записи DNS по мере необходимости. Эти события активируются при создании, обновлении или удалении служб Kubernetes и связанных с ними подов.
  • kubelet задает опцию /etc/resolv.conf nameserver для каждого нового пода как IP-адрес кластера службы kube-dns с соответствующими опциями поиска, позволяющими использовать более короткие имена хостов:
				
					
   [label resolv.conf]

   nameserver 10.32.0.10

   search namespace.svc.cluster.local svc.cluster.local cluster.local

   options ndots:5
  • Работающие в контейнерах приложения могут разрешать такие имена хостов как example-service.namespace в корректные IP-адреса кластера.

Пример записей Kubernetes DNS

Полная запись DNS A службы Kubernetes будет выглядеть, как показано в следующем примере:

				
					
<^>service<^>.<^>namespace<^>.svc.cluster.local

Под будет иметь запись в этом формате, отражающую фактический IP-адрес пода:

				
					
<^>10.32.0.125<^>.<^>namespace<^>.pod.cluster.local

Кроме того, создаются дополнительные записи SRV для именованных портов службы Kubernetes:

				
					
_<^>port-name<^>._<^>protocol<^>.<^>service<^>.<^>namespace<^>.svc.cluster.local

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

Поиск доменов и разрешение коротких имен хостов

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

				
					
<^>other-service<^>

Если служба находится в другом пространстве имен, его нужно добавить в запрос:

				
					
<^>other-service<^>.<^>other-namespace<^>

Если вы хотите связаться с подом, вам потребуется как минимум следующее:

				
					
<^>pod-ip<^>.<^>other-namespace<^>.pod

Как мы видели в файле resolv.conf по умолчанию, автоматически заполняются только суффиксы .svc, так что обязательно укажите все вплоть до уровня .pod.

Теперь мы знаем, как применять службу Kubernetes DNS на практике, и можем более детально познакомиться с двумя вариантами ее реализации.

Детали реализации службы Kubernetes DNS

Как было отмечено в предыдущем разделе, в версии Kubernetes version 1.11 было представлено новое программное обеспечение для работы со службой kube-dns. Это изменение было разработано для повышения производительности и безопасности службы. Вначале посмотрим на первоначальную реализацию kube-dns.

kube-dns

Служба kube-dns до версии Kubernetes 1.11 состояла из трех контейнеров, работающих в поде kube-dns в пространстве имен kube-system. Вот эти три контейнера:

  • kube-dns: контейнер, где запускается служба SkyDNS, выполняющая обработку запроса DNS
  • dnsmasq: популярный оптимизированный решатель DNS и система кэширования ответов SkyDNS
  • sidecar: вспомогательный контейнер, отвечающий за отчеты по метрическим показателям и направляющий ответы при проверке состояния службы

В связи с уязвимостями безопасности Dnsmasq и проблемами с производительностью при масштабировании SkyDNS была разработана новая система CoreDNS.

CoreDNS

Начиная с версии Kubernetes 1.11 в качестве основной службы Kubernetes DNS используется служба CoreDNS. Это означает, что данная служба готова к использованию в производственной среде и будет выступать в качестве кластерной службы DNS по умолчанию для различных инструментов установки и управляемых поставщиков Kubernetes.

CoreDNS представляет собой одиночный процесс, написанный на языке Go. Этот процесс охватывает весь диапазон функций предыдущей системы. Единый контейнер разрешает и кэширует запросы DNS, отправляет ответы при проверке состояния и предоставляет метрические показатели.

Помимо устранения проблем с производительностью и безопасностью, в CoreDNS также исправлены некоторые мелкие ошибки и добавлены некоторые новые функции:

  • Исправлены проблемы с несовместимостью при использовании доменов stubDomain и внешних служб
  • CoreDNS может улучшить полную балансировку нагрузки на базе DNS за счет применения случайного порядка возврата определенных записей
  • Функция autopath может улучшить время отклика DNS при разрешении внешних имен хостов за счет использования интеллектуальных функций при итерации суффиксов поиска доменов, перечисленных в файле resolv.conf.
  • С kube-dns 10.32.0.125.namespace.pod.cluster.local всегда разрешается как 10.32.0.125, даже если этот под фактически не существует. CoreDNS использует режим подтверждения подов, при котором разрешение выполняется только в случае существования пода с правильным IP-адресом в правильном пространстве имен.

Дополнительную информацию о службе CoreDNS и ее отличии от kube-dns можно найти в объявлении о выпуске основной версии Kubernetes CoreDNS.

Дополнительные варианты конфигурации

Операторам Kubernetes часто требуется настроить разрешение определенных доменов подами и контейнерами или изменить параметры серверов имен верхнего уровня или суффиксов поиска доменов, которые заданы в файле resolv.conf. Для этого можно использовать опцию dnsConfig в спецификации пода:

				
					
[label example_pod.yaml]

apiVersion: v1

kind: Pod

metadata:

  namespace: example

  name: custom-dns

spec:

  containers:

    - name: example

      image: nginx

  dnsPolicy: "None"

  <^>dnsConfig:<^>

    <^>nameservers:<^>

      <^>- 203.0.113.44<^>

    <^>searches:<^>

      <^>- custom.dns.local<^>

При обновлении этого параметра конфигурации выполняется перезапись файла resolv.conf в поде для активации изменений. Конфигурация напрямую сопоставляется со стандартными опциями resolv.conf, так что вышеуказанная конфигурация создаст файл со строками nameserver 203.0.113.44 и search custom.dns.local.

Заключение

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

Дополнительную информацию о службе Kubernetes DNS можно найти в официальной документации Kubernetes _по службе DNS для служб и подов_.