Введение
Система доменных имен 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
в спецификации пода:
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 для служб и подов.