Kubeadm: Implementación nueva con CoreDNS que no resuelve ninguna búsqueda de dns

Por el motivo que sea, no hay servicio kube-dns en su clúster.
Primero deberá volver a crearlo a mano para arreglar las cosas. Entonces podemos intentar averiguar cómo desapareció.

Puede usar este yaml para crear el servicio con 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

Nota: Es contrario a la intuición que el nombre del servicio CoreDNS todavía se llame "kube-dns", pero selecciona los pods de coredns (que usan la etiqueta de selector "kube-dns ').

Tengo el mismo problema que OP, y la descripción y el caso de uso son casi iguales: kubeadm en Centos 7.5 con un maestro que también funciona como nodo trabajador. Tengo el mismo problema y el servicio SI 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

Desde los pods de CoreDNS, parece que no puedo hacer búsquedas en el mundo exterior, lo que parece extraño:

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

Para mí, esto significa que el pod CoreDNS no puede ver su servidor de nombres ascendente, que es 192.168.1.254, la IP de la red de host. ¿Estoy en el camino correcto?

Pero, lo que es aún más extraño, es que un pod que se ejecuta en ese nodo maestro PUEDE alcanzar esa dirección IP sin problemas:

λ 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

¿Puedes probar con dig ?

dig google.com @192.168.1.254

Además, normalmente los sistemas con una configuración ipv6 válida intentarán resolver primero con ese solucionador de ipv6. Si eso falla, estos sistemas lo llaman falla. Primero eche un vistazo al comando dig, si eso funciona, vería si el sistema está configurado con ipv4 ipv6 de doble pila o no.

¡Gracias nuevamente a @mauilion por dedicar tanto tiempo ayudándome a diagnosticar este problema hoy!

Mi solución (aunque bastante terrible por ahora) fue simplemente deshabilitar el servicio firewalld en mi sistema operativo host:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Tenga en cuenta lo que realmente está haciendo ese comando. Hágalo bajo su propio riesgo.

Me encontré con el mismo problema con kubernetes 1.11.2 y flannel 0.10.0 implementados en una VM CentOS 7 a través de kubeadm con un proxy kube configurado para usar iptables. Lo que noté es que no tenía comunicaciones de pod a pod o pod a servicio después de la implementación inicial. Mirando la cadena FORWARD en iptables, kube-proxy configuró una cadena KUBE-FORWARD como la primera regla que, tras la inspección, debería manejar todo el tráfico que describí anteriormente. Flannel agregó dos reglas después de las reglas DROP y REJECT que son predeterminadas en la cadena FORWARD de CentOS 7. Me di cuenta de que cuando eliminé la regla REJECT, las reglas agregadas por Flannel procesarían el tráfico y mis pods podrían comunicarse con otros pods y con los ips de servicio.

Dado que kube-proxy monitorea el cambio de KUBE-FORWARD y evita que cambie, agregué dos reglas después de la regla KUBE-FORWARD que agregó el ctstate de NEW. Una vez que agregué estas reglas, el tráfico interno se procesaría como esperaba.

Compruebe la variable clusterDNS en /var/lib/kubelet/config.yaml . Para nuestra configuración, esto se estableció (incorrectamente) en 10.96.0.10 mientras que debería haber sido 10.244.240.10 (con eso hemos iniciado nuestro clúster). Cambiar esto y reiniciar kubelet nos solucionó el problema. Sin embargo, su millaje puede variar.

@pkeuter , 10.244.0.0/16 es el _pod_ cidr predeterminado para franela. Si eso es así en su caso, entonces 10.244.240.10 sería una IP de pod, que no debe usar como configuración de ip de cluster-dns (re: podría cambiar, sin equilibrio de carga).

No lo es:

Hemos arrancado el clúster con: --pod-network-cidr=10.244.0.0/16 --service-cidr=10.244.240.0/20 , pero como veo ahora hay algo de superposición, que debería cambiar de todos modos :-) ¡Así que gracias por eso @chrisohaver!

Compruebe la variable clusterDNS en /var/lib/kubelet/config.yaml . Para nuestra configuración, esto se estableció (incorrectamente) en 10.96.0.10 mientras que debería haber sido 10.244.240.10 (con eso hemos iniciado nuestro clúster). Cambiar esto y reiniciar kubelet nos solucionó el problema. Sin embargo, su millaje puede variar.

Gracias por esto, me ayudó a rastrear por qué mis solicitudes de DNS internas no se estaban resolviendo.

Como referencia, tuve que establecer mi valor clusterDNS en 192.168.0.10 cuando inicié kubeadm con --service-cidr = 192.168.0.0 / 16 y mi servicio kube-dns tiene eso como su IP externa.

También es de destacar que simplemente reiniciar kubelet no fue suficiente: tuve que reiniciar mis pods para actualizar /etc/resolv.conf. Una que se hizo, las solicitudes se están resolviendo como se esperaba.

Hubo una serie de problemas de combinación en coreDNS que desde entonces se han resuelto. Dado el conjunto de problemas sobrecargados, voy a cerrar este.

Si hay reproducciones específicas en 1.12+, no dude en abrir y lo abordaremos lo antes posible.

Compruebe la variable clusterDNS en /var/lib/kubelet/config.yaml . Para nuestra configuración, esto se estableció (incorrectamente) en 10.96.0.10 mientras que debería haber sido 10.244.240.10 (con eso hemos iniciado nuestro clúster). Cambiar esto y reiniciar kubelet nos solucionó el problema. Sin embargo, su millaje puede variar.

genial, y uso calico, ¿qué dirección clusterDNS debo configurar?

Hice lo mismo pero enfrentando el mismo error, mis pods de coredns no comienzan a dar un estado de error

Cambié mi ClusterDNS pero aún no tiene efecto @justlooks

+1 Enfrentando el mismo problema en CentOS 7 y kubeadm 1.11

@timothysc

Agregar iptables -p FORWARD ACCEPT solucionó el problema

+1 Enfrentando el mismo problema en CentOS 7 y kubeadm 1.12

encontró la solución para el problema.
Se eliminó el límite de recursos en el controlador del demonio dns principal ya que estaba alcanzando el límite de CPU. que lo estaba haciendo reiniciar.

Tal vez el problema de la franela, en mi caso, el vagabundo tiene una interfaz de red múltiple, por lo que debe especificar la interfaz al implementar la franela: - --iface=eth1 , de lo contrario, va a suceder el mismo problema de dns ...

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

vim https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml modificado de la siguiente manera:

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

Gracias @pkeuter , solucionó el problema y tuve que eliminar los pods de coredns y dejar que lo volvieran a crear.