CoreDNS#

CoreDNS - это гибкий DNS-сервер. Основные сценарии использования CoreDNS связаны с использованием плагинов. Если функциональность не предусмотрена, существует возможность добавления функциональности в виде плагина.

CoreDNS может прослушивать DNS-запросы, поступающие через:

  • UDP/TCP;

  • TLS 1.2 ( RFC 7858 ), также называемый DoT;

  • DNS через HTTP/2 — DoH — ( RFC 8484 );

  • gRPC.

Основные функции CoreDNS:

  • подача данных зоны из файла - поддерживаются как DNSSEC (только NSEC), так и DNS (file и auto);

  • получение данных зоны от первичных серверов, т. е. действие в качестве вторичного сервера (только AXFR) (secondary);

  • моментальная подпись данных зоны (dnssec);

  • балансировка нагрузки ответов (loadbalance);

  • разрешение передачи зон, т. е. действие в качестве первичного сервера (файл + передача);

  • автоматическая загрузка файлов зон с диска (auto);

  • кеширование ответов DNS (cache);

  • использование etcd в качестве backend (замена SkyDNS);

  • использование DropApp в качестве backend;

  • использование в качестве прокси для пересылки запросов на какой-либо другой (рекурсивный) сервер имен (forward);

  • предоставление метрик (используя Prometheus) (prometheus);

  • обеспечение регистрации запросов (log) и ошибок (errors);

  • интеграция с облачными провайдерами (route53);

  • поддержка параметра идентификатора сервера имен DNS RFC 5001 (NSID) (nsid);

  • поддержка профилирования (pprof);

  • переписывание запросов (qtype, qclass и qname) (rewrite and template);

  • блокировка запросов (any).

Установка#

Конфигурация#

  1. Создайте файл конфигурации:

    kubectl -n kube-system get configmap coredns -oyaml

  2. Это конфигурация CoreDNS по умолчанию, поставляемая с kubeadm. Она сохраняется в configmap с именем coredns:

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local 0.0.0.0/12 {
           pods insecure
           upstream /etc/resolv.conf
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
    }
kind: ConfigMap
metadata:
  creationTimestamp: 2017-12-21T12:55:15Z
  name: coredns
  namespace: kube-system
  resourceVersion: "161"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: <UID>

Развертывание#

  1. Чтобы установить CoreDNS для нового кластера DropApp, используйте флаг feature-gates и установите для него значение CoreDNS=true.

    Используйте следующую команду, чтобы установить CoreDNS в качестве службы DNS по умолчанию при установке нового кластера DropApp:

    kubeadm init --feature-gates CoreDNS=true

  2. Вывод будет следующим:

    [init] Using Kubernetes version: v1.26.15
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks.
    [WARNING SystemVerification]: docker version is greater than the most recently validated version. Docker version: 17.09.1-ce. Max validated version: 17.03 # отобразится актуальная для текущей поставки версия Docker
    [WARNING FileExisting-crictl]: crictl not found in system path
[preflight] Starting the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [sandeep2 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [<IP-address1> <IP-address2>]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
[init] This might take a minute or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 31.502217 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node sandeep2 as master by adding a label and a taint
[markmaster] Master sandeep2 tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: 0cd000.a000a00b0000a0ec
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

    Установка CoreDNS будет подтверждена, если при развертывании DropApp отобразится следующий результат:

    [addons] Applied essential addon: CoreDNS

Тестирование#

  1. Используйте флаг -plugins, чтобы вывести список всех скомпилированных плагинов. Без Corefile coreDNS загрузит плагин whoami, который выведет IP-адрес и порт клиента. Для тестирования coreDNS и работы на порту 1053 отправьте запрос, используя dig:

    ./coredns -dns.port=1053
.:1053
2023/04/20 10:40:44 [INFO] CoreDNS-1.0.5
2023/04/20 10:40:44 [INFO] linux/amd64, go1.10,
CoreDNS-1.9.4
linux/amd64, go1.10,

  2. Из другого окна терминала dig должен наблюдаться следующий вывод:

    dig @localhost -p 1053 a whoami.example.org

;; QUESTION SECTION:
;whoami.example.org.        IN  A

;; ADDITIONAL SECTION:
whoami.example.org. 0   IN  AAAA    ::1
_udp.whoami.example.org. 0  IN  SRV 0 0 39368 .

Плагины#

После запуска и анализа конфигурации CoreDNS запустит серверы. Каждый сервер определяется по зонам, которые он обслуживает, и по порту. У каждого сервера есть своя собственная цепочка подключаемых модулей.

Когда запрос обрабатывается CoreDNS, выполняются следующие действия:

  1. Если настроено несколько серверов, которые прослушивают запрашиваемый порт, CoreDNS проверит, какой из них имеет наиболее специфичную зону для этого запроса (совпадение по длине суффикса). Например, если есть два сервера, один для example.org, а другой для a.example.org, и запрос предназначен для www.a.example.org, запрос будет перенаправлен последнему.

  2. Как только сервер будет найден, запрос перенаправится через цепочку плагинов, настроенную для этого сервера. Это всегда происходит в одном и том же порядке. Этот статический порядок определен в plugin.cfg.

  3. Каждый плагин проверит запрос и определит, следует ли ему его обрабатывать. Некоторые плагины позволяют выполнять дополнительную фильтрацию по имени запроса или другим атрибутам.

    Список возможных событий:

    • запрос обрабатывается этим плагином;

    • запрос не обрабатывается этим плагином;

    • запрос обрабатывается этим плагином, но на полпути он решает, что все еще хочет вызвать следующий плагин в цепочке. Этот провал вызывается по ключевому слову, которое его включает;

    • запрос обрабатывается этим плагином, добавляется «подсказка» и вызывается следующий плагин. Эта подсказка дает возможность «увидеть» возможный ответ и действовать в соответствии с ним.

    Обработка запроса означает, что плагин отправит клиенту ответ.

Примечание

Обратите внимание, плагин может отклоняться от приведенного выше списка. В настоящее время все плагины, поставляемые с CoreDNS, попадают в одну из этих четырех групп.

Плагин состоит из:

  • настройки;

  • регистрации;

  • обработчика.

Программа установки анализирует конфигурацию и директивы плагина. Они должны быть задокументированы в README плагина.

Обработчик - это код, который обрабатывает запрос и реализует всю логику.

Часть регистрации включает плагин в CoreDNS - это происходит при компиляции CoreDNS. Все зарегистрированные плагины могут использоваться сервером. Решение о том, какие плагины будут настроены на каждом сервере, принимается во время выполнения и хранится в файле конфигурации CoreDNS - Corefile.