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‑ы находятся в состоянии 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 qps, Medium qps или Large qps по мере необходимости. Система автоматически задаст количество add-on pods и квоты ресурсов на основе предустановленных спецификаций. Вы можете увидеть конфигурации в консоли.

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

   • Если вы выбрали Custom, вы можете при необходимости скорректировать количество pods и квоты ресурсов. QPS дополнения CoreDNS положительно коррелирует с потреблением CPU. Если количество узлов или контейнеров в кластере растёт, pods CoreDNS будут нести более тяжёлую нагрузку. Рекомендуется корректировать количество pods CoreDNS и их квоты 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 Add-on parameters

   Параметр	Описание
   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 — секунда, и её нельзя опустить.
   errors	Конфигурация по умолчанию	Ошибки записываются в stdout. Для получения подробностей см. errors.
   health	Конфигурация по умолчанию	Health check for CoreDNS. It listens on {$POD_IP}:8080. Keep the default setting. Otherwise, the CoreDNS health check will fail and the add-on will restart repeatedly. For details, see health.
   ready	Конфигурация по умолчанию	Определяет, готов ли backend server принимать трафик. Он прослушивает {$POD_IP}:8081. Если backend server не готов, 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. Настройте политики развертывания для pod‑ов дополнения.
   Note

   • Политики планирования не применяются к pod‑ам DaemonSet дополнения.
   • При настройке развертывания multi-AZ или привязки к узлам убедитесь, что существуют узлы, соответствующие политике планирования, и что в кластере достаточно ресурсов. В противном случае дополнение не сможет работать.

   Table 4 Конфигурации планирования дополнения

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

6. Нажмите Install.

1. Войдите в CCE console и нажмите имя кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите CoreDNS справа и нажмите Edit.
3. В области Parameters выберите, включить ли Corefile View (поддерживается дополнением 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 дополнение можно обновить. Однако если Corefile view будет снова отключён, обновление дополнения перезапишет текущие конфигурации. Чтобы завершить обновление, parameterSyncStrategy должен быть установлен в значение force или inherit.
   • После изменения ConfigMap Corefile просто дождитесь, пока механизм перезагрузки CoreDNS автоматически обновит конфигурацию. Обычно это занимает около 10 секунд, чтобы изменения вступили в силу.

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

Политики DNS можно настроить для каждого pod. Kubernetes поддерживает политики DNS Default, ClusterFirst, ClusterFirstWithHostNet и None. Подробнее см. DNS for Services and Pods. Эти политики указываются в специфичном для pod поле dnsPolicy.

• Default: Pods наследуют конфигурацию разрешения имён от узла, на котором работают pod‑ы. Пользовательский upstream DNS‑сервер и stub domain не могут использоваться одновременно с этой политикой.
• ClusterFirst: Любой DNS‑запрос, который не соответствует настроенному суффиксу домена кластера, например www.kubernetes.io, перенаправляется к upstream‑серверу имён, унаследованному от узла. У администраторов кластера могут быть настроены дополнительные stub‑домены и upstream‑DNS‑серверы.
• ClusterFirstWithHostNet: Для pod‑ов, работающих с hostNetwork, используйте ClusterFirstWithHostNet.
• None: Позволяет pod‑у игнорировать настройки DNS в среде Kubernetes. Все настройки DNS должны указываться с помощью поля dnsPolicy в dnsConfigPod.

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

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

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

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