Kubeadm: Nouveau déploiement avec CoreDNS ne résolvant aucune recherche DNS

Pour une raison quelconque, il n'y a pas de service kube-dns sur votre cluster.
Vous devrez d'abord recréer cela à la main pour réparer les choses. Ensuite, nous pouvons essayer de comprendre comment il a disparu.

Vous pouvez utiliser ce yaml pour créer le service avec 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

Remarque: il est contre-intuitif que le nom du service CoreDNS soit toujours nommé "kube-dns", mais il sélectionne les pods coredns (qui utilisent le libellé de sélecteur "kube-dns ').

J'ai le même problème que OP, et la description et le cas d'utilisation sont à peu près les mêmes: kubeadm sur Centos 7.5 avec un maître qui fonctionne également en tant que nœud de travail. J'ai le même problème et je le service existe:

λ 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

À partir des pods CoreDNS, je n'arrive pas à faire des recherches vers le monde extérieur, ce qui semble étrange:

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

Pour moi, cela signifie que le pod CoreDNS ne peut pas voir son serveur de noms en amont, qui est 192.168.1.254, l'adresse IP du réseau hôte. Suis-je sur la bonne voie?

Mais, ce qui est encore plus étrange, c'est qu'un pod fonctionnant sur ce nœud maître PEUT atteindre cette adresse IP très bien:

λ 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

Pouvez-vous essayer avec dig ?

dig google.com @192.168.1.254

En général, les systèmes avec une configuration ipv6 valide essaieront également de résoudre d'abord avec ce résolveur ipv6. Si cela échoue, ces systèmes appellent cela un échec. Jetez un coup d'œil à la commande dig d'abord si cela fonctionne, je regarderais pour voir si le système est configuré avec ipv4 ipv6 double pile ou non.

Merci encore à @mauilion d'avoir passé autant de temps à m'aider à diagnostiquer ce problème aujourd'hui!

Ma solution (bien que ce soit assez terrible pour le moment) consistait simplement à désactiver le service firewalld sur mon OS hôte:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Gardez à l'esprit ce que fait réellement cette commande. Faites-le à vos risques et périls.

J'ai rencontré le même problème avec kubernetes 1.11.2 et flannel 0.10.0 déployés sur une machine virtuelle CentOS 7 via kubeadm avec un kube-proxy configuré pour utiliser iptables. Ce que j'ai remarqué, c'est que je n'avais pas de communication pod à pod ou pod à service après le déploiement initial. En regardant la chaîne FORWARD sur iptables, kube-proxy a mis en place une chaîne KUBE-FORWARD comme première règle qui devrait, après inspection, gérer tout le trafic que j'ai décrit ci-dessus. Flannel a ajouté deux règles après les règles DROP et REJECT qui sont par défaut dans la chaîne CentOS 7 FORWARD. J'ai remarqué que lorsque j'ai supprimé la règle REJECT, les règles ajoutées par Flannel traiteraient le trafic et mes pods pouvaient communiquer avec d'autres pods et avec des ips de service.

Puisque kube-proxy surveille le changement de KUBE-FORWARD et l'empêche de changer, j'ai ajouté deux règles après la règle KUBE-FORWARD qui a ajouté le ctstate de NEW. Une fois que j'ai ajouté ces règles, le trafic interne serait traité comme je m'y attendais.

Veuillez vérifier la variable clusterDNS dans /var/lib/kubelet/config.yaml . Pour notre configuration, cela a été défini (incorrectement) sur 10.96.0.10 alors qu'il aurait dû être 10.244.240.10 (c'est ce avec quoi nous avons amorcé notre cluster). Changer cela et redémarrer kubelet a résolu le problème pour nous. Votre kilométrage peut cependant varier.

@pkeuter , 10.244.0.0/16 est la valeur par défaut du _pod_ cidr pour la flanelle. Si tel est le cas dans votre cas, alors 10.244.240.10 serait une adresse IP de pod, que vous ne devriez pas utiliser comme paramètre IP de cluster-dns (re: cela pourrait changer, pas d'équilibrage de charge).

Ce n'est pas:

Nous avons amorcé le cluster avec: --pod-network-cidr=10.244.0.0/16 --service-cidr=10.244.240.0/20 , mais comme je le vois maintenant, il y a un chevauchement, que je devrais quand même changer :-) Alors merci pour ça @chrisohaver!

Veuillez vérifier la variable clusterDNS dans /var/lib/kubelet/config.yaml . Pour notre configuration, cela a été défini (incorrectement) sur 10.96.0.10 alors qu'il aurait dû être 10.244.240.10 (c'est ce avec quoi nous avons amorcé notre cluster). Changer cela et redémarrer kubelet a résolu le problème pour nous. Votre kilométrage peut cependant varier.

Merci pour cela - cela m'a aidé à déterminer pourquoi mes requêtes DNS internes ne se résolvaient pas.

Pour référence, j'ai dû définir ma valeur clusterDNS sur 192.168.0.10 lorsque j'initialise kubeadm avec --service-cidr = 192.168.0.0 / 16 et mon service kube-dns l'a comme adresse IP externe.

Notez également que le simple fait de redémarrer kubelet n'était pas suffisant - j'ai dû redémarrer mes pods pour que /etc/resolv.conf soit mis à jour. Les demandes qui ont été traitées se résolvent comme prévu.

Il y avait un certain nombre de problèmes contradictoires sur coreDNS qui ont depuis été résolus. Compte tenu de l'ensemble surchargé de problèmes, je vais fermer celui-ci.

S'il y a des repro spécifiques sur 1.12+, n'hésitez pas à ouvrir et nous nous en occuperons dès que possible.

Veuillez vérifier la variable clusterDNS dans /var/lib/kubelet/config.yaml . Pour notre configuration, cela a été défini (incorrectement) sur 10.96.0.10 alors qu'il aurait dû être 10.244.240.10 (c'est ce avec quoi nous avons amorcé notre cluster). Changer cela et redémarrer kubelet a résolu le problème pour nous. Votre kilométrage peut cependant varier.

super, et j'utilise calico quelle adresse clusterDNS dois-je définir?

J'ai fait la même chose mais face à la même erreur, mes pods coredns ne commencent pas à donner un état d'erreur

J'ai changé mon ClusterDNS mais toujours aucun effet @justlooks

+1 Face au même problème dans CentOS 7 et kubeadm 1.11

@timothysc

L'ajout de iptables -p FORWARD ACCEPT résolu le problème

+1 Face au même problème dans CentOS 7 et kubeadm 1.12

trouvé la résolution du problème.
Suppression de la limite de ressources sur le contrôleur de démon DNS principal car il atteignait la limite du processeur. ce qui le faisait redémarrer.

Peut-être que le problème de la flanelle, dans mon cas, le vagabond a une interface réseau mutil, il faut donc spécifier l'interface lors du déploiement de la flanelle: - --iface=eth1 , sinon le même problème DNS va se produire ...

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

vim https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml modifié comme suit:

......
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
......

Merci @pkeuter , cela a résolu le problème et j'ai dû supprimer les pods coredns et les laisser le recréer.