CoreDNS

Введение

Примечания и ограничения

Установка дополнения

1. Войдите в консоль CCE и щелкните название кластера, чтобы открыть консоль кластера. На навигационной панели выберите Дополнения, найдите CoreDNS справа, и щелкните Установить.
2. В Установить дополнение страница, настройте спецификации по мере необходимости.
   • Если вы выбрали Предустановка, вы можете выбрать между Малый qps, Средний qps, или Большой qps по мере необходимости. Система автоматически установит количество дополнительных pod'ов и квоты ресурсов в соответствии с предустановленными спецификациями. Вы можете увидеть конфигурации в консоли.

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

   • Если вы выбрали Пользовательский, вы можете регулировать количество pod‑ов и квоты ресурсов по мере необходимости. QPS дополнения CoreDNS положительно коррелирует с потреблением CPU. Если количество узлов или контейнеров в кластере растёт, pod‑ы CoreDNS будут выполнять более тяжёлую работу. Рекомендуется регулировать количество pod‑ов CoreDNS и их квоты CPU и памяти в зависимости от масштаба кластера. Для деталей см Таблица 1.

     Таблица 1 Рекомендуемые квоты CoreDNS

     Узлы	Рекомендуемый QPS	Поды	Запрошенные 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	2048Mi

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

   Таблица 2 Параметры дополнения

   Параметр	Описание
   Заглушка домена	Сервер имен домена для пользовательского доменного имени. Формат представляет собой пару ключ‑значение. Ключ — это суффикс доменного имени, а значение — один или несколько IP‑адресов DNS, например, acme.local -- 1.2.3.4,6.7.8.9. Для получения подробностей см. Настройка заглушки домена для CoreDNS. ВНИМАНИЕ: Прописные буквы не допускаются в пользовательских доменных именах.
   Расширенные настройки параметров	parameterSyncStrategy: указывает, следует ли настраивать проверку согласованности при обновлении дополнения. ensureConsistent: указывает, что проверка согласованности конфигурации включена. Если доставленная конфигурация отличается от текущей эффективной конфигурации, текущая эффективная конфигурация будет заменена. Однако, если доставленная конфигурация совпадает с текущей эффективной конфигурацией, текущая эффективная конфигурация будет сохранена. The ensureConsistent параметр обеспечивает согласованность конфигурации. Если ConfigMap изменён вручную, дополнение не может быть обновлено. В таких случаях вам потребуется использовать the force или наследовать политику обновления дополнения. force: указывает, что проверка согласованности конфигурации игнорируется во время обновления. Конфигурация, предоставленная во время обновления дополнения, будет использована, поэтому важно убедиться, что она соответствует текущей эффективной конфигурации. После обновления дополнения вам нужно восстановить значение of parameterSyncStrategy to ensureConsistent чтобы снова включить проверку согласованности конфигурации. наследовать: Если конфигурация, предоставленная во время обновления дополнения, отличается от текущей эффективной конфигурации, будет использована текущая эффективная конфигурация. После обновления дополнения вам нужно восстановить значение parameterSyncStrategy to ensureConsistent чтобы снова включить проверку согласованности конфигурации. серверы: серверы имён, которые доступны в CoreDNS v1.23.1 и более поздних версиях. Вы можете настроить серверы имён. Для подробностей см dns-custom-nameservers. плагины указывает конфигурацию каждого компонента в CoreDNS. Обычно сохраняйте настройки по умолчанию, чтобы предотвратить недоступность CoreDNS из‑за ошибок конфигурации. Каждый компонент плагина содержит имя, параметры (необязательно), и configBlock (необязательно). Формат сгенерированного Corefile выглядит следующим образом: $name $parameters { $configBlock } Таблица 3 описывает общие плагины. Для получения подробностей см. Плагины. 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"] }

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

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

4. Настройте политики развертывания для подов дополнения.
   Note

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

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

   Параметр	Описание
   Развертывание multi-AZ	Предпочтительно: Поды развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы в кластере развернуты в одной AZ, поды будут планироваться на разные узлы в этой AZ. Эквивалентный режим: Подкасты развертывания дополнения равномерно распределяются по узлам кластера в каждом AZ. Если добавлен новый AZ, рекомендуется увеличить количество pods дополнения для развертывания HA с cross-AZ. При эквивалентном мульти-AZ развертывании разница между числом pods дополнения в разных AZ будет менее или равна 1. Если ресурсы в одном из AZ недостаточны, pods не могут быть запланированы в этот AZ. Forcible: Подкасты развертывания дополнения принудительно планируются на узлы в разных AZ. В каждом AZ может быть не более одного pod. Если узлы кластера не находятся в разных AZ, некоторые pods дополнения могут работать некорректно. Если узел неисправен, pods дополнения на нём могут не мигрировать.
   Node Affinity	Not configured: Аффинность узла отключена для add-on. Specify node: Укажите узлы, на которых развернут add-on. Если вы не укажете узлы, add-on будет случайным образом планироваться в соответствии с политикой планирования кластера по умолчанию. Specify node pool: Укажите пул узлов, в котором развернут аддон. Если вы не укажете пул узлов, аддон будет назначен случайным образом в соответствии с политикой планирования кластера по умолчанию. Настройка аффинити: Введите метки узлов, где будет развернут аддон, для более гибких политик планирования. Если вы не укажете метки узлов, аддон будет назначен случайным образом в соответствии с политикой планирования кластера по умолчанию. Если настроено несколько пользовательских политик аффинити, убедитесь, что в кластере есть узлы, удовлетворяющие всем политикам аффинити. В противном случае аддон не сможет работать.
   Толерация	Использование как taints, так и tolerations позволяет (не принудительно) развертыванию аддона быть запланированным на узел с соответствующими taint‑ами, и контролирует политики выселения развертывания после того, как узел, где находится развертывание, будет помечен taint‑ом. Аддон добавляет политику толерации по умолчанию для node.kubernetes.io/not-ready и node.kubernetes.io/unreachable taints соответственно. Временное окно толерации составляет 60 с. Для получения подробной информации см. Настройка политик толерантности.

5. Нажмите Установить.

Настройка CoreDNS с помощью Corefile

1. Войдите в консоль CCE и нажмите имя кластера, чтобы получить доступ к консоли кластера. В навигационной панели выберите Дополнения, найдите CoreDNS справа, и нажмите Редактировать.
2. В Параметры области, выберите, переключаться на Просмотр Corefile (поддерживается дополнением 1.30.3 и более поздних версий).

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

   Для описания формата Corefile см. Конфигурация.

   Note

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

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

Компоненты

Как работает разрешение доменных имен в Kubernetes?

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

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

Рисунок 1 Маршрутизация