One place for hosting & domains

      Введение в службу 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 в спецификации пода:

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



      Source link