Основы сервиса DNS Kubernetes

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

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

Читайте также:

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

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

Независимо от программного обеспечения, обрабатывающего фактические записи DNS, обе реализации работают одинаково:

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

nameserver 10.32.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

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

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

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

service.namespace.svc.cluster.local

Запись пода создается в этом формате (он отражает фактический IP-адрес пода):

10.32.0.125.namespace.pod.cluster.local

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

_port-name._protocol.service.namespace.svc.cluster.local

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

Search domain и разрешение коротких имен хостов

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

other-service

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

other-service.other-namespace

Если у вас есть целевой под, вам нужно будет использовать такой формат:

pod-ip.other-namespace.pod

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

Ознакомившись с практическим использованием сервиса DNS Kubernetes, давайте рассмотрим некоторые детали двух разных реализаций.

Особенности реализаций Kubernetes DNS

Как отмечалось в предыдущем разделе, в Kubernetes версии 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, в системе становится общедоступным новый сервис DNS, CoreDNS. Это означает, что он готов к работе в среде производства и является сервисом DNS кластера по умолчанию для многих инструментов установки и управляемых провайдеров Kubernetes.

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

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

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

Больше информации о CoreDNS и их отличиях с kube-dns можно найти по этой ссылке.

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

Операторы Kubernetes часто хотят кастомизировать то, как их поды и контейнеры разрешают определенные пользовательские домены. Также бывает нужно настроить вышестоящие серверы имен или суффиксы search domain, указанные в 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 .

Заключение

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

Больше информации о Kubernetes DNS можно найти в официальной документации.

Tags: ,

Добавить комментарий