Kubernetes используют частный DNS - PullRequest
1 голос
/ 30 января 2020

Можно ли использовать частный DNS в Kubernetes? Например, приложению необходимо подключиться к внешней БД по имени хоста. Запись DNS, которая разрешает IP-адрес, хранится в частном DNS.

Мой AKS (Azure Kubernetes Service) работает в версии 1.17, которая уже использует новый coreDNS.

My Первой попыткой было использовать этот частный DNS, как на виртуальной машине, настроив файл /etc/resolve.conf для pods:

dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 10.76.xxx.xxx
      - 10.76.xxx.xxx
    searches:
      - az-q.example.com
    options:
      - name: ndots
        value: "2"

Затем я попытался использовать configmap для настройки coreDNS:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  upstreamNameservers: |
    ["10.76.xxx.xxx", "10.76.xxx.xxx"]

Но мой модуль каждый раз запускается с ошибкой при развертывании:

$ sudo kubectl logs app-homepage-backend-xxxxx -n ingress-nginx
events.js:174
      throw er; // Unhandled 'error' event
      ^
Error: getaddrinfo ENOTFOUND az-q.example.com az-q.example.com:636
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26)

Чего мне не хватает?

Ответы [ 3 ]

1 голос
/ 31 января 2020

Все зависит от dnsPolicy , установленного вами в файле конфигурации развертывания вашего приложения.

Когда dnsPolicy модуля Pod имеет значение “default”,, он наследует конфигурацию разрешения имен от узла, на котором работает модуль Pod. DNS-разрешение модуля должно вести себя так же, как и узел.

1. Во многих Linux дистрибутивах (например, Ubuntu) по умолчанию используется локальный преобразователь DNS (systemd-resolved). Systemd-resolved перемещает и заменяет /etc/resolv.conf заглушкой, что может привести к фатальной пересылке l oop при разрешении имен на вышестоящих серверах. Это можно исправить вручную, используя флаг --resolv-conf kubelet, чтобы указать на правильный resolv.conf (для systemd-resolved это /run/systemd/resolve/resolv.conf). kubeadm (> = 1.11 ) автоматически определяет systemd-resolved и соответствующим образом корректирует флаги kubelet.

Установки Kubernetes не настраивают файлы resolv.conf узлов для использования DNS кластера по умолчанию потому что этот процесс по своей сути определяется дистрибутивом c. Это, вероятно, должно быть реализовано в конечном итоге.

2. lib c в Linux невозможно (застрял в этой ошибке 2005 года) с ограничением в 3 записи DNS-сервера имен и 6 DNS-записей поиска. Kubernetes должен потреблять 1 запись сервера имен и 3 записи поиска. Это означает, что если локальная установка уже использует 3 сервера имен или использует более 3 поисков, некоторые из этих настроек будут потеряны. В качестве частичного обходного пути узел может запустить dnsmasq, который предоставит больше записей сервера имен, но не больше записей поиска. Вы также можете использовать флаг --resolv-conf kubelet.

3 . Убедитесь, что вы не используете Alpine версии 3.3 или более ранней версии в качестве базового образа, тогда DNS может работать некорректно.

Пожалуйста, посмотрите здесь: dns-kubernetes-known -issues .

0 голосов
/ 05 февраля 2020

Для достижения того, что вам нужно, я бы go с dnsPolicy: ClusterFirst определением в модуле pod, а затем определением зоны-заглушки (частной зоны DNS) в вашей подсистеме DNS кластера.

Для идентификации стека DNS кластера обычно проверяйте модули, работающие в пространстве имен kube-system. Скорее всего, вы найдете один из этих двух: CoreDNS или Kube-DNS.

Если DNS вашего кластера работает на CoreDNS , найдите этот вид изменение в вашем coredns configmap. Если вы работаете в более старой системе Kube-DNS , найдите эту модификацию в kube-dns configmap.

Важно сказать, что если вы хотите Примените эту модификацию к модулям, работающим в режиме сети хоста (многие модули из kube-system пространства имен), вам нужно изменить их манифесты с помощью dnsPolicy: ClusterFirstWithHostNet stanza.

0 голосов
/ 31 января 2020

Что означает dnsPolicy в конфигурации развертывания для приложения? Согласно это делает c:

Пользовательские вышестоящие серверы имен и домены-заглушки не влияют на модули со значением dnsPolicy, установленным в «Default» или «None». ”.

Если для модуля dnsPolicy установлено значение« ClusterFirst », разрешение его имени обрабатывается по-разному, в зависимости от того, настроены ли сервер-заглушка и вышестоящие DNS-серверы.

См. В этом примере c и что происходит с пользовательскими конфигурациями.

...