Kubernetes: O plugin de rede não está pronto: cni config uninitialized

Criado em 12 jul. 2017  ·  75Comentários  ·  Fonte: kubernetes/kubernetes

Olá, quero fazer uma nova instalação do Kubernetes via kubeadm, mas quando eu inicio a instalação, estou preso

[apiclient] Created API client, waiting for the control plane to become ready

Quando faço um journalctl -xe , vejo:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

E não sei por que recebo esse erro. Eu também tentei desabilitar o firewalld, mas sem efeito.

Meio Ambiente :

  • Versão do Kubernetes (use kubectl version ): v1.7.0
  • Provedor de nuvem ou configuração de hardware **:
  • SO (por exemplo, de / etc / os-release): CentOS 7
  • Kernel (por exemplo, uname -a ): 3.10.0-514.26.2.el7.x86_64
  • Ferramentas de instalação: Kubeadm
  • Outras:
    versão docker: Docker version 17.06.0-ce, build 02c1d87
    Minha versão RPM:

kubeadm-1.7.0, kubectl-1.7.0, kubelet-1.7.0, kubernetes-cni-0.5.1

Obrigado pela ajuda

arekubeadm kinbug sinetwork

Comentários muito úteis

flanneld precisa de uma correção para k8s 1.12.
Use este PR (até que seja aprovado):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
é um problema conhecido: https://github.com/coreos/flannel/issues/1044

Todos 75 comentários

@PLoic Não há rótulos de assinatura neste problema. Adicione um rótulo de assinatura por:
(1) mencionando um sig: @kubernetes/sig-<team-name>-misc
por exemplo, @kubernetes/sig-api-machinery-* para API Machinery
(2) especificando o rótulo manualmente: /sig <label>
por exemplo, /sig scalability para sig / escalabilidade

_Nota: o método (1) acionará uma notificação para a equipe. Você pode encontrar a lista de equipes aqui e a lista de marcadores aqui _

/ area [kubeadm]

@PLoic você obtém este erro porque nenhuma rede CNI foi definida em /etc/cni/net.d e você aparentemente está usando o plugin de rede CNI. Algo precisa gravar um arquivo de configuração nesse diretório para informar ao driver CNI como configurar a rede. Não tenho certeza do que / como o kubeadm faz isso, então vou deixar isso para @jbeda ou outro pessoal do kubeadm.

xref: # 43567

@dcbw Oi dcbw, Ambiente igual ao @PLoic , mas recebo este mesmo erro

Parece que está funcionando removendo $KUBELET_NETWORK_ARGS em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

remover $ KUBELET_NETWORK_ARGS não funciona comigo.

@PLoic também não funciona comigo

@PLoic na etapa 3, qual rede de pod você instalou? Existem várias opções, e a solução de problemas depende do caso específico.

@PLoic também, os logs do kubelet seriam ótimos

tente aplicar este plugin: kubectl apply --filename https://git.io/weave-kube-1.6
funciona para mim.

@PLoic @dcbw Eu instalo o plugin de flanela de k8s (1.7) e ainda recebo este mesmo erro, você pode fornecer uma solução?

14 de julho 17:57:20 node2 kubelet: W0714 17: 57: 20.540849 17504 cni.go: 189] Não é possível atualizar a configuração cni: nenhuma rede encontrada em /etc/cni/net.d
14 de julho 17:57:20 node2 kubelet: E0714 17: 57: 20.541001 17504 kubelet.go: 2136] Rede de tempo de execução do contêiner não está pronta: NetworkReady = false motivo: NetworkPluginNotReady mensagem: docker : plugin de rede não está pronto: cni config uninitialized
14 de julho 17:57:23 node2 kubelet: I0714 17: 57: 23.032330 17504 kubelet.go: 1820] ignorando a sincronização do pod - [Falha ao iniciar ContainerManager a versão do systemd não suporta a capacidade de iniciar uma fatia como unidade temporária]

Desculpe pela demora, eu estava usando o Weave, vou tentar atualizar o kubernetes para 1.7.1 e com a nova versão do weave

Atualizei todos os meus componentes e parece funcionar! :)

Posso fechar este problema @PLoic ?

@cmluciano Sim, acho que não há problema em encerrar este problema

Remover o $ KUBELET_NETWORK_ARGS em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf funciona para mim.
Obrigado @PLoic

Observe que KUBELET_NETWORK_ARGS é o que diz ao kubelet qual tipo de plugin de rede esperar. Se você removê-lo, o kubelet não espera nenhum plug-in e, portanto, você obtém tudo o que o tempo de execução do contêiner subjacente oferece: normalmente a rede "ponte" do Docker.

Isso é bom em alguns casos, especialmente se você tiver apenas uma máquina. Não é útil se você realmente deseja usar o CNI.

Estou vendo exatamente o mesmo erro com kubeadm, onde fica marcado para sempre em:

[apiclient] Created API client, waiting for the control plane to become ready

Em "journalctl -r -u kubelet", vejo estas linhas continuamente:
Aug 31 16:34:41 k8smaster1 kubelet[8876]: E0831 16:34:41.499982 8876 kubelet.go:2136] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Aug 31 16:34:41 k8smaster1 kubelet[8876]: W0831 16:34:41.499746 8876 cni.go:189] Unable to update cni config: No networks found in /etc/cni/net.d

Os detalhes da versão são:
`kubeadm version: & version.Info {Major:" 1 ", Minor:" 7 ", GitVersion:" v1.7.4 ", GitCommit:" 793658f2d7ca7f064d2bdf606519f9fe1229c381 ", GitTreeState:" clean ", BuildDate:" 2017-08-17T08 : 51Z ", GoVersion:" go1.8.3 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

Versão do Kubectl: Versão do cliente: version.Info {Principal: "1", Secundário: "7", GitVersion: "v1.7.4", GitCommit: "793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState: "clean", BuildDate: "2017-08-17T08 : 48: 23Z ", GoVersion:" go1.8.3 ", Compilador:" gc ", Plataforma:" linux / amd64 "}`

Os detalhes do sistema operacional são:
Operating System: Red Hat Enterprise Linux Server 7.3 (Maipo) Kernel: Linux 3.10.0-514.el7.x86_64 Architecture: x86-64
Qualquer ajuda é muito apreciada!

@ ashish-billore qual provedor CNI você instalou?

estou recebendo Unable to update cni config: No networks found in /etc/cni/net.d com uma dica recente do github do branch master - "v1.9.0-alpha.0.690+9aef242a4c1e42-dirty"

no ubuntu 17.04

se eu remover esta linha de 10-kubelet.conf :
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/ --cni-bin-dir=/opt/cni/bin""

o kubelet é iniciado, então eu instalo o weave-net como o plug-in pod-network, mas os pods do sistema kube nunca iniciam (eles permanecem programados?)

kube-system   etcd-luboitvbox                      0/1       Pending   0          31m
kube-system   kube-apiserver-luboitvbox            0/1       Pending   0          31m
kube-system   kube-controller-manager-luboitvbox   0/1       Pending   0          31m
kube-system   kube-dns-1848271846-7mw9x            0/3       Pending   0          32m
kube-system   kube-proxy-k89jp                     0/1       Pending   0          32m
kube-system   kube-scheduler-luboitvbox            0/1       Pending   0          31m
kube-system   weave-net-v8888                      0/2       Pending   0          30m

o mesmo acontece com a flanela.

Olá,

Para obter informações, tive este problema: o Kubernetes apresenta o RBAC desde a v1.6, precisamos criar uma conta de serviço correspondente, regras de RBAC e daemonset de flanela para que o kubelet possa se comunicar com o servidor API corretamente.

Você tem que executar:

$ kubectl create -f https://raw.githubusercontent.com/coreos/flannel/v0.9.0/Documentation/kube-flannel.yml

Espero que ajude.

Oi pessoal, por que esse problema foi fechado? Não parece que houve uma solução?

Eu vejo isso quando tento instalar um cluster do k8 com o plugin weave CNI.

@vinayvenkat o problema foi

Como o Kubernetes, e particularmente a rede, é muito complexo e diversificado, você não deve presumir que um problema que parece semelhante é realmente o mesmo. Abra um novo problema e forneça detalhes completos de sua situação específica.

Se o seu problema for com o Weave Net, você pode obter uma resposta mais específica em https://github.com/weaveworks/issues/new ou no Slack da comunidade do Weave.

Eu também encontrei o mesmo problema. Mas não é um erro fatal na instalação do k8s.
O problema pode ser que você use kubelet cgroups do systemd que difere dos cgroups do docker, ajuste o kubelet e o docker, execute o kubeadm novamente, ele pode funcionar bem.
espero ajudá-lo.

SO (por exemplo, de / etc / os-release): CentOS 7

Se você vir o diretório /etc/cni/net.d no nó vazio, apesar do pod de provedor de rede de pods estar em execução nele, tente setenforce 0 e exclua o pod de provedor de rede de pods. O k8s irá reiniciá-lo e, com sorte, agora ele será capaz de copiar sua configuração.

não se esqueça de reiniciar o kubelet ...
removendo o $ KUBELET_NETWORK_ARGS em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl enable kubelet && systemctl start kubelet
em seguida, junte-se novamente ao nó
dessa forma funciona bem para mim ~

Oi,

Se você comentar $ KUBELET_NETWORK_ARGS em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e reiniciar o serviço / servidor ou se kubeadm redefinir e entrar novamente em / kubeadm init para recriar o cluster
e junte os nós novamente,

os pods estarão em execução, mas se você descrever o pod kube-dns, verá

Aviso Insalubre 1m (x4 sobre 2m) kubelet, falha na sondagem de prontidão mestre: Obtenha http://172.17.0.2 : 8081 / readiness: dial tcp 172.17.0.2:8081: getsockopt: conexão recusada

a saída completa conforme abaixo.

Eventos:
Digite Razão Idade da Mensagem
---- ------ ---- ---- -------
Agendador padrão 10m agendado normal Atribuído com sucesso kube-dns-6f4fd4bdf-qxmzn ao mestre
Normal SuccessMountVolume 10m kubelet, master MountVolume.SetUp bem-sucedido para o volume "kube-dns-token-47fpd"
Normal SuccessMountVolume 10m kubelet, master MountVolume.SetUp bem-sucedido para o volume "kube-dns-config"
Extração normal de 10 m de kubelet, imagem de extração mestre "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7"
Kubelet extraído normal de 10 m, imagem principal extraída com sucesso "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7"
Kubelet de 10 m criado normal, contêiner criado mestre
Kubelet de 10 m inicializado normal, contêiner inicial inicializado
Extração normal de 10 m de kubelet, imagem de extração mestre "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7"
Kubelet extraído normal de 10 m, imagem principal extraída com sucesso "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7"
Kubelet de 10 m criado normal, contêiner criado mestre
Kubelet de 10 m inicializado normal, contêiner inicial inicializado
Extração normal de 10 m de kubelet, imagem de extração mestre "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7"
Kubelet extraído normal de 10 m, imagem principal extraída com sucesso "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7"
Kubelet de 10 m criado normal, contêiner criado mestre
Kubelet de 10 m inicializado normal, contêiner inicial inicializado
Normal SuccessMountVolume 2m kubelet, master MountVolume.SetUp bem-sucedido para o volume "kube-dns-token-47fpd"
Normal SuccessMountVolume 2m kubelet, master MountVolume.SetUp bem-sucedido para o volume "kube-dns-config"
SandboxChanged normal 2m kubelet, o sandbox do Pod mestre alterado, ele será eliminado e recriado.
Kubelet extraído normal de 2 m, imagem de contêiner mestre "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7" já presente na máquina
Kubelet de 2 m criado normal, contêiner criado mestre
Kubelet de 2 m inicializado normal, contêiner inicial inicializado
Kubelet de 2 m criado normal, contêiner criado mestre
Kubelet extraído normal de 2 m, imagem de contêiner mestre "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7" já presente na máquina
Kubelet de 2 m inicializado normal, contêiner inicial inicializado
Kubelet extraído normal de 2 m, imagem de contêiner mestre "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7" já presente na máquina
Kubelet de 2 m criado normal, contêiner criado mestre
Kubelet de 2 m inicializado normal, contêiner inicial inicializado
Aviso Insalubre 1m (x4 sobre 2m) kubelet, falha na sondagem de prontidão mestre: Obtenha http://172.17.0.2 : 8081 / readiness: dial tcp 172.17.0.2:8081: getsockopt: conexão recusada

docker @ master : ~ $ kubectl get pods --namespace = kube-system
NOME PRONTO STATUS REINICIA IDADE
etcd-master 1/1 Running 1 14m
kube-apiserver-master 1/1 Executando 1 14m
kube-controller-manager-master 1/1 Running 1 14m
kube-dns-6f4fd4bdf-qxmzn 3/3 Executando 3 15m
kube-proxy-d54fk 1/1 Executando 1 15m
kube-scheduler-master 1/1 Running 1 14m

Ninguém mencionou o SELinux ainda. Eu recebi este erro ao executar kubeadm join em uma máquina Centos 7 com SELinux no modo Enforcing. Definir setenforce 0 e reexecutar o kubeadm corrigiu meu problema.

Obrigado setenforce 0 funcionou para mim.

1. $ KUBELET_NETWORK_ARGS tirar, não resolver o problema
2.setenforce 0
3.systemctl stop firewalld
4.docker cgroups drivers: systemd与 Environment = "KUBELET_CGROUP_ARGS = - cgroup-driver = systemd"
conformidade
mas, você sabe que o problema ainda existe.


20 de maio 20:10:45 k8s kubelet: I0520 20: 10: 45.244383 17638 kubelet.go: 1794] ignorando a sincronização do pod - [o tempo de execução do contêiner está inativo]
20 de maio 20:10:45 k8s kubelet: E0520 20: 10: 45.920981 17638 reflector.go: 205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:460: Falha ao listar * v1.Nó: Obter https: //192.168.18.90 : 6443 / api / v1 / nodes? FieldSelector = metadata.name% 3Dk8s.master.com & limit = 500 & resourceVersion = 0: disque tcp 192.168.18.90:6443: getsockopt: conexão recusada
20 de maio 20:10:45 k8s kubelet: E0520 20: 10: 45.924021 17638 reflector.go: 205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:451: Falha ao listar * v1.Serviço: Obter https: //192.168.18.90 : 6443 / api / v1 / services? Limit = 500 & resourceVersion = 0: disque tcp 192.168.18.90:6443: getsockopt: conexão recusada
20 de maio 20:10:45 k8s kubelet: E0520 20: 10: 45.935594 17638 reflector.go: 205] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Falha ao listar * v1.Pod: Get https://192.168.18.90 : 6443 / api / v1 / pods? fieldSelector = spec.nodeName% 3Dk8s.master.com & limit = 500 & resourceVersion = 0: disque tcp 192.168.18.90:6443: getsockopt: conexão recusada

23 de maio 10:19:45 arch kubelet [13585]: E0523 10: 19: 45.909458 13585 kubelet.go: 2095] Rede de tempo de execução do contêiner não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : plugin de rede não está pronto: configuração cni não inicializado
23 de maio 10:19:46 arch kubelet [13585]: E0523 10: 19: 46.002646 13585 helpers.go: 468] PercpuUsage tinha 0 cpus, mas o número real é 8; ignorando CPUs extras

`sudo kubectl get node

NOME STATUS ROLES IDADE VERSÃO
127.0.0.1 NotReady23h v1.8.13`

Acabei de encontrar isso, e parece ser devido ao arquivo estar vazio, aqui está a saída do contêiner install-cni :

$ k logs canal-25rct install-cni -n kube-system
ls: /calico-secrets: No such file or directory
Wrote Calico CNI binaries to /host/opt/cni/bin
CNI plugin version: v3.1.2
/host/secondary-bin-dir is non-writeable, skipping
CNI config: {
Created CNI config 10-calico.conflist
Done configuring CNI.  Sleep=true

E em /etc/cni/net.d/10-calico.conflist :

$ cat /etc/cni/net.d/10-calico.conflist 
{

Quando tento fazer o shell no contêiner (talvez seja um initContainer ?), Obtenho o seguinte:

$ k exec -it canal-25rct -c install-cni -n kube-system -- /bin/bash
Error: Malformed environment entry: "  "name": "k8s-pod-network",
": Success
command terminated with exit code 45

É estranho, porque a versão do script não mudou, e a única coisa que mudei recentemente foi mudar para rkt para rodar contêineres. Além disso, isso está no Container Linux (CoreOS) se isso ajudar em tudo.

Olá pessoal do K8s!

Eu tive muitas vezes o mesmo problema. Por exemplo - algo deu errado durante a inicialização do meu K8s e tive que usar kubeadm reset e inicializar K8s novamente. Depois de executar o comando de inicialização, obtive no log do kubelet este erro:

Jun 01 10:13:40 vncub0626 kubelet[18861]: I0601 10:13:40.665823   18861 kubelet.go:2102] Container runtime status: Runtime Conditions: RuntimeReady=true reason: message:, NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 01 10:13:40 vncub0626 kubelet[18861]: E0601 10:13:40.665874   18861 kubelet.go:2105] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

... Fiquei bravo com esta mensagem de erro - nada ajudou. Então eu disse a mim mesmo - primeiro a inicialização foi executada, mas a reinicialização não. Então não foi causado por esta linha na configuração do Kubelet: KUBELET_NETWORK_ARGS e não concordo em comentar. Então li o log do kubelet várias vezes ... e finalmente notei no log a próxima mensagem de erro:

Jun 01 10:13:29 vncub0626 kubelet[18861]: E0601 10:13:29.376339   18861 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:465: Failed to list *v1.Service: Get https://10.96.22.11:6443/api/v1/services?limit=500&resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Este erro foi causado por um arquivo ~/.kube/config inválido no diretório inicial após a inicialização anterior. Depois de removê-lo, executo a inicialização novamente ... e voilá ... a inicialização foi concluída com sucesso. :]

... espero que ajude outra pessoa porque esse erro é um pesadelo e não é quase possível determinar sua causa.

@waldauf você está correto !!! impressionante!!!

executar comando seguir funciona bem

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml

versão do kubeadm v1.10.3

Remover o $ KUBELET_NETWORK_ARGS em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf funciona para mim.

Repetindo para visibilidade:

Observe que KUBELET_NETWORK_ARGS é o que diz ao kubelet qual tipo de plugin de rede esperar. Se você removê-lo, o kubelet não espera nenhum plug-in e, portanto, você obtém tudo o que o tempo de execução do contêiner subjacente oferece: normalmente a rede "ponte" do Docker.

Isso é bom em alguns casos, especialmente se você tiver apenas uma máquina. Não é útil se você realmente deseja usar o CNI.

@waldauf thx, funciona

Isso me ocorreu quando meu plugin de flanela não foi instalado corretamente.

Eu estava seguindo este guia hoje (https://www.techrepublic.com/article/how-to-install-a-kubernetes-cluster-on-centos-7/) e perdi a configuração do cgroupfs em "/ etc / systemd /system/kubelet.service.d/10-kubeadm.conf ". Depois de consertar, funcionou como um encanto

https://github.com/kubernetes/kubernetes/issues/48798#issuecomment -395965665

@ChinaSilence Você pode explicar por que temos que usar flanela? Não podemos fazer isso sem flanela?

flannel 0.10.0 e kubernetes 1.12.0 não podem funcionar juntos de alguma forma. há algo errado com o kubernetes 1.12.0, então eu fiz downgrade do kubernetes para o 1.11.3 e tudo está funcionando bem.

Espero que o kubernetes corrija esse problema em breve.

@ bilalx20 posso confirmar que - a flanela também está quebrada para mim no 1.12.
o que você pode fazer é tentar weave ou callico, eles funcionam.

Tenho esse problema no meu Ubuntu 16.04 com k8s 1.12.

Faça o downgrade para 1.11.0 e tudo estará instalado e funcionando.

Eu tenho esse problema no CentOS 7.5 com k8s 1.12

Remover a configuração do plugin cni de /var/lib/kubelet/kubeadm-flags.env funciona bem

flanneld precisa de uma correção para k8s 1.12.
Use este PR (até que seja aprovado):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
é um problema conhecido: https://github.com/coreos/flannel/issues/1044

Eu tive o problema que @ReSearchITEng descreve com 1.12.1. Sua solução funcionou para mim.
EDIT: risque isso, um dos nós ainda mostra o mesmo problema depois de kubeadm join
EDIT2: problema não relacionado, parece que nvidia-container-runtime estava faltando neste nó de GPU. Diagnosticado usando journalctl -xeu kubelet no nó defeituoso

TL; DR: a solução funciona

Confirmando que a solução de @ReSearchITEng funciona, não tenho meu nó mestre no estado de execução e a flanela está

Apenas no caso de alguém estar pesquisando isso. Eu tive o mesmo problema, no meu caso, o processo de inicialização de nuvem definiu a opção NM_CONTROLLED em / etc / sysconfig / network-scripts / ifcfg- {interface-name} para no.
Esta opção deve ser definida como yes para que o NetworkManager crie o arquivo resolv.conf necessário para os pods sdn.

Não consegui realmente aplicar os manifestos do weave, portanto, nenhum plug-in de rede foi inicializado.
Nota para mim mesmo: Leia todo o manual de instalação do Weave antes de procurar respostas em outro lugar: +1:

flanneld precisa de uma correção para k8s 1.12.
Use este PR (até que seja aprovado):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
é um problema conhecido: coreos / flannel # 1044

Adicional:
Eu acho que esse problema é causado pelo primeiro init coredns do kuberadm, mas não pelo init flannel, então ele joga "o plugin de rede não está pronto: cni config uninitialized".
Solução:

  1. Instale flanela por kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
  2. Reinicie o pod coredns
    kubectl delete coredns-xx-xx
  3. Em seguida, execute kubectl get pods para ver se funciona.

se vir este erro, "cni0" já tem um endereço IP diferente de 10.244.1.1/24 ".
Siga isso:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

se vir este erro "Back-off reiniciando contêiner com falha", e você pode obter o log

root<strong i="28">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

Em seguida, você pode ver o arquivo "/etc/resolv.conf" no nó com falha, se o servidor de nomes for localhost, haverá um loopback. Altere para:

#nameserver 127.0.1.1
nameserver 8.8.8.8

você adiciona --network-plugin = cni em seu kueblet start conf
no meu sistema:
1.vim /etc/systemd/system/kubelet.service
2. excluir --network-plugin = cni
3. reinicie o kubelet (systemctl daemon-reload; systemctl restart kubelet)

por favor execute 3 passos, em seu sistema, talvez sua instalação diferente da minha, por favor, faça assim

@mdzddl você excluiu --network-plugin = cni porque kubelet reclama sobre cni? Não tão inteligente. Excluir o plugin de rede padrão não é recomendado de forma alguma.

flanneld precisa de uma correção para k8s 1.12.
Use este PR (até que seja aprovado):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
é um problema conhecido: coreos / flannel # 1044

Funciona para mim !

@mdzddl você excluiu --network-plugin = cni porque kubelet reclama sobre cni? Não tão inteligente. Excluir o plugin de rede padrão não é recomendado de forma alguma.

Então qual é a solução

flanneld precisa de uma correção para k8s 1.12.
Use este PR (até que seja aprovado):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
é um problema conhecido: coreos / flannel # 1044

Adicional:
Eu acho que esse problema é causado pelo primeiro init coredns do kuberadm, mas não pelo init flannel, então ele joga "o plugin de rede não está pronto: cni config uninitialized".
Solução:

  1. Instale flanela por kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
  2. Reinicie o pod coredns
    kubectl delete coredns-xx-xx
  3. Em seguida, execute kubectl get pods para ver se funciona.

se vir este erro, "cni0" já tem um endereço IP diferente de 10.244.1.1/24 ".
Siga isso:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

se vir este erro "Back-off reiniciando contêiner com falha", e você pode obter o log

root<strong i="29">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

Em seguida, você pode ver o arquivo "/etc/resolv.conf" no nó com falha, se o servidor de nomes for localhost, haverá um loopback. Altere para:

#nameserver 127.0.1.1
nameserver 8.8.8.8

kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel criado
clusterrolebinding.rbac.authorization.k8s.io/flannel criado
conta de serviço / flanela criada
configmap / kube-flannel-cfg criado
incapaz de reconhecer " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": nenhuma correspondência para o tipo "DaemonSet" na versão "extensions / v1beta1"
incapaz de reconhecer " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": nenhuma correspondência para o tipo "DaemonSet" na versão "extensions / v1beta1"
incapaz de reconhecer " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": nenhuma correspondência para o tipo "DaemonSet" na versão "extensions / v1beta1"
incapaz de reconhecer " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": nenhuma correspondência para o tipo "DaemonSet" na versão "extensions / v1beta1"
incapaz de reconhecer " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": nenhuma correspondência para o tipo "DaemonSet" na versão "extensions / v1beta1"

Lança o erro acima

flannel não atualizou seu manifesto para estar em conformidade com as alterações mais recentes no k8s 1.16.
experimente um plugin CNI diferente, como Calico ou WeaveNet.

... ou remendar os manifestos de flanela para usar apps/v1 vez de extensions/v1beta1

Eu tenho esse problema no Ubuntu 16.04 com k8s 1.16 (eu executo o ubuntu no vagrant)

Remover a configuração do plugin cni de /var/lib/kubelet/kubeadm-flags.env funciona bem

flannel não atualizou seu manifesto para estar em conformidade com as alterações mais recentes no k8s 1.16.
experimente um plugin CNI diferente, como Calico ou WeaveNet.
...
... ou remendar os manifestos de flanela para usar apps / v1 em vez de extensions / v1beta1

Isso foi corrigido há algum tempo, mas os links na documentação do Kubernetes ainda apontam para uma versão mais antiga que não funciona (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster- kubeadm / has https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml). Usar "master" em vez disso funciona e também corrige outro problema (versão ausente na configuração CNI).

Isto é o que eu vi: Este erro ocorre quando você não tem a flanela em execução ainda, mas você inicia o kublet apenas com manifestos de apiserver, planejador e gerenciador de controlador - ENQUANTO VOCÊ TEM ESTA LINHA em 10-kubeadm.conf - "Environment =" KUBELET_NETWORK_ARGS = - network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --node-ip = 192.168.8.11 "

Comente isso e inicie o kubelet.
Em seguida, os pods do sistema Kube principal aparecem.
Em seguida, instale o kube-proxy
Em seguida, instale a flanela
* Em seguida, descomente a linha acima e reinicie o kubelet *
Instale core-dns / kube-dns

Oi,
Estou tentando instalar a versão 1.16.0, estou usando o plug-in kuberouter e estou recebendo os mesmos erros

A rede de tempo de execução do contêiner não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : o plug-in de rede não está pronto: cni config não inicializado

Oi,
Estou tentando instalar a versão 1.16.0, estou usando o plug-in kuberouter e estou recebendo os mesmos erros

A rede de tempo de execução do contêiner não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : o plug-in de rede não está pronto: cni config não inicializado

Se você puder fornecer mais informações sobre o ambiente de execução, será útil. Por exemplo, o sistema operacional e o que você fez antes de ocorrer o erro.

esta é uma nova instalação da versão 1.16.0 no Amazon.
estou usando este AMI - k8s-1.16-debian-stretch-amd64-hvm-ebs-2020-01-17
uname -a
Linux ip-172-28-125-218 4.9.0-11-amd64 # 1 SMP Debian 4.9.189-3 + deb9u2 (2019-11-11) x86_64 GNU / Linux

se eu instalar o 1.15.0, não haverá problemas.

isso é o que vejo no syslog dos nós mestres.

12 de março 05:26:22 ip-172-28-125-218 kubeletÄ3656Å: E0312 05: 26: 22.761009 3656 kubelet.go: 2187Å Rede de tempo de execução do contêiner não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : plug-in de rede não pronto: cni config uninitialized
12 de março 05:26:25 ip-172-28-125-218 dockerÄ3570Å: I0312 05: 26: 25.713681 3619 dns.go: 47Å DNSView inalterado: 5
12 de março 05:26:25 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 25.883857 3656 cni.go: 202Å Erro ao validar CNI config & äkubernetes false Ä0xc0009d8260Å Ä123 34 99 110 105 86 101 114 115 111 110 34 58 34 34 44 34 110 97 109 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 112 108 117 103 105 110 115 34 58 91 123 34 98 114 105 100 103 101 34 58 34 107 117 98 101 45 98 114 105 100 103 101 34 44 34 105 112 97 109 34 58 123 34 115 117 98 110 101 116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34 34 116 121 112 101 34 58 34 104 111 115 116 45 108 111 99 97 108 34 125 44 34 105 115 68 101 102 97 117 108 116 71 97 116 101 119 97 121 34 58 116 114 117 101 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 116 121 112 101 34 58 34 98 114 105 100 103 101 34 125 93 125Åå: o Äplugin bridge não suporta a versão de configuração "" Å
12 de março 05:26:25 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 25.883925 3656 cni.go: 237Å Não é possível atualizar a configuração cni: nenhuma rede válida encontrada em /etc/cni/net.d/
12 de março 05:26:27 ip-172-28-125-218 kubeletÄ3656Å: E0312 05: 26: 27.762309 3656 kubelet.go: 2187Å A rede de tempo de execução do contêiner não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : o plugin de rede não está pronto: cni config uninitialized
12 de março 05:26:30 ip-172-28-125-218 dockerÄ3570Å: I0312 05: 26: 30.713906 3619 dns.go: 47Å DNSView inalterado: 5
12 de março 05:26:30 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 30.886362 3656 cni.go: 202Å Erro ao validar CNI config & äkubernetes false Ä0xc0008fc000Å Ä123 34 99 110 105 86 101 114 115 111 110 34 58 34 34 44 34 110 97 109 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 112 108 117 103 105 110 115 34 58 91 123 34 98 114 105 100 103 101 34 58 34 107 117 98 101 45 98 114 105 100 103 101 34 44 34 105 112 97 109 34 58 123 34 115 117 98 110 101 116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34 34 116 121 112 101 34 58 34 104 111 115 116 45 108 111 99 97 108 34 125 44 34 105 115 68 101 102 97 117 108 116 71 97 116 101 119 97 121 34 58 116 114 117 101 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 116 121 112 101 34 58 34 98 114 105 100 103 101 34 125 93 125Åå: o Äplugin bridge não suporta a versão de configuração "" Å
12 de março 05:26:30 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 30.886428 3656 cni.go: 237Å Não é possível atualizar a configuração do cni: nenhuma rede válida encontrada em /etc/cni/net.d/

Remover a configuração do plugin cni de /var/lib/kubelet/kubeadm-flags.env também funciona no CentOS 7.6 com k8s 1.16.8

por favor, não mude nada. Basta executar este comando. O erro desaparecerá.

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Obrigado @ikramuallah , que funcionou para 1.18, o problema é que não funcionou diretamente porque uma das

por favor, não mude nada. Basta executar este comando. O erro desaparecerá.

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

obrigado!

por favor, não mude nada. Basta executar este comando. O erro desaparecerá.
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

obrigado!

Não consigo acessar o link. Algo está errado ?

O link

Por favor alguem me ajude
Para kube-proxy-windows-xhxzw, o status do pod é ContainerCreating. Quando descrevo os pods, ele avisa como

Aviso NetworkNotReady 3m27s (x4964 em 168m) kubelet, rede casts1 não está pronta: a rede em tempo de execução não está pronta: NetworkReady = falso motivo: NetworkPluginNotReady mensagem: docker : o plugin de rede não está pronto: cni config não inicializado

Todos os outros pods estão em execução. exceto o kube-proxy-windows

Eu criei o ambiente do Kubernetes conforme abaixo:
Master Node Ready V1.19.0 RHEL 7 OS
Nó de trabalho NotReady V1.19.0 Windows Server 2019
Estou tentando juntar o nó de trabalho do Windows ao nó mestre

Estou usando a rede de flanela. Eu tentei as soluções abaixo:
1.kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

  1. Alterar cniVersion de 10-flannel.confglist de "0.3.1" para "0.2.0"
    10-flannel.confglist já estava lá.

Por favor, deixe-me saber o problema exato

No meu caso, quando sou o mestre do init kubernetes, tive esse problema. Depois de excluir todos os dados no etcd, o processo de inicialização foi bem-sucedido
Em todos os nós etcd:
systemctl stop etcd
rm -rf / var / lib / etcd / *
systemctl daemon-reload && systemctl enable etcd && systemctl start

Esta página foi útil?
0 / 5 - 0 avaliações