Kubeadm: Новое развертывание с CoreDNS не разрешает поиск DNS

По какой-то причине в вашем кластере нет службы kube-dns .
Сначала вам нужно будет воссоздать это вручную, чтобы исправить ситуацию. Затем мы можем попытаться выяснить, как он исчез.

Вы можете использовать этот yaml для создания службы с kubectl apply -f ...

apiVersion: v1
kind: Service
metadata:
  name: kube-dns
  namespace: kube-system
  annotations:
    prometheus.io/port: "9153"
    prometheus.io/scrape: "true"
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "CoreDNS"
spec:
  selector:
    k8s-app: kube-dns
  clusterIP: 10.96.0.10
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP

Примечание. Это нелогично, что имя службы CoreDNS по-прежнему называется «kube-dns», но оно выбирает модули coredns (которые используют метку селектора «kube-dns»).

У меня та же проблема, что и у OP, и описание и вариант использования примерно такие же: kubeadm на Centos 7.5 с одним мастером, который также работает как рабочий узел. У меня такая же проблема, и у меня есть услуга:

λ k get all --all-namespaces
NAMESPACE        NAME                                                READY     STATUS             RESTARTS   AGE
default          pod/busybox                                         0/1       Error              0          28m
default          pod/gitlab-gitlab-fd8b9fb85-26mkz                   0/1       CrashLoopBackOff   6          50m
default          pod/gitlab-minio-7fb7886d94-2zsff                   1/1       Running            0          50m
default          pod/gitlab-postgresql-8684bb6656-ltxjm              1/1       Running            0          50m
default          pod/gitlab-redis-785447c586-84x4c                   1/1       Running            0          50m
default          pod/ldap-79bb8c66b9-68v9f                           1/1       Running            0          2d
default          pod/local-volume-provisioner-dkxm9                  1/1       Running            0          2d
kube-system      pod/coredns-78fcdf6894-2t8tv                        1/1       Running            0          2d
kube-system      pod/coredns-78fcdf6894-wvq26                        1/1       Running            0          2d
kube-system      pod/etcd-server1.stitches.tech                      1/1       Running            0          2d
kube-system      pod/kube-apiserver-server1.domain            1/1       Running            0          2d
kube-system      pod/kube-controller-manager-server1.domain   1/1       Running            0          2d
kube-system      pod/kube-flannel-ds-m9cz5                           1/1       Running            0          2d
kube-system      pod/kube-proxy-qhr8p                                1/1       Running            0          2d
kube-system      pod/kube-scheduler-server1.domain            1/1       Running            0          2d
kube-system      pod/kubernetes-dashboard-6948bdb78-qnp4b            1/1       Running            0          2d
kube-system      pod/tiller-deploy-56c4cf647b-64w8v                  1/1       Running            0          2d
metallb-system   pod/controller-9c57dbd4-fqhzb                       1/1       Running            0          2d
metallb-system   pod/speaker-tngv7                                   1/1       Running            0          2d

NAMESPACE     NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                   AGE
default       service/gitlab-gitlab          LoadBalancer   10.102.204.34   192.168.1.201   22:32208/TCP,80:32194/TCP,443:31370/TCP   50m
default       service/gitlab-minio           ClusterIP      None            <none>          9000/TCP                                  50m
default       service/gitlab-postgresql      ClusterIP      10.108.66.88    <none>          5432/TCP                                  50m
default       service/gitlab-redis           ClusterIP      10.97.59.57     <none>          6379/TCP                                  50m
default       service/kubernetes             ClusterIP      10.96.0.1       <none>          443/TCP                                   2d
default       service/ldap-service           LoadBalancer   10.101.250.10   192.168.1.200   389:32231/TCP                             2d
kube-system   service/kube-dns               ClusterIP      10.96.0.10      <none>          53/UDP,53/TCP                             2d
kube-system   service/kubernetes-dashboard   NodePort       10.104.132.52   <none>          443:30924/TCP                             2d
kube-system   service/tiller-deploy          ClusterIP      10.96.67.163    <none>          44134/TCP                                 2d

NAMESPACE        NAME                                      DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
default          daemonset.apps/local-volume-provisioner   1         1         1         1            1           <none>                          2d
kube-system      daemonset.apps/kube-flannel-ds            1         1         1         1            1           beta.kubernetes.io/arch=amd64   2d
kube-system      daemonset.apps/kube-proxy                 1         1         1         1            1           beta.kubernetes.io/arch=amd64   2d
metallb-system   daemonset.apps/speaker                    1         1         1         1            1           <none>                          2d

NAMESPACE        NAME                                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
default          deployment.apps/gitlab-gitlab          1         1         1            0           50m
default          deployment.apps/gitlab-minio           1         1         1            1           50m
default          deployment.apps/gitlab-postgresql      1         1         1            1           50m
default          deployment.apps/gitlab-redis           1         1         1            1           50m
default          deployment.apps/ldap                   1         1         1            1           2d
kube-system      deployment.apps/coredns                2         2         2            2           2d
kube-system      deployment.apps/kubernetes-dashboard   1         1         1            1           2d
kube-system      deployment.apps/tiller-deploy          1         1         1            1           2d
metallb-system   deployment.apps/controller             1         1         1            1           2d

NAMESPACE        NAME                                             DESIRED   CURRENT   READY     AGE
default          replicaset.apps/gitlab-gitlab-fd8b9fb85          1         1         0         50m
default          replicaset.apps/gitlab-minio-7fb7886d94          1         1         1         50m
default          replicaset.apps/gitlab-postgresql-8684bb6656     1         1         1         50m
default          replicaset.apps/gitlab-redis-785447c586          1         1         1         50m
default          replicaset.apps/ldap-79bb8c66b9                  1         1         1         2d
kube-system      replicaset.apps/coredns-78fcdf6894               2         2         2         2d
kube-system      replicaset.apps/kubernetes-dashboard-6948bdb78   1         1         1         2d
kube-system      replicaset.apps/tiller-deploy-56c4cf647b         1         1         1         2d
kube-system      replicaset.apps/tiller-deploy-64c9d747bd         0         0         0         2d
metallb-system   replicaset.apps/controller-9c57dbd4              1         1         1         2d

Из модулей CoreDNS я не могу выполнять поиск во внешнем мире, что кажется странным:

root on server1 at 11:45:48 AM in /internal/gitlab
λ k exec -it coredns-78fcdf6894-2t8tv /bin/sh -n kube-system
/ # cat /etc/resolv.conf
nameserver 192.168.1.254
nameserver 2600:1700:c540:64c0::1
search attlocal.net domain
/ # host gitlab
;; connection timed out; no servers could be reached
/ # host google.com
;; connection timed out; no servers could be reached

Для меня это означает, что модуль CoreDNS не может видеть свой вышестоящий сервер имен, который является 192.168.1.254, IP-адресом сети хоста. Я на правильном пути?

Но что еще более странно, так это то, что модуль, работающий на этом главном узле, МОЖЕТ легко достичь этого IP-адреса:

λ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools
If you don't see a command prompt, try pressing enter.
dnstools# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254): 56 data bytes
64 bytes from 192.168.1.254: seq=0 ttl=63 time=1.102 ms

Можете ли вы попробовать с dig ?

dig google.com @192.168.1.254

Также обычно системы с допустимой конфигурацией ipv6 сначала пытаются выполнить разрешение с помощью этого преобразователя ipv6. Если это не удается, эти системы называют это отказом. Сначала взгляните на команду dig, если она работает, я бы посмотрел, настроена ли система с двойным стеком ipv4 ipv6 или нет.

Еще раз спасибо

Мое решение (хотя на данный момент оно довольно ужасное) заключалось в том, чтобы просто отключить службу firewalld в моей ОС:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Помните, что на самом деле делает эта команда. Делайте это на свой страх и риск.

Я столкнулся с той же проблемой с kubernetes 1.11.2 и flannel 0.10.0, развернутыми на виртуальной машине CentOS 7 через kubeadm с kube-proxy, настроенным на использование iptables. Что я заметил, так это то, что у меня не было модуля для модуля или модуля для обслуживания связи после первоначального развертывания. Глядя на цепочку FORWARD в iptables, kube-proxy устанавливает цепочку KUBE-FORWARD в качестве первого правила, которое после проверки должно обрабатывать весь трафик, описанный выше. Фланель добавила два правила после правил DROP и REJECT, которые используются по умолчанию в цепочке CentOS 7 FORWARD. Я заметил, что когда я удалил правило REJECT, правила, добавленные Flannel, обрабатывали трафик, и мои модули могли взаимодействовать с другими модулями и с IP-адресами служб.

Поскольку kube-proxy отслеживает изменение KUBE-FORWARD и предотвращает его изменение, я добавил два правила после правила KUBE-FORWARD, которое добавило ctstate NEW. Как только я добавлю эти правила, внутренний трафик будет обрабатываться так, как я ожидал.

Пожалуйста, проверьте переменную clusterDNS в /var/lib/kubelet/config.yaml . Для нашей конфигурации это было установлено (неправильно) на 10.96.0.10 тогда как это должно было быть 10.244.240.10 (это то, с чем мы загрузили наш кластер). Изменение этого параметра и перезапуск kubelet устранили проблему для нас. Однако ваш пробег может отличаться.

@pkeuter , 10.244.0.0/16 - это cidr _pod_ по умолчанию для фланели. Если это так в вашем случае, тогда 10.244.240.10 будет IP-адресом модуля, который вы не должны использовать в качестве настройки IP-адреса cluster-dns (re: он может измениться, без балансировки нагрузки).

Нет:

Мы загрузили кластер с помощью: --pod-network-cidr=10.244.0.0/16 --service-cidr=10.244.240.0/20 , но, как я теперь вижу, есть некоторые совпадения, которые я все равно должен изменить :-) Так что спасибо за этот @chrisohaver!

Пожалуйста, проверьте переменную clusterDNS в /var/lib/kubelet/config.yaml . Для нашей конфигурации это было установлено (неправильно) на 10.96.0.10 тогда как это должно было быть 10.244.240.10 (это то, с чем мы загрузили наш кластер). Изменение этого параметра и перезапуск kubelet устранили проблему для нас. Однако ваш пробег может отличаться.

Спасибо за это - это помогло мне отследить, почему мои внутренние DNS-запросы не разрешались.

Для справки, мне пришлось установить значение clusterDNS на 192.168.0.10, когда я инициализирую kubeadm с --service-cidr = 192.168.0.0 / 16, и моя служба kube-dns имеет это как внешний IP-адрес.

Также следует отметить, что простого перезапуска kubelet было недостаточно - мне пришлось перезапустить свои поды, поэтому /etc/resolv.conf был обновлен. Один из выполненных запросов разрешается, как и ожидалось.

На coreDNS возник ряд проблем, которые с тех пор были решены. Учитывая перегруженный набор проблем, я собираюсь закрыть эту.

Если есть конкретные репро на версии 1.12+, не стесняйтесь открывать, и мы рассмотрим их как можно скорее.

Пожалуйста, проверьте переменную clusterDNS в /var/lib/kubelet/config.yaml . Для нашей конфигурации это было установлено (неправильно) на 10.96.0.10 тогда как это должно было быть 10.244.240.10 (это то, с чем мы загрузили наш кластер). Изменение этого параметра и перезапуск kubelet устранили проблему для нас. Однако ваш пробег может отличаться.

отлично, и я использую calico, какой адрес clusterDNS мне следует установить?

Я сделал то же самое, но столкнулся с той же ошибкой, что мои стручки coredns не начали выдавать состояние ошибки

Я изменил свой ClusterDNS, но все еще без эффекта @justlooks

+1 Та же проблема в CentOS 7 и kubeadm 1.11

@timothysc

Добавление iptables -p FORWARD ACCEPT устранило проблему.

+1 Та же проблема в CentOS 7 и kubeadm 1.12

нашел решение проблемы.
удален лимит ресурсов на основном контроллере демона DNS, поскольку он достиг лимита процессора. что заставляло его перезапускаться.

Возможно, проблема с фланелью, в моем случае у бродяги есть интерфейс mutil, поэтому при развертывании фланели необходимо указать интерфейс: - --iface=eth1 , иначе возникнет та же проблема с DNS ...

https://github.com/kubernetes/kubernetes/issues/39701

vim https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml изменено следующим образом:

......
containers:
      - name: kube-flannel
        image: quay.io/coreos/flannel:v0.11.0-amd64
        command:
        - /opt/bin/flanneld
        args:
        - --ip-masq
        - --kube-subnet-mgr
        - --iface=eth1
......

Спасибо @pkeuter ,