Предоставляют ли узлы OpenShift службу dns по умолчанию? - PullRequest
Новая
       16

Предоставляют ли узлы OpenShift службу dns по умолчанию?

0 голосов
/ 05 октября 2018

У меня есть OpenShift, кластер, и периодически при доступе к журналам я получаю: 

worker1-sass-on-prem-origin-3-10 on 10.1.176.130:53: no such host" kube doing a connection to 53 on a node.

Я также склонен время от времени видеть tcp: lookup postgres.myapp.svc.cluster.local on 10.1.176.136:53: no such host ошибки в модулях, опять же, это заставляет меня задуматьсячто при доступе к внутренним конечным точкам службы модули, клиенты и другие связанные с Kubernetes службы фактически общаются с DNS-сервером, который, как предполагается, работает на данном узле, на котором работают указанные модули.

Обновление

Просматривая один из моих модулей на данном узле, я нашел следующее в resolv.conf (мне пришлось ssh и запустить docker exec, чтобы получить этот вывод - поскольку oc exec не работает из-за этой проблемы).

/etc/cfssl $ cat /etc/resolv.conf 
nameserver 10.1.176.129
search jim-emea-test.svc.cluster.local svc.cluster.local cluster.local bds-ad.lc opssight.internal
options ndots:5

Таким образом, похоже, что в моем кластере контейнеры имеют самореференциальную запись resolv.conf.Этот кластер создается с помощью openshift-ansible .Я не уверен, является ли это специфичным для инфраструктуры, или это на самом деле фундаментальный аспект работы узлов openshift, но я подозреваю, что последнее, так как я не делал никаких значительных настроек в моем ANSI-рабочем потоке от upsh-openshift-ANSIBLEрецепты.

1 Ответ

0 голосов
/ 05 октября 2018

Да, DNS на каждом узле является нормальным в openshift.

Похоже, что для развертывания в ANSILSHIFT развертывание служб dnsmasq на каждом узле является нормальным явлением.

Подробности.

В качестве примера того, как это может повлиять на ситуацию, приведено следующее https://github.com/openshift/openshift-ansible/pull/8187.В любом случае, если dnsmasq локального узла по какой-то причине действует некорректно, это не позволит контейнерам, работающим на этом узле, правильно разрешать адреса других контейнеров в кластере.

Взгляд глубже на "дымящую пушку" dnsmasq

После проверки на отдельном узле я обнаружил, что на самом деле процесс действительно ограничен портом 53, и это dnsmasq.Следовательно,

[enguser@worker0-sass-on-prem-origin-3-10 ~]$ sudo netstat -tupln | grep 53 tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 675/openshift

И, dnsmasq работает локально:

[enguser@worker0-sass-on-prem-origin-3-10 ~]$ ps -ax | grep dnsmasq 4968 pts/0 S+ 0:00 grep --color=auto dnsmasq 6994 ? Ss 0:22 /usr/sbin/dnsmasq -k [enguser@worker0-sass-on-prem-origin-3-10 ~]$ sudo ps -ax | grep dnsmasq 4976 pts/0 S+ 0:00 grep --color=auto dnsmasq 6994 ? Ss 0:22 /usr/sbin/dnsmasq -k

Последний ключ, сам resolv.conf даже добавляетлокальный IP-адрес как сервер имен ... И это, очевидно, заимствовано в контейнерах, которые запускаются. 

 nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
 Generated by NetworkManager
search cluster.local bds-ad.lc opssight.internal
 NOTE: the libc resolver may not support more than 3 nameservers.
 The nameservers listed below may not be recognized.
nameserver 10.1.176.129

Решение (в моем конкретном случае)

В моем случае это происходилопотому что локальный сервер имен использовал ifcfg (вы можете увидеть эти файлы в / etc / sysconfig / network-scripts /) с 

[enguser@worker0-sass-on-prem-origin-3-10 network-scripts]$ cat ifcfg-ens192 
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens192
UUID=50936212-cb5e-41ff-bec8-45b72b014c8c
DEVICE=ens192
ONBOOT=yes

Однако мои виртуально настроенные виртуальные машины не смогли разрешить IP-адреса, предоставленные дляих в записях PEERDNS.

В конечном итоге исправление состояло в том, чтобы работать с нашим ИТ-отделом, чтобы убедиться, что у нашего авторитетного домена для наших кластеров kube есть доступ ко всем IP-адресам в нашем центре обработки данных.Общее исправление: 53 ошибок поиска ...

Если вы видите, что при записи kubectl или oc logs / exec появляется: 53 ошибок записи, то, скорее всего, ваш apiserver неспособен к сотрудничествуnube с kubelets через их IP-адрес .

Если вы видите: 53 ошибки записи в других местах, например, внутри пакетов , то это потому, что ваш модуль, используя свой собственный локальный DNS, не может разрешить внутренний IP-адрес кластераадреса.Это может быть просто потому, что у вас есть устаревший контроллер, который ищет сервисы, которые больше не существуют, или же у вас есть ошибки на уровне реализации kubernetes dns.

...