Настройка LocalDNS в Служба Azure Kubernetes

Чтобы включить LocalDNS во время создания пула узлов, используйте следующую команду с пользовательским файлом конфигурации:

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Чтобы включить LocalDNS в существующем пуле узлов, используйте следующую команду с пользовательским файлом конфигурации:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Чтобы отключить LocalDNS для пула узлов, необходимо обновить файлlocaldnsconfig.json , задав для свойства значение modeDisabled. Это изменение заставляет AKS отключить локальный DNS-прокси на всех узлах в указанном пуле, возвращая разрешение DNS к стандартному поведению кластера. После обновления файла конфигурации примените его к пулу узлов с помощью Azure CLI, чтобы убедиться, что изменение вступает в силу.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

После включения LocalDNS можно проверить его операцию, выполнив dns-запросы из модулей pod в указанном пуле узлов и проверяя SERVER поле в ответах, чтобы подтвердить возврат адресов LocalDNS (169.254.10.10 или 169.254.10.11).

Перед выполнением шагов проверки убедитесь, что выполнены следующие условия:

1. kubectl Вы установили и настроили доступ к кластеру AKS.
2. Учетная запись пользователя имеет достаточные разрешения для создания и выполнения команд в pod.
3. Пул узлов, в котором требуется проверить, находится ли localDNS в состоянии "Готово ".
4. Образ BusyBox (busybox:1.28) доступен из узлов кластера.

Ниже приведен пример проверки:

1. Создайте отладочный pod в пуле узлов, на которых включена LocalDNS.

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. После запуска pod выполните следующую команду, чтобы проверить разрешение DNS:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Просмотрите выходные данные . Если localDNS работает правильно, вы увидите ответ с адресом сервера 169.254.10.10 или 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

LocalDNS использует файл конфигурации на основе JSON localdnsconfig.json для определения поведения разрешения DNS для каждого пула узлов. Этот файл позволяет указать рабочие режимы, блоки сервера для различных доменов DNS и параметры подключаемого модуля, такие как кэширование, пересылка и ведение журнала.

Конфигурация LocalDNS по умолчанию

Конфигурация LocalDNS по умолчанию обеспечивает сбалансированную настройку, которая оптимизирует как внутреннее, так и внешнее разрешение DNS для большинства рабочих нагрузок AKS. Эту конфигурацию можно использовать в качестве отправной точки и настроить ее, чтобы лучше соответствовать конкретным требованиям DNS кластера.

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

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

Настройте mode для LocalDNS

LocalDNS можно включить в трех возможных режимах, определяющих степень применения LocalDNS для рабочей нагрузки:

• Required: в этом режиме localDNS применяется в пуле узлов, если выполнены все необходимые условия. Если требования не выполнены, развертывание не удается.

• Disabled: отключает локальную функцию DNS, то есть запросы DNS не разрешаются локально на узле.

• Preferred: в этом режиме AKS проверяет правильность конфигурации LocalDNS, но не включает LocalDNS на узлах. Однако применение этого режима по-прежнему активирует операцию повторного создания образа узла, что позволяет протестировать конфигурацию на наличие ошибок, не влияя на разрешение DNS в кластере.

В следующей таблице приведены сведения о поведении LocalDNS для каждого режима и версии Kubernetes:

Блоки сервера и поддерживаемые плагины для LocalDNS

Конфигурация по умолчанию применяется к запросам из подов с dnsPolicy:default под vnetDNSOverrides и подов с dnsPolicy:ClusterFirst под kubeDNSOverrides. В каждом из них определены два блока сервера по умолчанию: . и cluster.local.

• . представляет все внешние запросы DNS из модулей pod, которые пытаются разрешить общедоступные или не кластерные домены (например, microsoft.com).

• cluster.local представляет все внутренние запросы обнаружения служб Kubernetes от подов, которые пытаются решать имена Kubernetes-сервисов или внутренние ресурсы кластера. Эти запросы направляются через CoreDNS для разрешения в кластере.

Поддерживаемые плагины

Правила проверки конфигурации

При создании конфигурации LocalDNS следует учитывать следующие правила проверки, чтобы избежать сбоев развертывания:

• Ограничения корневой зоны(.) : в vnetDNSOverridesразделе " forwardDestination Корневой зоны" не может быть ClusterCoreDNS.

• Ограничения зоны cluster.local: в обоих случаях и , для не может быть .

• Совместимость протокола и serveStale: если protocol задано как ForceTCP, serveStale нельзя задать как Verify. Вместо этого используйте Immediate.

Создайте пользовательский блок сервера в LocalDNS

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

Например, если у вас есть определенные потребности DNS при доступе к microsoft.com, можно использовать следующий блок сервера:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

Монитор localDNS

LocalDNS предоставляет метрики Prometheus, которые можно использовать для мониторинга и оповещения. Эти метрики доступны через порт 9253 IP-адреса узла и могут быть собраны оттуда.

В следующем примере YAML показана конфигурация для сбора метрик, которую можно использовать с надстройкой Azure Managed Prometheus в качестве DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

Устранение неполадок локального DNS

Сбой запросов DNS к определенным доменам

Если dns-запросы к определенным доменам завершаются ошибкой после включения LocalDNS:

1. Проверьте наличие переопределений для конкретного домена в localdnsconfig.json , которые могут быть неправильно настроены.
2. Временно попробуйте убрать специальные настройки для домена и использовать только конфигурацию по умолчанию ..
3. Проверьте, возникает ли проблема с протоколом пользовательской диаграммы данных (UDP) и протоколом protocol управления передачей (TCP), изменив этот параметр.

Обновление DNS-серверов VNet для LocalDNS

При обновлении пользовательских DNS-серверов непосредственно в конфигурации виртуальной сети (с помощью портала Azure или интерфейса командной строки эти изменения автоматически не применяются к узлам кластера AKS. Обновление параметров DNS на уровне виртуальной сети сообщает только поставщику сетевых ресурсов (NRP), но не уведомляет поставщика ресурсов AKS. В результате узлы AKS продолжают использовать предыдущие параметры DNS-сервера, пока не будет предприняты дальнейшие действия.

Чтобы убедиться, что узлы AKS принимают новые настройки DNS-сервера виртуальной сети:

1. Обновите конфигурацию DNS виртуальной сети с помощью портала Azure или API по мере необходимости.

2. Используйте поставщик ресурсов AKS для повторного создания пула узлов, обеспечивая применение и сохранение обновленных параметров DNS:

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

Этот процесс гарантирует, что поставщик ресурсов AKS знает об изменениях DNS и применяет их ко всем узлам в пуле узлов.

Обновление политик сети Cilium, чтобы разрешить разрешение DNS с помощью LocalDNS

При развертывании политик сети Cilium в кластере необходимо явно разрешить исходящий трафик pod на IP-адреса LocalDNS.

Политики сети применяют модель отказа по умолчанию для пунктов назначения, которые не указаны, поэтому DNS-трафик на LocalDNS заблокирован, если он не разрешен явным образом.

• В Azure CNI, работающем на базе Cilium <=v1.16 с k8s <=1.31, это можно сделать с помощью политики на основе CIDR.
• В Azure CNI на базе Cilium >=v1.17 с K8s >=1.32, можно использовать сетевую политику Cilium, допускающую исходящий трафик к хост-энтитетам.

Следующая политика сети Cilium может использоваться для разрешения трафика во всех версиях:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-azure-dns-egress"
  namespace: default
spec:
  endpointSelector:
    matchLabels: {} # This selects ALL pods in the namespace
  egress:
    - toCIDR:
        - 169.254.10.0/24
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
    - toEntities:
        - host
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

Дальнейшие шаги

Сведения о LocalDNS в AKS см. в разделе LocalDNS в Служба Azure Kubernetes (концептуальная).

Подробные рекомендации по устранению неполадок с DNS при использовании LocalDNS см. в разделе "Устранение неполадок LocalDNS" в AKS.

Дополнительные сведения о настройке CoreDNS в AKS см. в руководстве по настройке CoreDNS.

Сведения о проекте CoreDNS см. на странице вышестоящего проекта CoreDNS.

Дополнительные сведения см. в статье Основные понятия сети для приложений в AKS.