CoreDNS

Введение

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

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

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

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

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

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

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

   Параметр	Описание
   Заглушка домена	Сервер имен домена для пользовательского доменного имени. Формат — пара «ключ‑значение». Ключ — суффикс доменного имени, а значение — один или несколько DNS‑IP‑адресов, например, acme.local -- 1.2.3.4,6.7.8.9. Для получения подробностей см. Настройка заглушки домена для CoreDNS. ВНИМАНИЕ: Прописные буквы не допускаются в пользовательских доменных именах.
   Расширенные настройки параметров	parameterSyncStrategy: указывает, нужно ли настраивать проверку согласованности при обновлении дополнения. ensureConsistent: указывает, что проверка согласованности конфигурации включена. Если поставленная конфигурация отличается от текущей действующей конфигурации, текущая действующая конфигурация будет заменена. Однако, если поставленная конфигурация совпадает с текущей действующей конфигурацией, текущая действующая конфигурация будет сохранена. The ensureConsistent параметр обеспечивает согласованность конфигурации. Если ConfigMap изменён вручную, надстройку нельзя обновить. В таких случаях вам потребуется использовать the force or inherit политику для обновления надстройки. force: указывает, что проверка согласованности конфигурации игнорируется во время обновления. Конфигурация, предоставленная во время обновления надстройки, будет использована, поэтому важно убедиться, что она соответствует текущей действующей конфигурации. После обновления надстройки необходимо восстановить значение parameterSyncStrategy к ensureConsistent чтобы снова включить проверку согласованности конфигурации. inherit: Если конфигурация, предоставленная во время обновления дополнения, отличается от текущей действующей конфигурации, будет использована текущая действующая конфигурация. После обновления дополнения вам потребуется восстановить значение parameterSyncStrategy чтобы ensureConsistent чтобы снова включить проверку согласованности конфигурации. ВНИМАНИЕ: После автоматического наследования параметров настройки (parameterSyncStrategy=inherit) включено, параметры заглушки домена будут очищены и объединены с расширенными параметрами настроек. Исходные параметры заглушки домена остаются без изменений и их всё ещё можно просмотреть в разделе Расширенные параметры настроек. серверы: name‑серверы, которые доступны в CoreDNS v1.23.1 и более поздних версиях. Вы можете настроить name‑серверы. Для получения подробностей см dns-custom-nameservers. плагины указывает конфигурацию каждого компонента в CoreDNS. Обычно сохраняйте параметры по умолчанию, чтобы предотвратить недоступность CoreDNS из‑за ошибок конфигурации. Каждый компонент плагина содержит имя, параметры (optional), и configBlock (optional). Формат сгенерированного Corefile выглядит следующим образом: $name $parameters { $configBlock } Таблица 3 описывает общие плагины. Для получения подробностей см Плагины. upstream_nameservers: указывает IP‑адрес upstream 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}. Для получения подробностей см bind.
   cache	Конфигурация по умолчанию	Включает кэш DNS. Для получения подробностей см cache. Если версия дополнения 1.25.10 или более поздняя, кеш servfail может быть отключён. Чтобы отключить кеш servfail, задайте configBlock to servfail 0. В противном случае единица кэша servfail — секунда, и её нельзя опустить.
   ошибки	Конфигурация по умолчанию	Ошибки записываются в stdout. Для получения деталей см ошибки.
   здоровье	Конфигурация по умолчанию	Проверка состояния для CoreDNS. {$POD_IP}:8080 прослушивается. Сохраните настройку по умолчанию. В противном случае проверка состояния CoreDNS завершится ошибкой, и дополнение будет перезапускаться многократно. Для получения деталей см здоровье.
   готово	Конфигурация по умолчанию	Определяет, готов ли сервер backend принимать трафик. {$POD_IP}:8081 прослушивается. Если сервер backend не готов, CoreDNS приостановит разрешение DNS, пока сервер не станет готов. Для получения деталей см готово.
   kubernetes	Конфигурация по умолчанию	плагин CoreDNS Kubernetes, который обеспечивает возможность парсинга службы в кластере. Подробнее см kubernetes.
   балансировка нагрузки	Конфигурация по умолчанию	Round-robin DNS балансировщик, который случайным образом меняет порядок записей 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" }

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

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

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

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

6. Щелкните Установить.

Компоненты

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

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

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

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

   Note

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

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

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

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

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

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