Облачная платформаAdvanced

Конфигурация DNS

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

В каждом кластере Kubernetes встроен аддон DNS (Kube-DNS или CoreDNS), обеспечивающий разрешение доменных имён для рабочих нагрузок в кластере. При обработке большого количества одновременных DNS‑запросов Kube-DNS/CoreDNS может столкнуться с узким местом производительности, то есть иногда может не успевать выполнять DNS‑запросы. Рабочие нагрузки Kubernetes иногда генерируют лишние DNS‑запросы, что может перегрузить систему DNS в периоды высокой конкуренции запросов. Настройка конфигурации DNS для рабочих нагрузок снизит риск отказов DNS‑запросов в некоторой степени.

Для получения дополнительной информации о DNS см. CoreDNS.

Элементы конфигурации DNS

Выполните команду cat /etc/resolv.conf на узле Linux или в контейнере, чтобы просмотреть файл конфигурации DNS‑резольвера. Ниже приведён пример конфигурации DNS‑резольвера контейнера в кластере Kubernetes:

 nameserver  10.247.x.x
 search  default.svc.cluster.local svc.cluster.local cluster.local
 options  single-request-reopen timeout:2 ndots:5

Параметры конфигурации

nameserver: список IP‑адресов серверов имён, к которым будет обращаться резольвер. Если IP‑адрес находится в диапазоне service CIDR кластера (например, 10.247.x.x в приведённом выше примере), это CoreDNS ClusterIP, и используется разрешение Kube-DNS/CoreDNS. В противном случае используется внешний DNS (управляемый облаком или самостоятельный).

search: список поиска для разрешения имён хостов. Когда доменное имя не может быть разрешено, DNS‑запросы будут выполняться, комбинируя доменное имя с каждым доменом из списка поиска последовательно, пока не будет найдено совпадение или не будут исчерпаны все домены списка. Для кластеров CCE список поиска в настоящее время ограничен тремя доменами на контейнер. При попытке разрешить несуществующее доменное имя будет инициировано восемь DNS‑запросов, поскольку каждое доменное имя (включая те, что находятся в списке поиска) будет запрошено дважды: один раз для IPv4 и один раз для IPv6.

options: дополнительные параметры в файле конфигурации DNS. Распространённые параметры включают timeout и ndots.

Значение ndots:5 означает, что если в доменном имени менее пяти точек (.), DNS‑запросы будут выполняться, комбинируя доменное имя с каждым доменом из списка поиска последовательно. Если после перебора всех доменов списка поиск не дал результата, доменное имя будет использовано для DNS‑запросов. Если в доменном имени пять и более точек, оно будет использовано в первую очередь для DNS‑запросов. В случае, когда доменное имя не может быть разрешено, DNS‑запросы будут выполняться, комбинируя доменное имя с каждым доменом из списка поиска последовательно.

Например, доменное имя www.***.com содержит только две точки (меньше значения ndots). Поэтому последовательность разрешения DNS выглядит следующим образом: www.***.com.default.svc.cluster.local, www.***.com.svc.cluster.local, www.***.com.cluster.local и www.***.com. Это означает, что будет инициировано как минимум семь DNS‑запросов, прежде чем домен будет разрешён в IP‑адрес. Такая конфигурация приводит к большому количеству избыточных DNS‑запросов при обращении к внешним доменным именам, что указывает на явные возможности для оптимизации.

Note

Подробную информацию о параметрах конфигурации файла DNS‑резольвера Linux см. в https://man7.org/linux/man-pages/man5/resolv.conf.5.html.

Настройка DNS для рабочей нагрузки через консоль

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

Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.

В панели навигации выберите Workloads. В правом верхнем углу нажмите Create Workload.

Настройте базовую информацию о workload. Для получения подробностей см. Creating a Workload.

В области Advanced Settings нажмите вкладку DNS и задайте следующие параметры по требованию:

DNS Policy: Политики DNS, предоставляемые в консоли, соответствуют полю dnsPolicy в файле YAML. Для получения подробностей см. Table 1.

Supplement defaults: соответствует dnsPolicy=ClusterFirst. Контейнеры могут разрешать как внутренние доменные имена кластера, зарегистрированные Service, так и внешние доменные имена, доступные в публичных сетях.

Replace defaults: соответствует dnsPolicy=None. Необходимо настроить IP Address и Search Domain. Контейнеры используют только пользовательские настройки IP Address и Search Domain для разрешения доменных имён.

Inherit defaults: соответствует dnsPolicy=Default. Контейнеры используют конфигурацию разрешения доменных имён узла, на котором запущены pod, и не могут разрешать внутренние доменные имена кластера.

Optional Objects: Параметры options в поле dnsConfig. Каждый объект может иметь свойство name (обязательно) и свойство value (необязательно). После задания свойств нажмите confirm to add.

timeout: интервал тайм‑аута в секундах.

ndots: Количество точек (.) , которые должны присутствовать в доменном имени. Если в доменном имени точек меньше указанного значения, операционная система выполнит поиск имени в поисковой доменной зоне. В противном случае имя считается полностью квалифицированным доменным именем (FQDN) и будет сначала рассматриваться как абсолютное.

IP Address of DNS Server: nameservers в dnsConfig. Вы можете настроить сервер доменных имён для пользовательского домена. Значение — один или группа DNS IP addresses. Можно добавить не более двух DNS IP addresses.

Search Domain: searches в dnsConfig. Список DNS‑search‑domains для поиска имени хоста в pod. Это свойство необязательно. При указании предоставленный список будет объединён с именами поисковых доменов, сформированными на основе выбранной DNS policy в dnsPolicy. Дублирующие доменные имена удаляются. Можно добавить не более трёх поисковых доменов.

Host Alias: Добавьте сопоставление доменных имён и IP‑address в локальный конфигурационный файл /etc/hosts pod для упрощённого локального разрешения доменных имён. Для получения подробностей см. Adding entries to Pod /etc/hosts with HostAliases

Нажмите Create Workload.

Настройка DNS с использованием Workload YAML

При создании рабочей нагрузки с помощью YAML‑файла вы можете настроить параметры DNS в YAML. Ниже приведён пример для приложения Nginx:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: container-1
          image: nginx:latest
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: default-secret
       dnsPolicy : None
       dnsConfig: 
         options: 
          - name: ndots
            value: '5'
          - name: timeout
            value: '3'
         nameservers: 
          - 10.2.3.4
         searches: 
          - my.dns.search.suffix

dnsPolicy

Поле dnsPolicy используется для настройки политики DNS для приложения. Значение по умолчанию — ClusterFirst. В следующей таблице перечислены конфигурации dnsPolicy.

Таблица 1 dnsPolicy
Параметр	Описание
ClusterFirst (значение по умолчанию)	Пользовательская конфигурация DNS добавляется к конфигурации DNS по умолчанию. По умолчанию приложение подключается к CoreDNS (CoreDNS кластера CCE подключается к DNS в облаке по умолчанию). Пользовательский dnsConfig будет добавлен к параметрам DNS по умолчанию. Контейнеры могут разрешать как внутренние доменные имена кластера, зарегистрированные Service, так и внешние доменные имена, доступные в публичных сетях. В файле конфигурации DNS присутствуют список поиска (search option) и ndots: 5. Поэтому при обращении к внешнему доменному имени и к длинному внутреннему доменному имени кластера (например, kubernetes.default.svc.cluster.local) список поиска обычно обрабатывается первым, что приводит к минимум шести недействительным DNS‑запросам. Проблема недействительных DNS‑запросов исчезает только при обращении к короткому внутреннему доменному имени кластера (например, kubernetes).
ClusterFirstWithHostNet	По умолчанию приложения, настроенные с host network, соединяются с конфигурацией DNS узла, на котором расположен pod. Конфигурация DNS указывается в DNS‑файле, на который указывает параметр kubelet --resolv-conf. В этом случае кластер CCE использует DNS в облаке. Чтобы соединиться с Kubernetes DNS или CoreDNS кластера, установите dnsPolicy в значение ClusterFirstWithHostNet. В этом случае конфигурация файла разрешения имён контейнера совпадает с конфигурацией ClusterFirst, и возникают недействительные DNS‑запросы. ... spec: containers: - image: nginx:latest imagePullPolicy: IfNotPresent name: container-1 restartPolicy: Always hostNetwork: true dnsPolicy: ClusterFirstWithHostNet
Default	Конфигурация DNS узла, на котором расположен pod, наследуется, а пользовательская конфигурация DNS добавляется к наследуемой конфигурации. Файл конфигурации DNS контейнера — это файл DNS, на который указывает флаг kubelet --resolv-conf. В этом случае для кластеров CCE используется облачный DNS. Параметры search и options оставлены неопределёнными. Такая конфигурация может разрешать только внешние доменные имена, зарегистрированные в Интернете, и не может разрешать внутренние доменные имена кластера. Эта конфигурация не имеет проблемы недействительных DNS‑запросов.
None	Конфигурация DNS по умолчанию заменяется пользовательской конфигурацией DNS, и используется только пользовательская конфигурация DNS. Если dnsPolicy установлен в None, необходимо указать поле dnsConfig, поскольку все параметры DNS должны быть заданы с помощью поля dnsConfig.

Note

Если поле dnsPolicy не указано, значение по умолчанию — ClusterFirst, а не Default.

dnsConfig

Поле dnsConfig используется для настройки параметров DNS для рабочих нагрузок. Настроенные параметры объединяются в файл конфигурации DNS, созданный в соответствии с dnsPolicy. Если dnsPolicy установлен в None, файл конфигурации DNS рабочей нагрузки указывается полем dnsConfig. Если dnsPolicy не установлен в None, параметры DNS, настроенные в dnsConfig, добавляются в файл конфигурации DNS, созданный в соответствии с dnsPolicy.

Таблица 2 dnsConfig
Параметр	Описание
options	Необязательный список объектов, каждый из которых может иметь свойство name (обязательно) и свойство value (необязательно). Содержимое этого свойства будет объединено с параметрами, сгенерированными из указанной DNS‑политики в dnsPolicy. Дублирующие записи удаляются.
nameservers	Список IP‑адресов, которые будут использоваться в качестве DNS‑серверов. Если dnsPolicy рабочей нагрузки установлен в None, этот список должен содержать как минимум один IP‑адрес. В остальных случаях параметр является необязательным. Перечисленные серверы будут объединены с nameservers, сгенерированными из указанной DNS‑политики в dnsPolicy, при этом дублирующие адреса удаляются. ПРИМЕЧАНИЕ: Для nameserver в файле конфигурации DNS контейнера можно настроить не более трёх DNS‑адресов. Если dnsPolicy установлен в ClusterFirst и кластер использует CoreDNS, можно добавить два пользовательских DNS‑адреса в дополнение к адресу CoreDNS. Избыточные DNS‑адреса считаются недействительными. Если dnsPolicy установлен в ClusterFirst и кластер использует CoreDNS и NodeLocal DNSCache, можно добавить один пользовательский DNS‑адрес в дополнение к адресам CoreDNS и NodeLocal DNSCache. Избыточные DNS‑адреса считаются недействительными.
searches	Список доменов поиска DNS для разрешения имён хостов в pod. Это свойство необязательно. При указании предоставленный список будет объединён с именами доменов поиска, сгенерированными на основе выбранной DNS‑политики в dnsPolicy. Дублирующие имена доменов удаляются.

Примеры конфигурации

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

Сценарий использования 1: Использование Kube-DNS/CoreDNS, встроенного в кластеры Kubernetes

Сценарий

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

Пример:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
  - name: test
    image: nginx:alpine
   dnsPolicy: ClusterFirst 
  imagePullSecrets:
    - name: default-secret

Файл конфигурации DNS контейнера:

nameserver 10.247.3.10
search default.svc.cluster.local svc.cluster.local cluster.local
options timeout:2 single-request-reopen ndots:5

Сценарий использования 2: Использование облачного DNS

Сценарий

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

Пример:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
  - name: test
    image: nginx:alpine
   dnsPolicy: Default   # The DNS configuration file that the kubelet  --resolv-conf  parameter points to is used. In this case, the CCE cluster uses the DNS on the cloud.
  imagePullSecrets:
    - name: default-secret

Файл конфигурации DNS контейнера выглядит следующим образом: (100.125.x.x — это DNS-адрес подсети узла.)

nameserver  100.125.x.x 
options timeout:2 single-request-reopen

Сценарий использования 3: Использование Kube-DNS/CoreDNS для рабочих нагрузок, работающих с hostNetwork

Сценарий

По умолчанию для рабочих нагрузок, работающих с hostNetwork, используется DNS. Если рабочим нагрузкам необходимо использовать Kube-DNS/CoreDNS, задайте dnsPolicy значение ClusterFirstWithHostNet.

Пример:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
   hostNetwork: true 
   dnsPolicy: ClusterFirstWithHostNet 
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  imagePullSecrets:
    - name: default-secret

Файл конфигурации DNS контейнера:

nameserver  10.247.3.10 
search  default.svc.cluster.local svc.cluster.local cluster.local 
options ndots:5 single-request-reopen timeout:2

Сценарий использования 4: Настройка DNS конфигурации приложения

Сценарий

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

Пример 1: Использование вашего локального DNS

Установите dnsPolicy в None, чтобы файл конфигурации DNS приложения генерировался на основе dnsConfig.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
  - name: test
    image: nginx:alpine
  dnsPolicy: "None"
  dnsConfig:
     nameservers: 
     - 10.2.3.4  # IP address of your on-premises DNS 
     searches: 
     - ns1.svc.cluster.local 
     - my.dns.search.suffix 
     options: 
     - name: ndots 
       value: "2" 
     - name: timeout 
       value: "3" 
  imagePullSecrets:
    - name: default-secret

Файл конфигурации DNS контейнера:

nameserver  10.2.3.4 
search  ns1.svc.cluster.local my.dns.search.suffix 
options  timeout:3 ndots:2  single-request-reopen

Пример 2: Изменение параметра ndots в файле конфигурации DNS для снижения количества недействительных DNS‑запросов

Установите dnsPolicy в значение, отличное от None, чтобы параметры DNS, настроенные в dnsConfig, были добавлены в файл конфигурации DNS, генерируемый на основе dnsPolicy.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
  - name: test
    image: nginx:alpine
  dnsPolicy:  "ClusterFirst" 
  dnsConfig:
    options:
    -  name: ndots 
       value: "2" # The ndots:5 option in the DNS configuration file generated based on the ClusterFirst policy is changed to ndots:2. 
  imagePullSecrets:
    - name: default-secret

Файл конфигурации DNS контейнера:

nameserver 10.247.3.10
search default.svc.cluster.local svc.cluster.local cluster.local
options  ndots:2  single-request-reopen timeout:2

Пример 3: Использование нескольких DNS в последовательной цепочке

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
  - name: test
    image: nginx:alpine
   dnsPolicy: ClusterFirst  # Added DNS configuration. The cluster connects to CoreDNS by default. 
  dnsConfig:
     nameservers: 
     - 10.2.3.4 # IP address of your on-premises DNS 
  imagePullSecrets:
    - name: default-secret

Note

Для сервера имен в файле конфигурации DNS контейнера можно настроить не более трех DNS‑адресов.

Если dnsPolicy установлен в ClusterFirst и кластер использует CoreDNS, вы можете добавить два пользовательских DNS‑адреса к адресу CoreDNS. Избыточные DNS‑адреса недействительны.

Если dnsPolicy установлен в ClusterFirst и кластер использует CoreDNS и NodeLocal DNSCache, вы можете добавить один пользовательский DNS‑адрес к адресам CoreDNS и NodeLocal DNSCache. Избыточные DNS‑адреса недействительны.

Файл конфигурации DNS контейнера:

nameserver 10.247.3.10 
nameserver  10.2.3.4 
search default.svc.cluster.local svc.cluster.local cluster.local
options timeout:2 single-request-reopen ndots:5

Родительская тема: DNS

Предыдущая статья

DNS Обзор

Следующая статья

Использование CoreDNS для пользовательского разрешения доменных имен

Эта статья полезна?

Поддержка Юридические документы Политика конфиденциальности