@bravinash Qual é a saída de kubectl -n kube-system describe pod <coredns-pod-name> ?

vou tentar fazer isso mais tarde hoje, eu mesmo.

@bravinash não posso confirmar o problema:

NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   calico-node-x2l7f                    2/2     Running   0          93s
kube-system   coredns-576cbf47c7-6qn92             1/1     Running   0          93s
kube-system   coredns-576cbf47c7-vk2h5             1/1     Running   0          93s
kube-system   etcd-luboitvbox                      1/1     Running   0          41s
kube-system   kube-apiserver-luboitvbox            1/1     Running   0          35s
kube-system   kube-controller-manager-luboitvbox   1/1     Running   0          45s
kube-system   kube-proxy-np5s4                     1/1     Running   0          93s
kube-system   kube-scheduler-luboitvbox            1/1     Running   0          58s

tudo é 1.12.1, plano de controle, kubeadm, kubelet.
forneça mais detalhes sobre sua configuração.

/ prioridade em espera de mais evidências

@bravinash você pode mostrar o log do pod crashlooping: kubectl logs -n kube-system <coredns pod name> .
Você pode ver pods core-dns desta forma: kubectl get pods -n kube-system |grep coredns

Reproduzido:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

$ dpkg -l |grep kube
ii  kubeadm                               1.12.1-00                         amd64        Kubernetes Cluster Bootstrapping Tool
ii  kubectl                               1.12.1-00                         amd64        Kubernetes Command Line Tool
ii  kubelet                               1.12.1-00                         amd64        Kubernetes Node Agent
ii  kubernetes-cni                        0.6.0-00                          amd64        Kubernetes CNI

$ uname -a
Linux ed-ipv6-1 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# kubeadm init --pod-network-cidr=192.168.0.0/16
...
You can now join any number of machines by running the following on each node
as root:
...

$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

$ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
clusterrole.rbac.authorization.k8s.io/calico-node created
$ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
configmap/calico-config created
service/calico-typha created
deployment.apps/calico-typha created
daemonset.extensions/calico-node created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
serviceaccount/calico-node created

$ kubectl get pods -n kube-system
NAME                                READY   STATUS             RESTARTS   AGE
calico-node-q6k75                   2/2     Running            0          2m20s
coredns-576cbf47c7-gk59b            0/1     CrashLoopBackOff   3          27m
coredns-576cbf47c7-vz5kc            0/1     CrashLoopBackOff   3          27m
etcd-ed-ipv6-1                      1/1     Running            0          26m
kube-apiserver-ed-ipv6-1            1/1     Running            0          26m
kube-controller-manager-ed-ipv6-1   1/1     Running            0          26m
kube-proxy-8dw78                    1/1     Running            0          27m
kube-scheduler-ed-ipv6-1            1/1     Running            0          26m

$ kubectl logs -n kube-system coredns-576cbf47c7-gk59b
.:53
2018/10/09 10:41:59 [INFO] CoreDNS-1.2.2
2018/10/09 10:41:59 [INFO] linux/amd64, go1.11, eb51e8b
CoreDNS-1.2.2
linux/amd64, go1.11, eb51e8b
2018/10/09 10:41:59 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/10/09 10:42:05 [FATAL] plugin/loop: Seen "HINFO IN 
XXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXX." more than twice, loop detected 

parece que foi causado por systemd resolvido:

# grep nameserver /etc/resolv.conf 
nameserver 127.0.0.53

@bravinash , confirme se o problema é o mesmo em sua configuração.

Se for o mesmo, você pode tentar apontar o kubelet para o resolv.conf original desta maneira:

$ echo -e '[Service]\nEnvironment="KUBELET_EXTRA_ARGS=--resolv-conf=/run/systemd/resolve/resolv.conf"\n' | sudo tee /etc/systemd/system/kubelet.service.d/99-local.conf
$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet

e remover pods coredns:

$ kubectl get pods -n kube-system -oname |grep coredns |xargs kubectl delete -n kube-system

O Kubelet irá iniciá-los novamente com a nova configuração.

Pelo menos isso corrigiu o problema na minha configuração:

$ kubectl get pods -n kube-system
NAME                                READY   STATUS    RESTARTS   AGE
calico-node-cpsqz                   2/2     Running   0          5m20s
coredns-576cbf47c7-2prpv            1/1     Running   0          18s
coredns-576cbf47c7-xslbx            1/1     Running   0          18s
etcd-ed-ipv6-1                      1/1     Running   0          17m
kube-apiserver-ed-ipv6-1            1/1     Running   0          17m
kube-controller-manager-ed-ipv6-1   1/1     Running   0          17m
kube-proxy-8dkqt                    1/1     Running   0          17m
kube-scheduler-ed-ipv6-1            1/1     Running   0          17m

oi @ bart0sh
--resolv-conf=/run/systemd/resolve/resolv.conf preenchido corretamente em kubeadm init em /var/lib/kubelet/kubeadm-flags.env ?

https://kubernetes.io/docs/setup/independent/kubelet-integration/#the -kubelet-drop-in-file-for-systemd

/ remove-priority awaiting-more-evidencia

@ neolit123 é:

$ cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=cgroupfs --network-plugin=cni --resolv-conf=/run/systemd/resolve/resolv.conf

Obrigado por apontar isso para mim. Pode ser que o problema seja diferente ou o resolv.conf original também o aciona.

estranho, ele funciona bem na minha VM - é um Ubuntu 17.10 e também tem resolução de systemd.

No meu sistema, o resolv.conf original também gerou o mesmo problema. Ele começou a funcionar depois de copiá-lo para outro arquivo, removendo uma das 3 linhas de servidor de nomes dele e alterando a opção --resolv-conf em /var/lib/kubelet/kubeadm-flags.env

De qualquer forma, precisamos da confirmação de @bravinash de que o problema é o mesmo.
Não parece um problema do Kubeadm para mim.

/var/lib/kubelet/kubeadm-flags.env é reescrito cada vez que kubeadm init é executado, aliás.
esse foi o meu ponto de vista anterior.

/ tipo bug
rede / sig
/ ecossistema de área

Isso é muito estranho, eu era capaz de reproduzir esse problema de forma consistente até agora. Reimplantei meu Ubutnu 18.04 com 1.12.1 (kubelet kubeadm kubectl)
Agora isso está funcionando ..

root @ k8s-1121 : ~ # cat /etc/resolv.conf

Este arquivo é gerenciado por man: systemd-resolution (8). Não edite.

#

Este é um arquivo resolv.conf dinâmico para conectar clientes locais ao

Resolvedor de stub DNS interno resolvido pelo systemd. Este arquivo lista todos

domínios de pesquisa configurados.

#

Execute "systemd-resolve --status" para ver detalhes sobre os servidores DNS de uplink

Atualmente em uso.

#

Os programas de terceiros não devem acessar este arquivo diretamente, mas apenas por meio do

link simbólico em /etc/resolv.conf. Para gerenciar man: resolv.conf (5) de uma maneira diferente,

substitua este link simbólico por um arquivo estático ou um link simbólico diferente.

#

Veja man: systemd-resolution.service (8) para detalhes sobre os modos suportados de

operação para /etc/resolv.conf.

nameserver 127.0.0.53
pesquisar exu.ericsson.se

root @ k8s-1121 : ~ # cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS = - cgroup-driver = systemd --network-plugin = cni --resolv-conf = / run / systemd / resolve / resolv.conf

root @ k8s-1121 : ~ # kubectl get pods --all-namespaces
NAMESPACE NOME PRONTO STATUS RESTARTS IDADE
kube-system calico-etcd-r5wrw 1/1 Executando 0 6m52s
kube-system calico-kube-controllers-f4dcbf48b-7lvvn 1/1 Executando 0 7m7s
kube-system calico-node-qw9kx 2/2 Executando 2 7m7s
kube-system coredns-576cbf47c7-wdxv2 1/1 Executando 0 7m52s
kube-system coredns-576cbf47c7-wjf2m 1/1 Executando 0 7m52s
kube-system etcd-k8s-1121 1/1 Executando 0 7m16s
kube-system kube-apiserver-k8s-1121 1/1 Executando 0 7m14s
kube-system kube-controller-manager-k8s-1121 1/1 Executando 0 7m8s
kube-system kube-proxy-g879x 1/1 Executando 0 7m52s
kube-system kube-scheduler-k8s-1121 1/1 Executando 0 7m

Vou tentar mais algumas coisas para reproduzir isso novamente ..

Cumprimentos,
Avinash

De: Ed Bartosh [email protected]
Enviado: terça-feira, 9 de outubro de 2018 6h56
Para: kubernetes / kubeadm [email protected]
Cc: Avinash Raghavendra [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [kubernetes / kubeadm] Erro CoreDNS Crashloop - 1.12.1 (# 1162)

No meu sistema, o resolv.conf original também gerou o mesmo problema. Ele começou a funcionar depois de copiá-lo para outro arquivo, removendo uma das 3 linhas de servidor de nomes dele e alterando a opção --resolv-conf em /var/lib/kubelet/kubeadm-flags.env

De qualquer forma, precisamos da confirmação de @bravinash https://github.com/bravinash de que o problema é o mesmo.
Não parece um problema do Kubeadm para mim.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/kubernetes/kubeadm/issues/1162#issuecomment-428163873 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/AdD2Qj7- CqRCRK8rWeHWoULUMGlim2IQks5ujI7igaJpZM4XMP-f .

Eu proponho encerrar este problema por 2 motivos:

• é mais coredns do que questão de Kubeadm
• não é mais reproduzível

@bravinash você pode reabrir este problema se você vê-lo novamente

Vou encerrar este problema por enquanto, pois ele não é mais reproduzível.

FWIW (atrasado para a conversa, comentando sobre um problema fechado), No CoreDNS, esse erro é esperado quando um loop é detectado ... e o comportamento é, conforme projetado, para sair quando isso acontecer. O K8s detecta isso como um "travamento".

2018/10/09 10:41:59 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/10/09 10:42:05 [FATAL] plugin/loop: Seen "HINFO IN XXX.XXX." more than twice, loop detected 

é mais coredns do que questão de Kubeadm

CoreDNS não pode resolver automaticamente um ambiente mal configurado. Então, o problema está em quem quer que seja responsável por configurar as coisas.

FWIW, eu recebo exatamente o mesmo problema ao tentar criar um mestre do kube com o init do kubeadm no ubuntu 18.04.
Se for, de fato, o dns do systemd atrapalhando, então isso ainda precisa de algum tipo de solução ...

@jwatte infelizmente não conseguimos reproduzir o problema. Se você puder nos mostrar os logs do pod core-dns, ficarei feliz em prosseguir com esse problema.

@jwatte , Supondo que você veja o erro "loop detectado" nos logs, o kubeadm deve detectar automaticamente o problema systemd-resolved e configurar o kubelet com o arquivo resolv.conf correto. Se não for, você pode tentar uma das soluções alternativas manuais listadas nos documentos do plug-in de loop CoreDNS.

@jwatte

O kubeadm deve detectar automaticamente o problema resolvido pelo systemd e configurar o kubelet com o arquivo resolv.conf correto

isso já está

Por favor, verifique se está feito em sua configuração. btw, qual versão do kubeadm você usa?

Estou usando a versão atual lançada de hoje para tudo.
kubeadm version: & version.Info {Major: "1", Minor: "12", GitVersion: "v1.12.1", GitCommit: "4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState: "clean", BuildDate: "2018-10T16: 43-05T16 08Z ", GoVersion:" go1.10.4 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

No entanto, a coisa especial que faço é editar os comandos de inicialização do kubelet para usar kubenet em vez de gcn, porque essa é nossa configuração de produto e eu gostaria de ficar por perto.
No entanto, não importa o quanto eu tenha mexido nas configurações e replicação do coredns, eu não conseguia fazer com que ele não ficasse em loop. Acabei limpando e configurando com gcn e flanela, e funcionou conforme o esperado.

Acabei limpando e configurando com gcn e flanela, e funcionou conforme o esperado.

Normalmente estou usando o Weave Net na minha configuração de desenvolvimento e funciona muito bem. Quando mudei para calico para reproduzir este bug, o pod core-dns começou a travar devido à detecção de loop. Remover um dos servidores de nomes do resolv.conf corrigiu o problema para mim.

Então, meu ponto é: até que possamos reproduzir isso e entender como consertar, não acho que possamos ir mais longe com isso. Ainda tenho a impressão de que não é um problema do kubeadm. No meu caso foi questão de infraestrutura.

Minha opinião é que está em algum lugar na seção "documentação" e "capacidade de diagnóstico", o que poderia ser resolvido pelo kubernetes. Quando recebo este erro: E daí? O que causa isso? Quais são os problemas comuns? O que posso fazer para obter mais informações sobre as causas desse problema? Pesquisar a mensagem de erro no Google e obter este thread como a referência principal mostra que essa necessidade ainda não foi resolvida pela oferta geral do kubernetes.

Separadamente: Por que dois servidores de nomes em resolv.conf causariam esse problema? Isso se parece com uma configuração comum e totalmente legítima que deve ser tolerada pelos componentes do kubernetes.

Por que dois servidores de nomes no resolv.conf causariam esse problema?

Havia 3 servidores de nomes no meu resolv.conf. Remover um servidor específico resolveu o problema. Remover qualquer outro não. Então, decidi que o loop foi de alguma forma criado por aquele servidor.

Minha opinião é que está em algum lugar na seção "documentação" e "capacidade de diagnóstico", o que poderia ser resolvido pelo kubernetes. Quando recebo este erro: E daí? O que causa isso? Quais são os problemas comuns?

Há isso ... uma seção recentemente adicionada sobre solução de problemas no plug-in de loop. A versão mais recente do CoreDNS aponta para isso na mensagem de erro.

Acabei de notar que nosso README.md -> webpage.html processo de conversão é problemático, portanto, parte da formatação está complicada na versão coredns.io O original está aqui ... https://github.com/coredns/coredns/blob/master/plugin/loop/README.md

também como referência (se ainda não foi postado)

a página de solução de problemas do kubeadm tem uma seção relacionada ao CrashLoopBackoff do CoreDNS causado pelo SELinux:
https://kubernetes.io/docs/setup/independent/trou troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state

kubectl -n kube-system describe pod

Eventos:
Digite Razão Idade da Mensagem
---- ------ ---- ---- -------
Agendador padrão normal agendado 114s atribuído com sucesso kube-system / coredns-5b4dd968b9-mqhvc para cap166
Pulled 49s normal (x4 sobre 114s) kubelet, cap166 Imagem do contêiner "k8s.gcr.io/ coredns: 1.2.2 " já presente na máquina
Normal Criado 49s (x4 sobre 114s) kubelet, cap166 Criado contêiner
49s normais iniciados (x4 sobre 114s) kubelet, contêiner iniciado cap166
Aviso BackOff 9s (x8 sobre 100s) kubelet, cap166 Back-off reiniciando contêiner com falha

Compartilhei a solução que funcionou para mim aqui: https://stackoverflow.com/a/53414041/1005102

@utkuozdemir

ps auxww | grep kubelet
você pode ver uma linha como:
/ usr / bin / kubelet ... --resolv-conf = / run / systemd / resolve / resolv.conf

alternativamente:
cat /var/lib/kubelet/kubeadm-flags.env
O kubeadm grava o sinalizador --resolv-conf nesse arquivo sempre que executa join e init.

O erro de loop CoreDNS acabou de acontecer comigo com o Ubuntu 18.04 / kubeadm quando especifiquei o IP do nó desta forma:
cat> / etc / default / kubelet < KUBELET_KUBEADM_ARGS = "- node-ip = 192.168.10.11"
EOF

Mover o comando --node-ip para /etc/systemd/system/kubelet.service.d/10-kubeadm.conf resolveu o problema do loop:
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --node-ip=192.168.10.11
(o conteúdo do arquivo / etc / default / kubelet agora é "KUBELET_EXTRA_ARGS =")

meu core-dns está em CrashLoopBackOff.
o log é:

E0401 16: 54: 47.487196 1 reflector.go: 134] github.com/coredns/coredns/plugin/kubernetes/controller.go:317: Falha ao listar * v1.Endpoints: Obter https://10.96.0.1 : 443 / api / v1 / endpoints? limit = 500 & resourceVersion = 0: disque tcp 10.96.0.1:443: i / o timeout
log: saindo devido a erro: log: não é possível criar log: open /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: nenhum arquivo ou diretório

Tenho ubuntu 18 e kubernetes v1.14 + flanela, todos os outros pods estão em execução

@pmehdinejad , Esse erro significa que sua API do kubernetes não está acessível.

@pmehdinejad , Esse erro significa que sua API do kubernetes não está acessível.

Acho que um é para antes de eu configurar a flanela, o erro mais recente é este:
log: saindo devido a erro: log: não é possível criar log: open /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: nenhum arquivo ou diretório

versão coredns?

versão coredns?

k8s.gcr.io/ coredns: 1.3.1

Tente 1.4.0 para ver se ele se comporta de maneira diferente. Pode estar relacionado ao problema glog / klog que corrigimos na versão 1.4.0.

Tente 1.4.0 para ver se ele se comporta de maneira diferente. Pode estar relacionado ao problema glog / klog que corrigimos na versão 1.4.0.

Parece estar corrigido com 1.4
Agradeço a ajuda

@pmehdinejad , Esse erro significa que sua API do kubernetes não está acessível.

Acho que um é para antes de eu configurar a flanela, o erro mais recente é este:
log: saindo devido a erro: log: não é possível criar log: open /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: nenhum arquivo ou diretório

Ainda recebendo este erro:
Obtenha https://10.96.0.1 : 443 / api / v1 / namespaces? Limit = 500 & resourceVersion = 0: disque tcp 10.96.0.1:443: i / o timeout

Estranho porque todos os outros pods estão sendo executados, incluindo kube-proxy, kube-apiserver e flanela

@pmehdinejad , o erro significa que o CoreDNS não pode acessar a API Kubernetes. Pode haver algo errado com flanela ou kube-proxy (o que torna as conexões possíveis).

@pmehdinejad , o erro significa que o CoreDNS não pode acessar a API Kubernetes. Pode haver algo errado com flanela ou kube-proxy (o que torna as conexões possíveis).

Sim, eu estava fazendo telnet do host, tentei implantar um pod e executá-lo do shell, mas a maioria das imagens são mínimas e sem coredns não consigo instalar nada no contêiner.

É estranho porque a flanela e o proxy estão funcionando e tudo o que posso ver em seus registros são estes:

Flanela:

I0402 14: 24: 26.014844 1 iptables.go: 155] Adicionando regra de iptables: -s 10.244.0.0/16 -d 10.244.0.0/16 -j RETURN
I0402 14: 24: 26.113264 1 iptables.go: 155] Adicionando regra de iptables: -s 10.244.0.0/16! -d 224.0.0.0/4 -j MASQUERADE - totalmente aleatório
I0402 14: 24: 26.115211 1 iptables.go: 155] Adicionando regra de iptables:! -s 10.244.0.0/16 -d 10.244.1.0/24 -j RETORNO
I0402 14: 24: 26.117448 1 iptables.go: 155] Adicionando regra de iptables:! -s 10.244.0.0/16 -d 10.244.0.0/16 -j MASQUERADE - aleatoriamente totalmente

kube-proxy:

E0402 15: 11: 19.584081 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Falha ao listar * v1.Endpoints: Não autorizado
E0402 15: 11: 20.585880 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Falha ao listar * v1.Serviço: não autorizado
E0402 15: 11: 20.586590 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Falha ao listar * v1.Endpoints: Não autorizado

Não sou especialista em kube-proxy, mas não acho que essas mensagens de erro sejam normais para kube-proxy.

Eu encontrei um problema semelhante. O crashloop de coredns e também causou crashloop do painel. Funciona depois de definir a rede para flanela e todos os nomes de host do PC em / etc / hosts.

Eu tenho 3 PCs e configurei todos os três PCs como mestre e nó. Um PC está atrás do meu gateway doméstico, outros dois atrás do firewall corporativo. Todos os três PCs estão conectados em uma VPN. Se a configuração de rede padrão foi usada pelo kubespray, o pod coredns funciona quando é implantado no PC da minha casa e, caso contrário, trava.

Tentei o seguinte:

• (FALHOU) resolv.conf: Alterei o arquivo /etc/systemd/system/kubelet.service.d/99-local.conf e /run/systemd/resolve/resolv.conf ou /etc/resolv.conf não vai funcionar
• (FALHOU) /var/lib/kubelet/kubeadm-flags.env, configuração para /etc/resolv.conf
• (FALHOU) /etc/systemd/resolved.conf, mudou o DNS e não funciona.
• (SUCESSO) usando flanela e colocando todos os nomes de host do PC em / etc / hosts

Então, é o problema da malha padrão da rede?