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

  1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
  2. В панели навигации выберите Workloads. В правом верхнем углу нажмите Create Workload.
  3. Configure basic information about the workload. For details, see Creating a Workload.
  4. In the Advanced Settings area, click the DNS tab and set the following parameters as required:

    • DNS Policy: The DNS policies provided on the console correspond to the dnsPolicy field in the YAML file. For details, see Table 1.
      • Supplement defaults: corresponds to dnsPolicy=ClusterFirst. Containers can resolve both the cluster-internal domain names registered by a Service and the external domain names exposed to public networks.
      • Replace defaults: corresponds to dnsPolicy=None. You must configure IP Address and Search Domain. Containers only use the user-defined IP address and search domain configurations for domain name resolution.
      • Inherit defaults: corresponds to dnsPolicy=Default. Containers use the domain name resolution configuration from the node that pods run on and cannot resolve the cluster-internal domain names.
    • Optional Objects: The options parameters in the dnsConfig field. Each object may have a name property (required) and a value property (optional). After setting the properties, click confirm to add.
      • timeout: Timeout interval, in seconds.
      • ndots: Number of periods (.) that must be present in a domain name. If a domain name has fewer periods than this value, the operating system will look up the name in the search domain. If not, the name is a fully qualified domain name (FQDN) and will be tried first as an absolute name.
    • IP Address of DNS Server: nameservers in dnsConfig. You can configure a domain name server for a custom domain name. The value is one or a group of DNS IP addresses.
    • Search Domain: searches in the dnsConfig. A list of DNS search domains for hostname lookup in the pod. This property is optional. When specified, the provided list will be merged into the search domain names generated from the chosen DNS policy in dnsPolicy. Duplicate domain names are removed.
    • Host Alias: Add the mapping between domain names and IP addresses to the local configuration file /etc/hosts of a pod for simplified local domain name resolution. For details, see Adding entries to Pod /etc/hosts with HostAliases

  5. Click 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, так и внешние доменные имена, доступные в публичных сетях. Список поиска (search option) и ndots: 5 присутствуют в файле конфигурации DNS. Поэтому при обращении к внешнему доменному имени и к длинному внутреннему доменному имени кластера (например, 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 (необязательно). Содержимое этого свойства будет объединено с параметрами options, сгенерированными из указанной 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. Дублирующие имена доменов удаляются. 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 в 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

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

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

    Container's файл конфигурации 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