Облачная платформа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-адресов name server, который будет запрашиваться резольвером. Если этот параметр установлен в 10.247.x.x, резольвер будет запрашивать kube-dns/CoreDNS. Если этот параметр установлен в другой IP-адрес, резольвер будет запрашивать облачный или локальный DNS сервер.
поиск: список поиска для разрешения имён хостов. Когда доменное имя не может быть разрешено, запросы DNS будут выполняться, комбинируя доменное имя с каждым доменом из списка поиска последовательно, пока не будет найдено совпадение или не будут проверены все домены в списке поиска. Для кластеров CCE список поиска в настоящее время ограничен тремя доменами на контейнер. Когда разрешается несуществующее доменное имя, будет инициировано восемь запросов DNS, потому что каждое доменное имя (включая те, что находятся в списке поиска) будет запрашиваться дважды: один раз для IPv4 и другой раз для IPv6.
опции: опции, позволяющие изменять некоторые внутренние переменные резольвера. Общие опции включают timeout и ndots.
Значение ndots:5 означает, что если у доменного имени менее 5 точек (.), запросы DNS будут осуществляться путем комбинирования доменного имени с каждым доменом из списка поиска поочередно. Если после попытки всех доменов из списка поиска совпадение не найдено, доменное имя затем используется для DNS‑запроса. Если у доменного имени 5 или более точек, оно будет использовано первым для 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 для доступа к внешнему имени домена. Есть возможность улучшить конфигурацию DNS рабочей нагрузки.

Note

Для получения дополнительной информации о параметрах конфигурации в файле конфигурации резольвера, используемом в операционных системах Linux, посетите http://man7.org/linux/man-pages/man5/resolv.conf.5.html.

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

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

Войдите в консоль CCE и нажмите имя кластера, чтобы открыть консоль кластера.
В навигационной панели выберите Рабочие нагрузки. В правом верхнем углу нажмите Создать нагрузку.
Настройте базовую информацию о нагрузке. Для получения подробностей см Создание нагрузки.
В Дополнительные настройки области, нажмите DNS вкладку и установите следующие параметры по требованию:
- Политика DNS: DNS‑политики, предоставленные в консоли, соответствуют dnsPolicy поле в файле YAML. Для получения подробностей см Таблица 1.
  - Дополнить значения по умолчанию: соответствует dnsPolicy=ClusterFirst. Контейнеры могут разрешать как внутренние доменные имена кластера, зарегистрированные Сервисом, так и внешние доменные имена, открытые в публичных сетях.
  - Заменить значения по умолчанию: соответствует dnsPolicy=None. Вы должны настроить IP‑адрес и Поисковый домен. Контейнеры используют только пользовательские настройки IP‑адреса и поискового домена для разрешения имен.
  - Унаследовать значения по умолчанию: соответствует dnsPolicy=Default. Контейнеры используют конфигурацию разрешения доменных имён с узла, на котором работают pod‑ы, и не могут разрешать внутренние доменные имена кластера.
- Опциональные объекты: Параметры опций в поле dnsConfig. Каждый объект может иметь свойство name (обязательно) и свойство value (необязательно). После установки свойств, click подтвердить добавление.
  - тайм‑аут: Интервал тайм‑аута, в секундах.
  - ndots: Количество точек (.) которые должны присутствовать в доменном имени. Если в доменном имени точек меньше этого значения, операционная система выполнит поиск имени в поисковом домене. Если нет, имя считается полным доменным именем (FQDN) и будет сначала попытано как абсолютное имя.
- IP‑адрес DNS‑сервера: nameservers в dnsConfig. Вы можете настроить сервер доменных имен для собственного доменного имени. Значение — один или несколько IP‑адресов DNS.
- Поисковый домен: поиски в dnsConfig. Список доменов поиска DNS для разрешения имён хостов в pod. Это свойство является необязательным. При указании предоставленный список будет объединён с именами доменов поиска, сгенерированными выбранной политикой DNS в dnsPolicy. Дубликаты имён доменов удаляются.
- Host Alias: Добавьте сопоставление имён доменов и IP‑адресов в локальный файл конфигурации /etc/hosts pod для упрощённого локального разрешения имён доменов. Подробнее см. Добавление записей в Pod /etc/hosts с помощью HostAliases.
Нажмите Создать нагрузку.

Настройка DNS с помощью 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 по умолчанию. Контейнеры могут разрешать как внутренние доменные имена кластера, зарегистрированные сервисом, так и внешние доменные имена, доступные в публичных сетях. Список поиска (search опция) и ndots: 5 присутствуют в файле конфигурации DNS. Поэтому при обращении к внешнему доменному имени и длинному кластерному внутреннему доменному имени (например, kubernetes.default.svc.cluster.local), список поиска обычно будет просматриваться первым, в результате чего будет как минимум шесть недействительных запросов DNS. Проблема недействительных запросов DNS исчезает только когда используется короткое кластерное внутреннее доменное имя (например, kubernetes) происходит доступ.
ClusterFirstWithHostNet	По умолчанию, приложения, настроенные с хостовая сеть взаимосвязаны с конфигурацией DNS узла, на котором расположен pod. Конфигурация DNS указывается в файле DNS, который kubelet --resolv-conf параметр указывает на. В данном случае кластер CCE использует DNS в облаке. Если рабочим нагрузкам необходимо использовать Kube-DNS/CoreDNS кластера, установите dnsPolicy в ClusterFirstWithHostNet и файл конфигурации DNS контейнера такой же, как у ClusterFirst, в котором по‑прежнему существуют недействительные DNS‑запросы. ... spec: containers: - image: nginx:latest imagePullPolicy: IfNotPresent name: container-1 restartPolicy: Always hostNetwork: true dnsPolicy: ClusterFirstWithHostNet
По умолчанию	Конфигурация DNS узла, на котором находится pod, наследуется, и пользовательская конфигурация DNS добавляется к наследуемой конфигурации. Файл конфигурации DNS контейнера является файлом конфигурации DNS, который использует kubelet --resolv-conf флаг указывает на. В этом случае для кластеров CCE используется облачный DNS. Оба search и опции поля оставлены неуказанными. Эта конфигурация может разрешать только внешние доменные имена, зарегистрированные в Интернете, и не может разрешать внутренние доменные имена кластера. Эта конфигурация свободна от проблемы недействительных DNS‑запросов.
Нет	Конфигурация DNS по умолчанию заменяется пользовательской конфигурацией DNS, и используется только пользовательская конфигурация DNS. Если dnsPolicy установлен в Отсутствует, dnsConfig поле должно быть указано, потому что все настройки DNS должны предоставляться с использованием dnsConfig поле.

Note

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

dnsConfig

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

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

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

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

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

Kubernetes in-cluster Kube-DNS/CoreDNS применяется для разрешения только внутренних имен доменов кластера или внутренних имен доменов кластера + внешних имен доменов. Это 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 в Нет чтобы файл конфигурации 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 в значение, отличное от Нет чтобы параметры 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

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