CoreDNS

CoreDNS является DNS‑сервером, который обеспечивает разрешение доменных имён для кластеров Kubernetes через цепочку плагинов.

CoreDNS — это программное обеспечение с открытым исходным кодом, являющееся частью CNCF. Оно предоставляет возможности для обнаружения облачными сервисами друг друга в облачно‑нативных развертываниях. CoreDNS использует архитектуру цепочки плагинов, позволяющую гибко настраивать и эффективно обрабатывать DNS‑запросы за счёт комбинирования плагинов по мере необходимости. При использовании в кластере Kubernetes CoreDNS может автоматически обнаруживать сервисы в кластере и обеспечивать разрешение доменных имён для этих сервисов. Работая с DNS‑серверами, CoreDNS может разрешать внешние доменные имена для рабочих нагрузок в кластере.

Это дополнение устанавливается по умолчанию при создании кластера.

Kubernetes поддерживает CoreDNS в качестве официального DNS по умолчанию для всех кластеров в дальнейшем.

Официальный веб‑сайт CoreDNS: https://coredns.io/

Сообщество с открытым исходным кодом: https://github.com/coredns/coredns

Чтобы CoreDNS работал корректно или обновлялся в кластере, убедитесь, что количество доступных узлов в кластере больше или равно количеству CoreDNS pods и все CoreDNS pods находятся в состоянии Running. В противном случае дополнение будет работать некорректно или обновление завершится неудачей.

Это дополнение устанавливается по умолчанию. Если оно было удалено по какой‑то причине, вы можете переустановить его, выполнив следующие действия:

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. In the navigation pane, choose Add-ons. Locate CoreDNS on the right and click Install.
3. На странице Install Add-on настройте спецификации по мере необходимости.
   • Если вы выбрали Preset, вы можете выбрать Small, Medium или Large по мере необходимости. Система автоматически задаст количество add-on pod‑ов и квоты ресурсов в соответствии с предустановленными спецификациями. Вы можете увидеть конфигурации в консоли.

     Малый вариант может обрабатывать до 2500 внешних и 10 000 внутренних доменных имен QPS. Средняя спецификация может обрабатывать до 5000 внешних и 20 000 внутренних доменных имен QPS. Большая спецификация может обрабатывать до 10 000 внешних и 40 000 внутренних доменных имен QPS.

   • Если вы выбрали Custom, вы можете при необходимости отрегулировать количество pod‑ов и квоты ресурсов. QPS CoreDNS add-on положительно коррелирует с потреблением CPU. Если количество узлов или контейнеров в кластере растёт, pod‑ы CoreDNS add-on будут нести более тяжёлую нагрузку. Отрегулируйте количество pod‑ов CoreDNS add-on и их квоты CPU и памяти в зависимости от масштаба кластера. Подробности см. в Table 1.

     Table 1 Рекомендуемые квоты CoreDNS

     Nodes	Recommended QPS	Pods	Requested vCPUs	vCPU Limit	Requested Memory	Memory Limit
     50	2500	2	500m	500m	512 MiB	512 MiB
     200	5000	2	1000m	1000m	1024 MiB	1024 MiB
     1000	10000	2	2000m	2000m	2048 MiB	2048 MiB
     2000	20000	4	2000m	2000m	2048 MiB	2048 MiB

4. Настройте параметры дополнения.

   Table 2 параметры дополнения

   Параметр	Описание
   Stub Domain	Сервер доменных имен для пользовательского доменного имени, представленный в виде пар ключ‑значение. Ключ — суффикс доменного имени, значение — один или несколько IP‑адресов DNS, например, acme.local -- 1.2.3.4,6.7.8.9. Для получения подробной информации см. Configuring the Stub Domain for CoreDNS. ПРЕДУПРЕЖДЕНИЕ: В пользовательских доменных именах не допускаются заглавные буквы.
   Extended Parameter Settings	parameterSyncStrategy: указывает, следует ли настраивать проверку согласованности при обновлении дополнения. ensureConsistent: указывает, что проверка согласованности конфигурации включена. Если поставленная конфигурация отличается от текущей эффективной конфигурации, текущая эффективная конфигурация будет заменена. Однако если поставленная конфигурация совпадает с текущей эффективной конфигурацией, текущая эффективная конфигурация будет сохранена. Параметр ensureConsistent гарантирует согласованность конфигурации. Если ConfigMap изменён вручную, дополнение нельзя обновить. В таких случаях необходимо использовать политику force или inherit для обновления дополнения. force: управляет тем, игнорировать ли проверку согласованности конфигурации во время обновления. Если конфигурация, поставленная при обновлении дополнения, идентична конфигурации до обновления, ConfigMap не будет обновлён, и эффективная конфигурация останется без изменений. Если конфигурация изменена во время обновления дополнения, применяется новая конфигурация, поставленная вместе с обновлением. Важно обеспечить, чтобы конфигурация, поставленная при обновлении дополнения, соответствовала текущей эффективной конфигурации. После обновления дополнения необходимо восстановить значение parameterSyncStrategy в ensureConsistent, чтобы снова включить проверку согласованности конфигурации. inherit: если конфигурация, предоставленная при обновлении дополнения, отличается от текущей эффективной конфигурации, будет использована текущая эффективная конфигурация. После обновления дополнения необходимо восстановить значение parameterSyncStrategy в ensureConsistent, чтобы снова включить проверку согласованности конфигурации. ПРЕДУПРЕЖДЕНИЕ: После включения автоматического наследования параметров (parameterSyncStrategy=inherit) настройки stub domain будут очищены и объединены с расширенными параметрами. Исходные настройки stub domain остаются без изменений и их по‑прежнему можно просмотреть в разделе Extended Parameter Settings. servers: доступно в CoreDNS 1.23.1 и более поздних версиях. Вы можете настраивать серверы. Для получения подробной информации см. dns-custom-nameservers. plugins указывает конфигурацию каждого компонента в CoreDNS. Обычно сохраняйте настройки по умолчанию, чтобы предотвратить недоступность CoreDNS из‑за ошибок конфигурации. Каждый компонент плагина содержит name, parameters (необязательно) и configBlock (необязательно). Формат сгенерированного Corefile выглядит следующим образом: $name $parameters { $configBlock } Table 3 описывает общие плагины. Для получения подробной информации см. Plugins. upstream_nameservers: указывает IP-адрес восходящего DNS‑сервера. Пример: { "annotations": {}, "parameterSyncStrategy": "ensureConsistent", "servers": [ { "plugins": [ { "name": "bind", "parameters": "{$POD_IP}" }, { "name": "cache", "parameters": 30 }, { "name": "errors" }, { "name": "health", "parameters": "{$POD_IP}:8080" }, { "name": "ready", "parameters": "{$POD_IP}:8081" }, { "configBlock": "pods insecure\nfallthrough in-addr.arpa ip6.arpa", "name": "kubernetes", "parameters": "cluster.local in-addr.arpa ip6.arpa" }, { "name": "loadbalance", "parameters": "round_robin" }, { "name": "prometheus", "parameters": "{$POD_IP}:9153" }, { "configBlock": "policy random", "name": "forward", "parameters": ". /etc/resolv.conf" }, { "name": "reload" } ], "port": 5353, "zones": [ { "zone": "." } ] } ], "upstream_nameservers": ["8.8.8.8", "8.8.4.4"] }

   Table 3 Конфигурации CoreDNS по умолчанию

   Plugin Name	Type	Description
   bind	Конфигурация по умолчанию	Хост IP-адрес, прослушиваемый CoreDNS. Сохраните значение по умолчанию {$POD_IP}. Для получения подробной информации см. bind.
   cache	Конфигурация по умолчанию	Включает кэш DNS. Для получения подробной информации см. cache. Если версия дополнения 1.25.10 или новее, кэш servfail можно отключить. Чтобы отключить кэш servfail, задайте configBlock значение servfail 0. В противном случае единица измерения кэша servfail — секунда, и её нельзя опустить.
   ошибки	Конфигурация по умолчанию	Ошибки записываются в stdout. Для получения подробной информации см. errors.
   health	Конфигурация по умолчанию	Проверка состояния для CoreDNS. Она прослушивает {$POD_IP}:8080. Сохраните настройку по умолчанию. В противном случае проверка состояния CoreDNS завершится неудачей, и дополнение будет постоянно перезапускаться. Для получения подробной информации см. health.
   ready	Конфигурация по умолчанию	Определяет, готов ли сервер back‑end принимать трафик. Он прослушивает {$POD_IP}:8081. Если сервер back‑end не готов, CoreDNS приостановит разрешение DNS, пока сервер не станет готов. Для получения подробной информации см. ready.
   kubernetes	Конфигурация по умолчанию	Плагин CoreDNS Kubernetes, предоставляющий возможность разбора сервисов в кластере. Для получения подробной информации см. kubernetes.
   loadbalance	Конфигурация по умолчанию	Round-robin DNS балансировщик, который случайным образом переставляет порядок записей A, AAAA и MX в ответе. Для получения подробной информации см. loadbalance.
   prometheus	Конфигурация по умолчанию	API для получения метрик CoreDNS. По умолчанию он прослушивает {$POD_IP}:9153. Сохраните настройку по умолчанию. В противном случае Prometheus не сможет собирать метрики CoreDNS. Подробнее см. Prometheus.
   forward	Конфигурация по умолчанию	Перенаправляет любые запросы, которые не находятся в домене кластера Kubernetes, к предопределённым резольверам (/etc/resolv.conf). Подробнее см. forward.
   reload	Конфигурация по умолчанию	Автоматически перезагружает изменённые Corefiles. После изменения ConfigMap подождите две минуты, чтобы изменение вступило в силу. Подробнее см. reload.
   log	Расширенная конфигурация	Включает логирование CoreDNS. Подробнее см. log. Ниже приведён пример: { "name": "log" }
   template	Расширенная конфигурация	Шаблон быстрого ответа, где AAAA указывает запрос IPv6. Если NXDOMAIN возвращается в ответе rcode, результат разрешения IPv6 не возвращается. Подробнее см. template. Следующий пример: { "configBlock": "rcode NXDOMAIN", "name": "template", "parameters": "ANY AAAA" }

5. Настройте политики развертывания для add-on pods.
   Note

   • Политики планирования не применяются к DaemonSet pods дополнения.
   • При настройке multi-AZ deployment или node affinity убедитесь, что существуют узлы, соответствующие политике планирования, и что ресурсы в кластере достаточны. В противном случае add-on pods не смогут работать.

   Table 4 Конфигурации планирования add-on

   Параметр	Описание
   Multi-AZ Deployment	Preferred: pod‑ы развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы кластера развернуты в одном AZ, pod‑ы будут планироваться на разные узлы в этом AZ. Equivalent mode: pod‑ы развертывания дополнения равномерно планируются на узлы кластера в каждом AZ. При добавлении нового AZ рекомендуется увеличить количество add-on pods для развертывания HA с перекрёстным AZ. При Equivalent multi-AZ deployment разница в количестве add-on pods между различными AZ будет не более 1. Если ресурсы в одном из AZ недостаточны, pod‑ы не могут быть запланированы в этот AZ. Forcible: pod‑ы развертывания дополнения принудительно планируются на узлы в разных AZ. В каждом AZ может быть не более одного pod‑а. Если узлы кластера не находятся в разных AZ, некоторые add-on pods могут работать некорректно. Если узел неисправен, pod‑ы дополнения на нём могут не быть перенесены.
   Node Affinity	Not configured: Node affinity отключена для add-on pods. Specify node: укажите узлы, на которых развернуты add-on pods. Если узлы не указаны, add-on pods будут планироваться случайным образом в соответствии с политикой планирования кластера по умолчанию. Specify node pool: Укажите пул узлов, где развертываются pod‑ы дополнения. Если вы не укажете пулов узлов, pod‑ы дополнения будут случайным образом запланированы на основе политики планирования кластера по умолчанию. Customize affinity: Введите метки узлов, где должны быть развернуты pod‑ы дополнения, для более гибких политик планирования. Если вы не укажете метки узлов, pod‑ы дополнения будут случайным образом запланированы на основе политики планирования кластера по умолчанию. Если настроено несколько пользовательских политик аффинности, убедитесь, что в кластере есть узлы, соответствующие всем политикам аффинности. В противном случае pod‑ы дополнения не смогут работать.
   Toleration	Использование как taint‑ов, так и toleration‑ов позволяет (но не требует) pod‑ам Deployment дополнения планироваться на узлах с соответствующими taint‑ами и обеспечивает контроль над политиками выселения pod‑ов, когда узлы‑хосты помечены taint‑ами. Дополнение применяет политики toleration по умолчанию для taint‑ов node.kubernetes.io/not-ready и node.kubernetes.io/unreachable на pod‑ах. Временное окно toleration составляет 60s. Подробности см. в Configuring Tolerance Policies.

6. Нажмите Install.

1. Войдите в CCE console и нажмите имя кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите CoreDNS справа и нажмите Edit.
3. In the Parameters area, select whether to enable Corefile View (supported by add-on 1.30.3 and later versions).

   Once the function is enabled, the ConfigMap of CoreDNS in the kube-system namespace will be directly configured in the Corefile format. Any existing stub domain configurations and parameters such as parameterSyncStrategy, servers, and upstream_nameservers in the advanced settings will no longer be in effect. It is important to verify that the Corefile configuration is accurate.

   For description of the Corefile format, see Configuration.

   Note

   • Once the Corefile view is disabled, the ConfigMap of CoreDNS will continue to be configured based on to the stub domain configurations and parameters such as parameterSyncStrategy, servers, and upstream_nameservers in the advanced settings. It is important to verify that the configuration is correct during the function switchover.
   • Once the Corefile view is enabled, the add-on can be upgraded. However, if the Corefile view is disabled again, the add-on upgrade will override the current configurations. To complete the upgrade, parameterSyncStrategy must be set to either force or inherit.
   • После изменения ConfigMap Corefile просто дождитесь, пока механизм перезагрузки CoreDNS автоматически обновит конфигурацию. Обычно это занимает около 10 секунд, чтобы изменения вступили в силу.

4. After editing the Corefile, click OK.

DNS policies can be configured for each pod. Kubernetes supports DNS policies Default, ClusterFirst, ClusterFirstWithHostNet, and None. For details, see DNS for Services and Pods. These policies are specified in the pod-specific dnsPolicy field.

• Default: Pods inherit the name resolution configuration from the node that the pods run on. The custom upstream DNS server and the stub domain cannot be used together with this policy.
• ClusterFirst: Любой DNS‑запрос, который не соответствует настроенному суффиксу домена кластера, например www.kubernetes.io, перенаправляется на восходящий сервер имён, унаследованный от узла. Администраторы кластера могут иметь настроенные дополнительные stub domains и upstream DNS servers.
• ClusterFirstWithHostNet: Для pod‑ов, работающих с hostNetwork, используйте ClusterFirstWithHostNet.
• None: Позволяет pod игнорировать настройки DNS в среде Kubernetes. Все настройки DNS должны быть предоставлены с использованием поля dnsPolicy в dnsConfigPod.

Маршрутизация

Without stub domain configurations: Любой запрос, который не соответствует настроенному суффиксу домена кластера, например www.kubernetes.io, перенаправляется на восходящий DNS‑сервер, унаследованный от узла.

With stub domain configurations: Если stub domains и upstream DNS servers настроены, DNS‑запросы маршрутизируются согласно следующему потоку:

1. Запрос сначала отправляется в слой кэширования DNS в CoreDNS.
2. Из слоя кэширования проверяется суффикс запроса, после чего запрос перенаправляется к соответствующему DNS:
   • Имена с суффиксом кластера, например, .cluster.local: Запрос отправляется в CoreDNS.
   • Имена с суффиксом stub domain, например, .acme.local: Запрос отправляется в настроенный пользовательский DNS resolver, который, например, прослушивает 1.2.3.4.
   • Имена, не соответствующие суффиксу, например, widget.com: Запрос перенаправляется к upstream DNS.