Kubeadm: Nova implantação com CoreDNS não resolvendo nenhuma pesquisa de dns

Por alguma razão, não há serviço kube-dns em seu cluster.
Você primeiro precisará recriar isso manualmente para consertar as coisas. Então, podemos tentar descobrir como ele desapareceu.

Você pode usar este yaml para criar o serviço com 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

Observação: é contra-intuitivo que o nome do serviço CoreDNS ainda seja denominado "kube-dns", mas ele seleciona os pods coredns (que usam o rótulo do seletor "kube-dns ').

Estou tendo o mesmo problema que o OP, e a descrição e o caso de uso são praticamente os mesmos: kubeadm no Centos 7.5 com um mestre que está operando como o nó de trabalho também. Tenho o mesmo problema e o serviço 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

Dos pods CoreDNS, não consigo fazer pesquisas no mundo exterior, o que parece estranho:

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 mim, isso significa que o pod CoreDNS não pode ver seu servidor de nomes upstream, que é 192.168.1.254, o IP da rede host. Estou no caminho certo?

Mas, o que é ainda mais estranho, é que um pod em execução nesse nó mestre PODE alcançar esse endereço IP perfeitamente:

λ 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

Você pode tentar com dig ?

dig google.com @192.168.1.254

Além disso, normalmente, os sistemas com uma configuração ipv6 válida tentarão resolver primeiro com esse resolvedor ipv6. Se isso falhar, esses sistemas chamam de falha. Dê uma olhada no comando dig primeiro, se isso funciona, eu verificaria se o sistema está configurado com dual stack ipv4 ipv6 ou não.

Obrigado novamente a @mauilion por gastar tanto tempo me ajudando a diagnosticar esse problema hoje!

Minha solução (embora seja terrível por enquanto) foi apenas desativar o serviço firewalld em meu sistema operacional host:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Lembre-se do que esse comando está realmente fazendo. Faça isso por sua própria conta e risco.

Eu tive o mesmo problema com kubernetes 1.11.2 e flanela 0.10.0 implantados em uma VM CentOS 7 via kubeadm com um proxy kube configurado para usar iptables. O que percebi é que não tive comunicações pod a pod ou pod to service após a implantação inicial. Olhando para a cadeia FORWARD no iptables, o kube-proxy configurou uma cadeia KUBE-FORWARD como a primeira regra que deve, após inspeção, lidar com todo o tráfego que descrevi acima. Flannel anexou duas regras após as regras DROP e REJECT que são padrão na cadeia CentOS 7 FORWARD. Percebi que quando removi a regra REJECT, as regras adicionadas por Flannel processariam o tráfego e meus pods poderiam se comunicar com outros pods e com ips de serviço.

Como o kube-proxy monitora a mudança KUBE-FORWARD e evita que ela mude, adicionei duas regras após a regra KUBE-FORWARD que adicionou o ctstate de NEW. Depois de adicionar essas regras, o tráfego interno seria processado conforme o esperado.

Verifique a variável clusterDNS em /var/lib/kubelet/config.yaml . Para nossa configuração, isso foi definido (incorretamente) para 10.96.0.10 passo que deveria ter sido 10.244.240.10 (foi com isso que inicializamos nosso cluster). Alterar isso e reiniciar o kubelet corrigiu o problema para nós. Porém, sua milhagem pode variar.

@pkeuter , 10.244.0.0/16 é o padrão _pod_ cidr para flanela. Se esse for o seu caso, 10.244.240.10 seria um pod IP, que você não deve usar como configuração de IP de cluster-dns (re: ele pode mudar, sem balanceamento de carga).

Não é:

Nós inicializamos o cluster com: --pod-network-cidr=10.244.0.0/16 --service-cidr=10.244.240.0/20 , mas como vejo agora há alguma sobreposição, que eu deveria mudar de qualquer maneira :-) Então, obrigado por esse @chrisohaver!

Verifique a variável clusterDNS em /var/lib/kubelet/config.yaml . Para nossa configuração, isso foi definido (incorretamente) para 10.96.0.10 passo que deveria ter sido 10.244.240.10 (foi com isso que inicializamos nosso cluster). Alterar isso e reiniciar o kubelet corrigiu o problema para nós. Porém, sua milhagem pode variar.

Obrigado por isso - me ajudou a rastrear por que minhas solicitações de DNS interno não estavam resolvendo.

Para referência, eu tive que definir meu valor clusterDNS para 192.168.0.10 enquanto eu inicio kubeadm com --service-cidr = 192.168.0.0 / 16 e meu serviço kube-dns tem isso como seu IP externo.

Também digno de nota, simplesmente reiniciar o kubelet não foi suficiente - eu tive que reiniciar meus pods para que o /etc/resolv.conf fosse atualizado. As solicitações feitas estão sendo resolvidas conforme o esperado.

Houve uma série de questões conflitantes no coreDNS que já foram resolvidas. Dado o conjunto sobrecarregado de problemas, fecharei este.

Se houver representantes específicos em 1.12+, sinta-se à vontade para abrir e trataremos o mais rápido possível.

Verifique a variável clusterDNS em /var/lib/kubelet/config.yaml . Para nossa configuração, isso foi definido (incorretamente) para 10.96.0.10 passo que deveria ter sido 10.244.240.10 (foi com isso que inicializamos nosso cluster). Alterar isso e reiniciar o kubelet corrigiu o problema para nós. Porém, sua milhagem pode variar.

Ótimo, e eu uso calico, qual endereço clusterDNS devo definir?

Eu fiz o mesmo, mas enfrentando o mesmo erro, meus pods coredns não começaram a apresentar estado de erro

Eu mudei meu ClusterDNS, mas ainda sem efeito @justlooks

+1 Enfrentando o mesmo problema no CentOS 7 e kubeadm 1.11

@timothysc

Adicionar iptables -p FORWARD ACCEPT corrigiu o problema

+1 Enfrentando o mesmo problema no CentOS 7 e kubeadm 1.12

encontrou a resolução para o problema.
removeu o limite de recursos no controlador daemon de dns central, pois ele estava atingindo o limite da CPU. o que o estava fazendo reiniciar.

Talvez o problema da flanela, no meu caso, o vagrant tem interface de rede mutil, então deve especificar a interface ao implantar flanela: - --iface=eth1 , caso contrário, o mesmo problema de dns vai acontecer ...

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

vim https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml modificado da seguinte forma:

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

Obrigado @pkeuter , ele corrigiu o problema e tive que excluir os pods coredns e deixá-los recriá-lo.