Введение в службу Kubernetes DNS

Введение

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

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

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

Что предоставляет служба 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 с соответствующими опциями поиска, позволяющими использовать более короткие имена хостов:

  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 в спецификации пода:

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 для служб и подов.