CoreDNS

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

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

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

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

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

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

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

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

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите CoreDNS справа и нажмите 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 положительно коррелирует с потреблением CPU. По мере увеличения количества узлов или контейнеров в кластере нагрузка CoreDNS растёт соответственно. Отрегулируйте количество pod‑ов CoreDNS и их квоты CPU и памяти в зависимости от масштаба кластера. Подробности см. в Table 1.

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

     Узлы	Рекомендуемый QPS	Pods	Запрошенные vCPU	Лимит vCPU	Запрошенная память	Лимит памяти
     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 Add-on parameters

   Parameter	Description
   Stub Domain	Сервер доменных имен для пользовательского доменного имени, представленный в виде пар ключ‑значение. Ключом является суффикс доменного имени, а значением — один или несколько IP‑адресов DNS, например, acme.local -- 1.2.3.4,6.7.8.9. Для получения подробной информации см. Configuring the Stub Domain for CoreDNS. CAUTION: В пользовательских доменных именах недопустимы заглавные буквы.
   Extended Parameter Settings	parameterSyncStrategy: указывает, следует ли настраивать проверку согласованности при обновлении дополнения. ensureConsistent: указывает, что проверка согласованности конфигурации включена. Если поставленная конфигурация отличается от текущей действующей конфигурации, текущая действующая конфигурация будет заменена. Однако если поставленная конфигурация совпадает с текущей действующей конфигурацией, текущая действующая конфигурация будет сохранена. Параметр ensureConsistent гарантирует согласованность конфигурации. Если ConfigMap изменён вручную, дополнение нельзя обновить. В таких случаях необходимо использовать политику force или inherit для обновления дополнения. force: управляет тем, игнорировать ли проверку согласованности конфигурации во время обновления. Если конфигурация, поставленная при обновлении дополнения, идентична конфигурации до обновления, ConfigMap не будет обновлён, и действующая конфигурация останется без изменений. Если конфигурация изменена во время обновления дополнения, применяется новая конфигурация, поставленная вместе с обновлением. Важно обеспечить, чтобы конфигурация, поставленная при обновлении дополнения, соответствовала текущей действующей конфигурации. После обновления дополнения необходимо восстановить значение parameterSyncStrategy в ensureConsistent, чтобы снова включить проверку согласованности конфигурации. inherit: если конфигурация, предоставленная при обновлении дополнения, отличается от текущей действующей конфигурации, будет использована текущая действующая конфигурация. После обновления дополнения необходимо восстановить значение parameterSyncStrategy в ensureConsistent, чтобы снова включить проверку согласованности конфигурации. CAUTION: После включения автоматического наследования параметров (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 по умолчанию

   Имя плагина	Тип	Описание
   bind	Конфигурация по умолчанию	IP‑адрес хоста, прослушиваемый CoreDNS. Сохраните значение по умолчанию {$POD_IP}. Для получения подробностей см. bind.
   cache	Конфигурация по умолчанию	Включает кэш DNS. Для получения подробностей см. cache. Если версия дополнения 1.25.10 или новее, кэш servfail можно отключить. Чтобы отключить кэш servfail, установите configBlock в значение servfail 0. В противном случае единица измерения кэша servfail — секунды, и её нельзя опустить.
   errors	Конфигурация по умолчанию	Ошибки записываются в stdout. Для получения подробной информации см. errors.
   health	Конфигурация по умолчанию	Проверка работоспособности CoreDNS. Она прослушивает {$POD_IP}:8080. Сохраните настройку по умолчанию. В противном случае проверка работоспособности CoreDNS завершится с ошибкой, и дополнение будет постоянно перезапускаться. Для получения подробной информации см. health.
   ready	Конфигурация по умолчанию	Готов ли сервер бэкенда принимать трафик. Он прослушивает {$POD_IP}:8081. Если сервер бэкенда не готов, CoreDNS приостановит разрешение DNS, пока сервер бэкенда не станет готов. Для получения подробной информации см. ready.
   kubernetes	Конфигурация по умолчанию	Плагин CoreDNS Kubernetes, который обеспечивает возможность разбора сервисов в кластере. Для получения подробной информации см. kubernetes.
   loadbalance	Конфигурация по умолчанию	DNS‑балансировщик round‑robin, который случайным образом переставляет порядок записей 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 или привязки к узлам убедитесь, что существуют узлы, соответствующие политике планирования, и что ресурсы в кластере достаточны. В противном случае add‑on pods не смогут работать.

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

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

6. Нажмите Install.

1. Войдите в CCE console и click the cluster name to access the cluster console.
2. В панели навигации выберите Add-ons. Найдите CoreDNS справа и click Edit.
3. В Parameters области выберите, включить ли Corefile View (поддерживается add-on 1.30.3 и более поздними версиями).

   После включения функции ConfigMap CoreDNS в пространстве имён kube-system будет напрямую сконфигурирован в формате Corefile. Любые существующие конфигурации stub domain и параметры, такие как parameterSyncStrategy, servers и upstream_nameservers в расширенных настройках, более не будут действовать. Важно убедиться, что конфигурация Corefile точна.

   Для описания формата Corefile см. Configuration.

   Note

   • После отключения Corefile view ConfigMap CoreDNS будет продолжать конфигурироваться на основе конфигураций stub domain и параметров, таких как parameterSyncStrategy, servers и upstream_nameservers в расширенных настройках. Важно убедиться, что конфигурация правильна во время переключения функции.
   • После включения Corefile view можно обновить add-on. Однако если Corefile view будет снова отключён, обновление add-on перезапишет текущие конфигурации. Для завершения обновления parameterSyncStrategy должен быть установлен в значение force или inherit.
   • После изменения ConfigMap Corefile просто дождитесь, пока механизм перезагрузки CoreDNS автоматически обновит конфигурацию. Обычно это занимает около 10 секунд, чтобы изменения вступили в силу.

4. После редактирования Corefile нажмите OK.

DNS policies can be configured per 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, перенаправляется к upstream‑серверу имён, унаследованному от узла. Администраторы кластера могут иметь настроенные дополнительные stub‑домены и upstream‑DNS‑серверы.
• ClusterFirstWithHostNet: Для pod‑ов, работающих с hostNetwork, используйте ClusterFirstWithHostNet.
• None: Позволяет pod игнорировать настройки DNS в среде Kubernetes. Все настройки DNS должны указываться с помощью поля dnsPolicy в dnsConfigPod.

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

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

С конфигурациями stub domain: Если stub‑домены и upstream‑DNS‑серверы настроены, DNS‑запросы маршрутизируются согласно следующему потоку:

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