<p>kubeadm init travou em "O primeiro nó foi registrado, mas ainda não está pronto"</p>

Exatamente a mesma coisa acontecendo comigo no Ubuntu 16.04.02, ambas as instalações GCE e VMWare local, Docker versão 1.12.6, kernel 4.8.0-44-generic 47 ~ 16.04.1-Ubuntu SMP.

O log do kubelet mostra um aviso sobre a falta de /etc/cni/net.d antes do erro que vemos no relatório de jimmycuadra:

Mar 29 04:43:25 instance-1 kubelet[6800]: W0329 04:43:25.763117    6800 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Mar 29 04:43:25 instance-1 kubelet[6800]: E0329 04:43:25.763515    6800 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Mesmo problema no Ubuntu AWS VM. Docker 1.12.5

root @ ip-10-43-0-20 : ~ # versão kubeadm
kubeadm version: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.0", GitCommit: "fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState: "clean", BuildDate: "2017-03-28T16: 24 30Z ", GoVersion:" go1.7.5 "

root @ ip-10-43-0-20 : ~ # uname -a
Linux ip-10-43-0-20 4.4.0-45-generic # 66-Ubuntu SMP Quarta, 19 de outubro 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ ip-10-43-0-20 : ~ # kubeadm init --config cfg.yaml
[kubeadm] AVISO: o kubeadm está em beta, não o use para clusters de produção.
[init] Usando a versão do Kubernetes: v1.6.0
[init] Usando o modo de autorização: RBAC
[init] AVISO: Para que as integrações do cloudprovider funcionem, --cloud-provider deve ser definido para todos os kubelets no cluster.
(/etc/systemd/system/kubelet.service.d/10-kubeadm.conf deve ser editado para este propósito)
[preflight] Execução de verificações pré-voo
[preflight] Iniciando o serviço kubelet
[certificados] Certificado e chave CA gerados.
[certificados] Certificado e chave do servidor API gerado.
[certificados] O certificado de serviço do servidor API é assinado para nomes DNS [ip-10-43-0-20 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] e IPs [10.96.0.1 10.43.0.20 ]
[certificados] Certificado e chave do cliente kubelet do servidor API gerado.
[certificados] Chave de assinatura de token de conta de serviço gerada e chave pública.
[certificados] Certificado e chave CA do proxy frontal gerado.
[certificados] Certificado e chave de cliente front-proxy gerados.
[certificados] Certificados e chaves válidos agora existem em "/ etc / kubernetes / pki"
[kubeconfig] Arquivo KubeConfig gravado no disco: "/etc/kubernetes/admin.conf"
[kubeconfig] Arquivo KubeConfig gravado no disco: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Arquivo KubeConfig gravado no disco: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Arquivo KubeConfig gravado no disco: "/etc/kubernetes/scheduler.conf"
[apiclient] Cliente API criado, esperando que o plano de controle esteja pronto
[apiclient] Todos os componentes do plano de controle estão saudáveis ​​após 16,531681 segundos
[apiclient] Aguardando pelo menos um nó para se registrar e ficar pronto
[apiclient] O primeiro nó foi registrado, mas ainda não está pronto
[apiclient] O primeiro nó foi registrado, mas ainda não está pronto
[apiclient] O primeiro nó foi registrado, mas ainda não está pronto

++ o mesmo problema (Ubuntu 16.04.1)

Mesma coisa aqui no Ubuntu 16.04

No CentOS 7, eu fiz downgrade do kubelet para 1.5.4 . Isso resolveu para mim. Parece que a verificação de pronto funciona de maneira diferente no 1.6.0 kubelet.

O mesmo problema no CentOS 7 na máquina bare metal x64, desde a atualização para k8s 1.6.0

Mesmo problema no Ubuntu 16.04

O mesmo problema no Ubuntu 16.04, fazer o downgrade manualmente do pacote kubelet resolveu o problema.

# apt install kubelet=1.5.6-00

@ctrlaltdel não funcionou para mim.

Suspeito que seja um problema do Kubelet. Não deve marcar o nó como não pronto quando CNI é desconfigurado. Apenas pods que requerem CNI devem ser marcados como não prontos.

@jbeda Você sabe quando esse problema será resolvido?

@kristiandrucker - não - ainda

@jbeda Ok, mas depois que o problema for resolvido, e daí? Reconstruir o kubelet a partir da fonte?

@kristiandrucker Isso terá que sair em um lançamento pontual do k8s se for um problema de kubelet.

Suspeito que https://github.com/kubernetes/kubernetes/pull/43474 seja a causa raiz. Vou registrar um bug e acompanhar o pessoal da rede.

@dcbw Você está por aí?

Parece que o problema é que um DaemonSet não está agendado para nós que têm a condição Net stNetwork: true deve ser agendado em um nó que é Net workReady: false , mas um pod ho

Como solução alternativa, adicionar a anotação scheduler.alpha.kubernetes.io/critical-pod em seu DaemonSet faz as coisas funcionarem novamente?

@janetkuo @lukaszo você pode fazer a triagem do comportamento do DS?

Há também uma discussão em andamento em # sig-network on slack, aliás.

Mesmo problema CentOS 7 x64

@prapdm isto parece não ter defesa da distro que você está executando.

CentOS Linux versão 7.3.1611 (Core)

Eu tentei em um nó com Ubuntu 16.04. Ele trava com a mensagem "ainda não está pronto". Eu também criei manualmente o DaemonSet de flanela, mas no meu caso agendei um pod sem nenhum problema. O próprio pod daemon foi para o CrashLoopBackOff com o erro: E0329 22:57:03.065651 1 main.go:127] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-z3xgn': the server does not allow access to the requested resource (get pods kube-flannel-ds-z3xgn)

Vou experimentar o Centos também, mas não acho que DaemonSet seja o culpado aqui, o kubeadm trava aqui.

isso é um erro de permissão rbac.

@jimmycuadra Acabei de notar que você está executando no Raspberry Pi, que tem um processador de braço.

Para o conjunto de daemon de flanela, você tem:

`` `nodeSelector:
beta.kubernetes.io/arch: amd64

but your node is labeled with: 

beta.kubernetes.io/arch=arm
`` `

Portanto, o DaemonSet não pode iniciar o pod neste nó, apenas altere o seletor de nó e ele funcionará.
Você ainda receberá o erro com a permissão rbac, mas talvez @mikedanese lhe diga como consertar, porque eu não sei.

Ah, obrigado @lukaszo! Eu não estava seguindo o guia específico do RPi desta vez (que usei para o K8s 1.5) e esqueci essa etapa. Eu teria descoberto quando o daemon definiu um erro, mas descobri que não fui tão longe. :}

Também estou vendo esse problema quando sigo as instruções descritas aqui:
https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

conseguiu fazê-lo funcionar depois de instalar o pod de rede de flanela certo.

Acho que @jimmycuadra pode fazer funcionar com o comentário do @lukaszo .

Quando a mensagem [apiclient] First node has registered, but is not ready yet start flooding, o servidor da API kubernetes estará em execução para que você possa:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl create -f -

Para a instalação do Raspberry Pi:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | sed "s/amd64/arm/g" | kubectl create -f -

Então vai terminar:

[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 245.050597 seconds
[apiclient] Test deployment succeeded
[token] Using token: 4dc99e............
[apiconfig] Created RBAC rules
[addons] Created essential addon: kube-proxy
[addons] Created essential addon: kube-dns

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 4dc99e........... 192.168.1.200:6443

Eu tive o mesmo problema e resolvi desta forma:
você deveria ser root

no 1.6.0 do kubeadm, você deve remover a variável de ambiente $ KUBELET_NETWORK_ARGS do arquivo de sistema: /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

então reinicie demônios

systemctl daemon-reload

kubeadm init

isso demora um pouco ... depois do sucesso

baixe o complemento de rede que deseja usar: http://kubernetes.io/docs/admin/addons/

chita parece ser o melhor, não tenho certeza, mas ainda está em teste para mim.

@thelastworm
Eu apenas tentei fazer isso e não funcionou.
Ubuntu 16.04.2 LTS, kubeadm 1.6.0
Eu fiz as seguintes etapas:

1. edite /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e remova $ KUBELET_NETWORK_ARGS
2. kubeadm reset para limpar a tentativa anterior de iniciá-lo
3. kubeadm init --token=<VALUE> --apiserver-advertise-address=<IP>

[EDITADO]
Funcionou depois que @ srinat999 apontou para a necessidade de executar systemctl daemon-reload antes de kubeadm init

A solução de @jcorral funcionou para mim com uma mudança na implantação da flanela, uma vez que a porta API insegura não é mais criada por kubeadm .

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | \
kubectl --kubeconfig /etc/kubernetes/admin.conf create -f -

@MaximF Você deve fazer systemctl daemon-reload após alterar o arquivo conf. Funcionou para mim.

@jcorral Sua solução funciona para mim. Obrigado.

@MaximF acabei de adicionar a linha de comando restart demon

O kubeadm init foi concluído com sucesso, mas quando eu verifico a versão, obtenho o seguinte erro:

Versão do cliente: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.0", GitCommit: "fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState: "clean", BuildDate: "2017-03-28T16: 36: 33Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}
A conexão com o servidor localhost: 8080 foi recusada - você especificou o host ou a porta correta?

@haribole
Você deve definir o KUBECONFIG env var

Alguém mandou Flannel correr atrás das soluções alternativas relacionadas à CNI? Posso passar pelo problema de não estar pronto, mas quando executo o Flannel, recebo um erro parecido com este:

Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-g5cbj': the server does not allow access to the requested resource (get pods kube-flannel-ds-g5cbj)

O status dos pods mostra "CrashLoopBackOff"

Você precisa adicionar funções rbac para autorizar a flanela a ler da API.

Você precisa adicionar funções rbac para autorizar a flanela a ler da API.

Caso alguém esteja se perguntando o que isso significa, parece que você precisa criar kube-flannel-rbac.yml antes de criar a flanela:

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

Acho que, como o problema raiz foi resolvido e o tíquete relacionado foi fechado , devemos fechar este também :)

Apenas para informação: está funcionando para mim agora com os pacotes atualizados no Ubuntu 16.04.

1.6.1 funciona para mim! Obrigado a todos que ajudaram a resolver esse problema!

Eu configurei com sucesso meu cluster Kubernetes em centos-release-7-3.1611.el7.centos.x86_64 executando as seguintes etapas (presumo que o Docker já esteja instalado):

1) (de /etc/yum.repo.d/kubernetes.repo) baseurl = http: //yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Para usar o repositório instável para o Kubernetes 1.6.1 mais recente
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) adicione "--cgroup-driver = systemd" no final da última linha.
=> Isso ocorre porque o Docker usa systemd para cgroup-driver enquanto kubelet usa cgroupfs para cgroup-driver.
4) systemctl enable kubelet && systemctl start kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Se você costumava adicionar --api-anunciar-endereços, você precisa usar --apiserver-anunciar-endereço.
6) cp /etc/kubernetes/admin.conf $ HOME /
sudo chown $ (id -u): $ (id -g) $ HOME / admin.conf
exportar KUBECONFIG = $ HOME / admin.conf
=> Sem esta etapa, você pode obter um erro com kubectl get
=> Eu não fiz isso com 1.5.2
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 introduz um controle de acesso baseado em função, então você deve adicionar um ClusterRole e um ClusterRoleBinding antes de criar um daemonset Flannel
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Criar um daemonset de flanela
9) (em cada nó escravo) kubeadm join --token (seu token) (ip) :( porta)
=> conforme mostrado no resultado do kubeadm init

Todas as etapas acima são resultado da combinação de sugestões de vários problemas do Kubernetes-1.6.0, especialmente do kubeadm.

Espero que isso economize seu tempo.

@eastcirclek @Sliim Você é ótimo

@eastcirclek essas foram as etapas exatas que acabei de executar ao consultar vários fóruns também. Uma diferença de fuso horário, talvez? Obrigado a todos, este tópico foi realmente útil.

Eu tenho o servidor Ubuntu 16.04 na AWS e segui as etapas

1. edite /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e remova $ KUBELET_NETWORK_ARGS
2. kubeadm reset para limpar a tentativa anterior de iniciá-lo
3. kubeadm init --token =--apiserver-advertise-address =

que aparentemente funcionou corretamente, mas quando tento instalar o Calico como plugin de rede, recebo o seguinte erro
A conexão com o servidor localhost: 8080 foi recusada - você especificou o host ou a porta correta?

A equipe k8s está trabalhando em um patch?

Obrigado

@overip Não acho que nenhum patch seja necessário para isso ... Você só precisa especificar o arquivo kubeconfig correto ao usar o kubectl. kubeadm deveria ter escrito em /etc/kubernetes/admin.conf .

@jimmycuadra poderia explicar os passos para fazer isso?

@overip A saída de kubeadm init tem as instruções:

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Pessoalmente, prefiro copiar o arquivo para $HOME/.kube/config , que é onde kubectl o procurará por padrão. Então você não precisa definir a variável de ambiente KUBECONFIG.

Se você está planejando usar o kubectl em sua máquina local, pode usar scp (ou apenas copiar e colar o conteúdo) para gravá-lo em ~/.kube/config em seu próprio computador.

Procure por "admin.conf" neste problema do GitHub para obter mais detalhes. Isso foi mencionado algumas vezes.

@eastcirclek - seguiu os passos, mas por algum motivo os nós não conseguem instalar a flanela corretamente.
(Nota: no mestre tudo é bom.)

Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666206   22893 kuberuntime_manager.go:458] Container {Name:install-cni Image:quay.io/coreos/flannel:v0.7.0-amd64 Command:[/bin/sh -c set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:cni ReadOnly:false MountPath:/etc/cni/net.d SubPath:} {Name:flannel-cfg ReadOnly:false MountPath:/etc/kube-flannel/ SubPath:} {Name:flannel-token-g65nf ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:nil ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:nil Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666280   22893 kuberuntime_manager.go:742] checking backoff for container "install-cni" in pod "kube-flannel-ds-3smf7_kube-system(2e6ad0f9-207f-11e7-8f34-0050569120ff)"
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846325   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/configmap/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-cfg" (spec.Name: "flannel-cfg") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846373   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-token-g65nf" (spec.Name: "flannel-token-g65nf") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").

Basta compartilhar meu método de solução alternativa. Em primeiro lugar, $ KUBELET_NETWORK_ARGS é necessário, caso contrário, o CNI não é habilitado / configurado. Remover e restaurar $ KUBELET_NETWORK_ARGS parece muito complicado.
Quando o kubeadm init mostra "[apiclient] O primeiro nó foi registrado, mas ainda não está pronto", o cluster k8s está realmente pronto para atender à solicitação. Nesse momento, o usuário pode simplesmente passar para a etapa 3/4 de https://kubernetes.io/docs/getting-started-guides/kubeadm/ conforme a seguir.

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:  http://kubernetes.io/docs/admin/addons/

Quando um usuário instala a podnetwork, certifique-se de que a conta de serviço da política de podnetwork tenha permissão suficiente. Tomando a flanela como exemplo. Acabei de vincular a função de administrador de cluster à conta de serviço de flanela da seguinte maneira. Pode não ser o ideal e você pode definir uma função específica para a conta de serviço de flanela. BTW, quando um usuário implanta outro serviço adicional como o painel, ele também requer a concessão de permissão suficiente para a conta de serviço relacionada.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flannel:daemonset
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: flannel
  namespace:  kube-system

Depois que o servidor do podnetwork estiver pronto, o kubeadm init mostrará que o nó está pronto e que o usuário poderá continuar com a instrução.

Tomando a flanela como exemplo. Acabei de vincular a função de administrador de cluster à conta de serviço de flanela da seguinte maneira. Pode não ser o ideal e você pode definir uma função específica para a conta de serviço de flanela.

Já existe https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Obrigado a todos pela ajuda.
Finalmente K8s 1.6.1 totalmente funcional com flanela. Tudo agora está nos manuais do ansible.
Testado em Centos / RHEL. Também começaram as preparações baseadas em Debian (por exemplo, Ubuntu), mas pode ser necessário algum refinamento.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS: trabalho baseado em sjenning / kubeadm-playbook - Muito obrigado, @sjenning

Obtendo isso para se juntar a um cluster:
[descoberta] Cliente de descoberta de informações de cluster criado, solicitando informações de " https://10.100.2.158 : 6443"
[descoberta] Falha ao solicitar informações do cluster, tentarei novamente: [configmaps "cluster-info" é proibido: O usuário " system: anonymous " não pode obter configmaps no namespace "kube-public"]
[descoberta] Falha ao solicitar informações do cluster, tentarei novamente: [configmaps "cluster-info" é proibido: O usuário " system: anonymous " não pode obter configmaps no namespace "kube-public"]

Comecei o nó como SelfHosting.