Kubeadm: Neubereitstellung mit CoreDNS ohne Auflösung der DNS-Suche

Aus irgendeinem Grund gibt es in Ihrem Cluster keinen kube-dns -Dienst.
Sie müssen das zuerst von Hand neu erstellen, um die Probleme zu beheben. Dann können wir versuchen herauszufinden, wie es verschwunden ist.

Sie können dieses Yaml verwenden, um den Service mit kubectl apply -f ... zu erstellen.

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

Hinweis: Es ist nicht intuitiv, dass der CoreDNS-Dienstname weiterhin "kube-dns" heißt, aber die coredns-Pods auswählt (die die Auswahlbezeichnung "kube-dns" verwenden).

Ich habe das gleiche Problem wie OP, und die Beschreibung und der Anwendungsfall sind ungefähr gleich: kubeadm auf Centos 7.5 mit einem Master, der auch als Worker-Knoten fungiert. Ich habe das gleiche Problem und ich den Dienst existiert:

λ 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

Von den CoreDNS-Pods aus kann ich anscheinend nicht nach außen schauen, was seltsam erscheint:

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

Für mich bedeutet dies, dass der CoreDNS-Pod seinen Upstream-Nameserver nicht sehen kann. Dies ist 192.168.1.254, die IP des Host-Netzwerks. Bin ich auf dem richtigen Weg?

Noch seltsamer ist jedoch, dass ein Pod, der auf diesem Masterknoten ausgeführt wird, diese IP-Adresse problemlos erreichen kann:

λ 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

Können Sie es mit dig versuchen?

dig google.com @192.168.1.254

Außerdem versuchen normalerweise Systeme mit einer gültigen IPv6-Konfiguration, diese zuerst mit diesem IPv6-Resolver aufzulösen. Wenn dies fehlschlägt, nennen diese Systeme dies einen Fehler. Schauen Sie sich zuerst den Befehl dig an, wenn dies funktioniert. Ich würde prüfen, ob das System mit Dual-Stack-IPv4-IPv6 konfiguriert ist oder nicht.

Nochmals vielen Dank an

Meine Lösung (obwohl es im Moment ziemlich schrecklich ist) bestand darin, den Dienst firewalld auf meinem Host-Betriebssystem zu deaktivieren:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Denken Sie daran, was dieser Befehl tatsächlich tut. Tun Sie dies auf eigenes Risiko.

Ich bin auf dasselbe Problem mit kubernetes 1.11.2 und Flannel 0.10.0 gestoßen, die über kubeadm mit einem für die Verwendung von iptables konfigurierten kube-Proxy auf einer CentOS 7-VM bereitgestellt wurden. Was mir aufgefallen ist, dass ich nach der ersten Bereitstellung keinen Pod-to-Pod oder Pod-to-Service-Kommunikation hatte. Mit Blick auf die FORWARD-Kette auf iptables hat kube-proxy als erste Regel eine KUBE-FORWARD-Kette eingerichtet, die nach Überprüfung den gesamten oben beschriebenen Datenverkehr verarbeiten soll. Flannel fügte zwei Regeln nach den DROP- und REJECT-Regeln hinzu, die in der CentOS 7 FORWARD-Kette standardmäßig verwendet werden. Als ich die REJECT-Regel entfernte, bemerkte ich, dass die von Flannel hinzugefügten Regeln den Datenverkehr verarbeiteten und meine Pods mit anderen Pods und mit Service-IPs kommunizieren konnten.

Da kube-proxy die KUBE-FORWARD-Änderung überwacht und verhindert, dass sie sich ändert, habe ich nach der KUBE-FORWARD-Regel zwei Regeln hinzugefügt, die den ctstate von NEW hinzugefügt haben. Sobald ich diese Regeln hinzugefügt habe, wird der interne Datenverkehr wie erwartet verarbeitet.

Bitte überprüfen Sie die Variable clusterDNS in /var/lib/kubelet/config.yaml . Für unsere Konfiguration wurde dies (fälschlicherweise) auf 10.96.0.10 während es 10.244.240.10 (damit haben wir unseren Cluster gebootet). Das zu ändern und Kubelet neu zu starten, hat das Problem für uns behoben. Ihr Kilometerstand kann jedoch variieren.

@pkeuter , 10.244.0.0/16 ist die Standardeinstellung _pod_ cidr für Flanell. Wenn dies in Ihrem Fall der Fall ist, ist 10.244.240.10 eine Pod-IP, die Sie nicht als IP-Einstellung für Cluster-DNS verwenden sollten (bezüglich: es könnte sich ändern, kein Lastausgleich).

Es ist nicht:

Wir haben den Cluster gebootet mit: --pod-network-cidr=10.244.0.0/16 --service-cidr=10.244.240.0/20 , aber wie ich jetzt sehe, gibt es einige Überlappungen, die ich sowieso ändern sollte :-) Also danke für das @chrisohaver!

Bitte überprüfen Sie die Variable clusterDNS in /var/lib/kubelet/config.yaml . Für unsere Konfiguration wurde dies (fälschlicherweise) auf 10.96.0.10 während es 10.244.240.10 (damit haben wir unseren Cluster gebootet). Das zu ändern und Kubelet neu zu starten, hat das Problem für uns behoben. Ihr Kilometerstand kann jedoch variieren.

Vielen Dank dafür - es hat mir geholfen herauszufinden, warum meine internen DNS-Anfragen nicht gelöst wurden.

Als Referenz musste ich meinen clusterDNS-Wert auf 192.168.0.10 setzen, da ich kubeadm mit --service-cidr = 192.168.0.0 / 16 initiiere und mein kube-dns-Dienst dies als externe IP hat.

Bemerkenswert ist auch, dass es nicht ausreicht, kubelet einfach neu zu starten - ich musste meine Pods neu starten, damit /etc/resolv.conf aktualisiert wurde. Eine erledigte Anforderung wird wie erwartet gelöst.

Es gab eine Reihe von Konflikten bei coreDNS, die inzwischen behoben wurden. Angesichts der überlasteten Probleme werde ich dieses schließen.

Wenn es bestimmte Repros ab 1.12 gibt, können Sie diese gerne öffnen und wir werden uns umgehend mit Ihnen in Verbindung setzen.

Bitte überprüfen Sie die Variable clusterDNS in /var/lib/kubelet/config.yaml . Für unsere Konfiguration wurde dies (fälschlicherweise) auf 10.96.0.10 während es 10.244.240.10 (damit haben wir unseren Cluster gebootet). Das zu ändern und Kubelet neu zu starten, hat das Problem für uns behoben. Ihr Kilometerstand kann jedoch variieren.

toll, und ich benutze calico welche clusterDNS adresse soll ich setzen?

Ich habe das Gleiche getan, aber mit dem gleichen Fehler konfrontiert. Meine Coredns-Pods geben keinen Fehlerstatus an

Ich habe mein ClusterDNS geändert, aber immer noch keine Auswirkung @justlooks

+1 Angesichts des gleichen Problems in CentOS 7 und kubeadm 1.11

@ Timothysc

Das Hinzufügen von iptables -p FORWARD ACCEPT das Problem behoben

+1 Angesichts des gleichen Problems in CentOS 7 und kubeadm 1.12

fand die Lösung für das Problem.
Das Ressourcenlimit auf dem Kern-DNS-Daemon-Controller wurde entfernt, als das CPU-Limit erreicht wurde. was es neu starten ließ.

Vielleicht hat das Flanellproblem, in meinem Fall, der Vagrant eine verstümmelte Netzwerkschnittstelle, muss also die Schnittstelle angeben, wenn Flanell bereitgestellt wird: - --iface=eth1 , sonst wird das gleiche DNS-Problem auftreten ...

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

vim https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml wie folgt geändert:

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

Danke @pkeuter , es hat das Problem behoben und ich musste die coredns-Pods löschen und sie neu erstellen lassen.