/ cc @lukemarsden @luxas @mikedanese

Se revertermos o número 43474 completamente, estaremos novamente em uma situação em que quebramos os plug-ins 0.2.0 CNI (consulte https://github.com/kubernetes/kubernetes/issues/43014)

Devemos pensar em fazer algo como https://github.com/kubernetes/kubernetes/pull/43284?

Também / cc @thockin

/ cc @ kubernetes / sig-network-bugs

Ref: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda, posso obter alguns logs do kubelet com --loglevel = 5?

@yujuhong - você mencionou que acha que está funcionando conforme o

Discussão em andamento agora - https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Parece que os DaemonSets ainda serão agendados, mesmo se o nó não estiver pronto. Neste caso, kubeadm é um pouco paranóico demais.

O plano atual que vamos testar é que kubeadm não espere mais que o nó mestre esteja pronto, mas apenas registre-o. Isso deve ser bom o suficiente para permitir que um CNI DaemonSet seja agendado para configurar o CNI.

@kensimon está testando isso.

@jbeda sim, parece que o controlador DaemonSet ainda irá enfileirá-los, principalmente porque ignora completamente a existência de rede. Devemos realmente corrigir isso de forma mais geral. Existe algo imediato para fazer no kube ou é tudo no kubeadm por enquanto?

Estou tentando instalar o kubernetes com kubeadm no Ubuntu 16.04. Existe uma solução rápida para isso?

@jbeda se você tiver uma versão corrigida, feliz em testá-la ..

Eu fiz o kubeadm ultrapassando o status NotReady do nó, mas a implantação fictícia que ele cria não está funcionando devido à contaminação node.alpha.kubernetes.io/notReady impedindo sua execução. Adicionar tolerâncias não parece ajudar, não tenho certeza de como proceder neste ponto. Alguém pode lançar alguma luz sobre como implantar um pod que tolere a contaminação notReady ?

Estou explorando algumas outras opções, como não marcar o nó como notReady, mas não está claro se é isso que queremos fazer.

contornamos isso removendo KUBELET_NETWORK_ARGS da linha de comando do kubelet. depois disso, o init kubeadm funcionou bem e pudemos instalar o plugin canal cni.

@sbezverk, poderia descrever como fazer isso?

Pode confirmar as descobertas de @sbezverk (good find :)), ajustar /etc/systemd/system/10-kubeadm.conf e remover KUBELET_NETWORK_ARGS fará com que ele rode em centos. Testado com tecido.

@overip, você precisa editar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

remover $ KUBELET_NETWORK_ARGS

e reinicie o kubelet depois que o init bebeadm deve funcionar.

isso é o que eu fiz

kubeadm reset

remover entradas ENV de:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

recarregar os serviços systemd e kube

systemctl daemon-reload
systemctl restart kubelet.service

execute novamente o init

kubeadm init

Tudo correto, e enquanto estamos nisso

Se você vir isso:
kubelet: erro: falha ao executar Kubelet: falha ao criar kubelet: configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"

você deve editar seu /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e adicionar a sinalização --cgroup-driver = "systemd"

e faça como acima

kuebadm reset
systemctl daemon-reload
systemctl restart kubelet.service
kubeadm init.

Eu teria cuidado ao remover --network-plugin=cni dos sinalizadores CLI do kubelet, isso faz com que o kubelet use o plug-in no_op por padrão ... Eu ficaria surpreso se plug-ins comuns como calico / weave funcionassem neste caso (mas então, novamente, meu entendimento de como esses plug-ins operam por baixo é um pouco limitado.)

@kensimon hm, não vi nenhum problema na minha configuração, implantei o plugin canal cni e funcionou bem ..

@sbezverk A rede entre hosts também está funcionando bem?

@resouer não pode confirmar, tenho 1.6.0 apenas como

@resouer @sbezverk Eu entrei com sucesso em uma máquina.

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

`` `[ root @ deploy-01 x86_64] # kubectl get pods -n kube-system
NOME PRONTO STATUS REINICIA IDADE
etcd-deploy-01 1/1 Executando 0 50m
kube-apiserver-deploy-01 1/1 Executando 0 51m
kube-controller-manager-deploy-01 1/1 Executando 0 50m
kube-dns-3913472980-6plgh 3/3 Running 0 51m
kube-proxy-mbvdh 1/1 Executando 0 4m
kube-proxy-rmp36 1/1 Executando 0 51m
kube-scheduler-deploy-01 1/1 Executando 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 Executando 0 24m
weave-net-3t487 2/2 Running 0 44m
weave-net-hhcqp 2/2 Running 0 4m

`` `

a solução alternativa funciona, mas a flanela não funciona ...

Cenário de pior caso

Eu tenho um cluster de três nós com weave funcionando. Não tenho certeza de como isso pode ser estável com este hack, mas obrigado de qualquer maneira! :risonho:

Em um nó lateral, você pode colocar de volta o $ KUBELET_NETWORK_ARGS, após o init no mestre passar. Na verdade, eu não o removi da máquina em que entrei, apenas o cgroup-driver, caso contrário, o kubelet e o docker não funcionarão juntos.

Mas você não precisa redefinir o kubeadm, apenas altere /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e faça a dança systemctl:

systemctl daemon-reload
systemctl restart kubelet.service

Para aqueles que estão descartando KUBELET_NETWORK_ARGS e relatando que funciona para você:

Para mim, tenho 2 clusters: um onde apliquei o patch de https://github.com/kubernetes/kubernetes/pull/43824 e deixei o kubeadm prosseguir normalmente na inicialização e um com KUBELET_NETWORK_ARGS excluído. No cluster com KUBELET_NETWORK_ARGS removido, qualquer tráfego entre os pods falha.

Em um cluster com KUBELET_NETWORK_ARGS removido:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

Em um cluster com KUBELET_NETWORK_ARGS normal, mas com um kubeadm corrigido:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Se você é um daqueles que desabilitou KUBELET_NETWORK_ARGS, verifique se o acima funciona para você.

Eu sugiro que deixemos o nó pronto e a verificação de implantação fictícia
completamente para 1.6 e mova-os para uma fase de validação para 1.7.

Em 29 de março de 2017 10:13, "Dan Williams" [email protected] escreveu:

@jbeda https://github.com/jbeda sim, parece o DaemonSet
controlador ainda os enfileirará principalmente porque é completamente ignorante
de rede-iness. Devemos realmente corrigir isso de forma mais geral. Existe
algo imediato para fazer no kube ou é tudo no kubeadm por enquanto?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Alguém mais executando o Ubuntu 16.04? Removi KUBELET_NETWORK_ARGS do serviço systemd e recarreguei o daemon systemd . Posso ativar um nó mestre, mas não posso ingressar em um nó. Ele falha com o erro The requested resource is unavailable

KUBELET_NETWORK_ARGS removido, qualquer tráfego entre pods falha.

Eu não ficaria surpreso, pois KUBELET_NETWORK_ARGS diz ao kubelet qual plugin usar, onde procurar a configuração e os binários. Você PRECISA deles.

Eu recomendo # 43835 (e a escolha certa do 1.6 # 43837) como a correção que fazemos para o 1.6. Eu testei os dois e eles funcionam. Designei @jbeda e @luxas para revisar quando eles acordarem.

Ambos os PRs parecem razoáveis. Mas acho que devemos olhar para https://github.com/kubernetes/kubernetes/pull/43824 . Embora seja um pouco mais complicado, ele preserva esse caminho de código para que os usuários que pré-configuram CNI fora do uso de um Daemonset (faço isso em https://github.com/jbeda/kubeadm-gce-tf, embora não atualizou-o para 1.6) ainda espera que os nós estejam prontos.

Como um bônus, este é @kensimon 's primeira PR para Kubernetes e ele retirou as paradas para testar este material para fora. Mas, para ser honesto, ambos são viáveis ​​e eu realmente quero que isso seja consertado. :)

Desculpe, perdi https://github.com/kubernetes/kubernetes/pull/43824. Eu também estou feliz com qualquer um, se ambos funcionarem.

Eu também estou feliz com qualquer um se ambos funcionarem também

@kensimon Funciona comigo, quando eu desabilito apenas KUBELET_NETWORK_ARGS durante kubadm init . Graças às suas instruções, pude verificar isso.

@Webwurst confirmado para funcionar quando você desabilita apenas KUBELET_NETWORK_ARGS durante kubadm init . Eu tive que reiniciar o kube-dns para ele pegar. A verificação de @kensimon funciona, dns resolve.

Embora eu concorde que este é um hack terrível, e horrível demais para a maioria das pessoas seguirem, olhando para os canais de folga.

Uma solução melhor é apresentada pelos patches de @kensimon ou @mikedanese.

@coeki exatamente como você reiniciou o kube-dns. Eu tentei kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system e agora kube-dns permanece pendente kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Ele fez exatamente como descrito: remover KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , adicionar KUBELET_NETWORK_ARGS , novamente sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
Mas então meu mestre fica em NotReady . Em describe eu recebo

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Tentei reiniciar o kube-dns conforme descrito acima, mas sem sucesso. Qualquer ideia? Estou morrendo de vontade de tentar fazer nosso cluster funcionar novamente após uma atualização com falha para 1.6.0 neste morging :(

@patte Então eu apenas delete pods kube-dns-3913472980-3ljfx -n kube-system E então kube-dns aparece novamente.

Após o kubeadm init, você adicionou KUBELET_NETWORK_ARGS , novamente sudo systemctl daemon-reload && sudo systemctl restart kubelet.service instalou uma rede de pod, como weave ou calico? Adicione isso primeiro, você deve conseguir fazê-lo funcionar.

Eu tentei e testei no centos7 e apenas fiz no ubuntu / xenial, então deve funcionar.

Para recapitular o que eu fiz:

remover KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

adicione KUBELET_NETWORK_ARGS novamente
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

Entrou em uma máquina, normalmente tenho que adicionar uma rota estática para 10.96.0.0 (cluster ip), pois estou no vagrant.
Use com o $ TOKEN, mas esta etapa é extra.

Então:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Espere por isso

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

Funciona para mim, embora seja um hack horrível;)

Estou realmente surpreso que a comunidade de desenvolvimento do Kubernetes não forneceu nenhum ETA para uma correção oficial. Quero dizer, este é um bug horrível que deve ser facilmente detectado durante o teste de código. Uma vez que não foi, pelo menos, 1.6.1 deve ser empurrado o mais rápido possível com a correção para que as pessoas parem de hackear seus clusters e comecem a fazer coisas produtivas;). Eu estou errado aqui?

Olá a todos,

Eu estava um pouco distraído esta semana, e este é um longo tópico cheio de
coisas do kubeadm que eu não conheço bem. Alguém pode resumir para mim? eu
acho que entendi a essência do bug, mas quais são as soluções propostas e
o que os torna horríveis?

Na quinta-feira, 30 de março de 2017 às 8:13, Serguei Bezverkhi < [email protected]

escreveu:

Estou realmente surpreso que a comunidade de desenvolvimento do Kubernetes não tenha
forneceu qualquer ETA para uma correção oficial. Quero dizer, este é um bug horrível que
deve ser facilmente detectado durante o teste de código. Uma vez que não tem, em
no mínimo, 1.6.1 deve ser empurrado o mais rápido possível com a correção para que as pessoas
pare de hackear seus clusters e comece a fazer coisas produtivas;). Sou eu
errado aqui?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Uma mudança no kubelet (# 43474) fez com que o kubelet começasse a relatar corretamente a rede que não estava pronta antes que o plug-in cni fosse inicializado. Isso quebrou alguns pedidos dos quais dependíamos e causou um impasse na inicialização do mestre do kubeadm. Não percebemos porque os testes do kubeadm e2e foram interrompidos por alguns dias antes dessa mudança.

As correções propostas atuais são # 43824 e # 43835.

ok, foi isso que eu entendi. O bloqueio entre o plugin de rede
chegando e a prontidão do nó é um pouco terrível agora.

Em quinta-feira, 30 de março de 2017 às 8h28, Mike Danese [email protected]
escreveu:

Uma mudança no kubelet (# 43474
https://github.com/kubernetes/kubernetes/pull/43474 ) fez com que o kubelet
começar a reportar corretamente a rede não estava pronta antes de o plugin cni ser
inicializado. Isso quebrou alguns pedidos dos quais dependíamos e causou
um impasse na inicialização do mestre do kubeadm. Nós não pegamos porque
Os testes do kubeadm e2e foram interrompidos por alguns dias antes dessa mudança.

As correções propostas atuais são # 43824
https://github.com/kubernetes/kubernetes/pull/43824 e # 43835
https://github.com/kubernetes/kubernetes/pull/43835 .

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

Ainda prefiro # 43835. É uma alteração mais simples, não acho que as verificações do e2e devam ser feitas onde estão, e há relatos de # 43824 que ainda não está funcionando. Vou pressionar para resolver isso hoje.

+1 para resolvê-lo hoje, pois muitos esforços são desperdiçados ao lidar com a garantia da solução alternativa.

Não acredito que ninguém realmente tentou o kubeadm 1.6.0 antes do lançamento do 1.6.0 ....

E, kubelet 1.5.6 + kubeadm 1.5.6 também estão corrompidos, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf faz referência a /etc/kubernetes/pki/ca.crt, mas kubeadm não gera ca.crt, há ca.pem embora.

Atualmente 1.6.0 e 1.5.6 são as únicas versões restantes no repositório apt k8s ...

"estourou fora da caixa", palavras aprendidas hoje.

Ainda prefiro # 43835. É uma alteração mais simples, não acho que as verificações do e2e devam ser feitas onde estão, e há relatos de # 43824 que ainda não está funcionando. Vou pressionar para resolver isso hoje.

Concordo com Mike sobre isso. # 43835 é a alteração mais simples e a validação (se necessária) pode ser feita em uma fase separada.

@thockin , realmente precisamos de condições e status mais refinados para a rede, especialmente com ho stNetwork: true. Os nós podem estar prontos para alguns pods, mas não para outros.

Não podemos usar nodeNetworkUnavailable, porque isso é específico para provedores de nuvem. Provavelmente precisamos de outro, ou de uma maneira do agendador permitir ho stNetwork: true pods em nós com Net workReady: false , ou fazer com que as manchas funcionem para nós não preparados. E testes de trabalho do kubeadm e2e :(

Aceita. Tenho atrasado o problema porque não tenho boas respostas,
mas precisamos conseguir isso em 1,7

Em quinta-feira, 30 de março de 2017 às 10h02, Dan Williams [email protected]
escreveu:

@thockin https://github.com/thockin , realmente precisamos de uma granulação mais fina
condições e status para rede, especialmente com ho stNetwork: true.
Os nós podem estar prontos para alguns pods, mas não para outros.

Não podemos usar nodeNetworkUnavailable, porque isso é específico para nuvem
provedores. Provavelmente precisamos de outro, ou uma maneira de o agendador
allow ho stNetwork: true pods em nós com Net workReady: false , ou tornando o
manchas funcionam para nós não preparados.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin alguma solução preferida? Podemos bloquear a prontidão do nó e descobrir quem usa IsNodeReady () como já fizemos, ou podemos adicionar outra condição de nó e, em seguida, corrigir quem-sabe-quantos bits da base de código em outro lugar para isso. Ou talvez haja outra opção.

Não podemos usar nodeNetworkUnavailable, porque isso é específico para provedores de nuvem. Provavelmente precisamos de outro, ou de uma maneira do agendador permitir ho stNetwork: true pods em nós com Net workReady: false , ou fazer com que as manchas funcionem para nós não preparados.

Acho que o agendador pode ser corrigido para respeitar manchas e tolerâncias, em vez de excluir completamente todos os nós não preparados.
Alguém terá que aplicar a tolerância no ho stNetwork: true pods. Eu não sei quem, mas não deve ser o planejador, já que ensinar o planejador a entender as especificações do pod parece demais.

/ cc @davidopp @ dchen1107

Além disso, para qualquer um que tentou os patches meus ou do Michael e está ficando preso no plano de controle que está chegando, parece que construir um kubeadm de master não funciona quando ele gerencia um cluster v1.6.0 , devido a kubeadm tentando iniciar kube-apiserver com argumentos inválidos:

unknown flag: --proxy-client-cert-file

Se você quiser testar as mudanças minhas ou de Michael em um cluster v1.6.0, escolha-as a dedo em relação à v1.6.0 em vez de construir em cima do mestre por enquanto.

@yujuhong o planejador já aplica automaticamente as tolerâncias aos pods (consulte https://github.com/kubernetes/kubernetes/pull/41414), este parece ser um caso de uso bastante semelhante

Eu não tenho uma imagem clara de todas as manchas e prontidão de
rede, neste ponto. Dan, você tem meia hora para escrever o
estado atual, para que possamos começar a separá-lo? Eu acho que você sabe disso
melhor. Eu sinto que temos uma série de problemas granulares que acabamos de
coberto por um cobertor até agora.

Na quinta-feira, 30 de março de 2017 às 10:22, Ken Simon [email protected]
escreveu:

@yujuhong https://github.com/yujuhong o planejador já
aplica automaticamente as tolerâncias aos frutos (consulte # 41414
https://github.com/kubernetes/kubernetes/pull/41414 ), isso parece um
caso de uso semelhante o suficiente

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin eu posso fazer isso, onde devo colocá-lo?

há alguns problemas relacionados, podemos renomear um deles, postar um
resumo do estado atual e ir de lá?

Na quinta-feira, 30 de março de 2017 às 10:50, Dan Williams [email protected]
escreveu:

@thockin https://github.com/thockin eu posso fazer isso, onde devo colocar
isto?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

Temos alguma linha de tempo para saber quando esse conserto será portado para o repositório CentOS?

No 1.6, por padrão, o Kubernetes principal não aplica automaticamente nenhuma contaminação aos nós. O planejador respeita as manchas que são adicionadas por sistemas de implantação como kubeadm, kops, etc. ou adicionadas manualmente pelos usuários (e respeita as tolerâncias correspondentes que são adicionadas aos pods).

No 1.6, por padrão, o programador Kubernetes exclui nós da consideração se eles estiverem relatando certas condições de nó, incluindo rede indisponível. O código para isso está aqui . Não tem nada a ver com manchas - é apenas olhar para a condição do nó.

No 1.6, você pode habilitar um recurso alfa que faz com que o Kubernetes principal (o NodeController) adicione uma mancha NoExecute sempre que houver NodeReady == "False" ou NodeReady == "Desconhecido". Isso fará com que os pods em execução no nó sejam despejados (se não tolerarem a contaminação) e evitará que novos pods sejam programados no nó (se não tolerarem a contaminação).

O plano de longo prazo é mover toda a lógica "como o Kubernetes principal reage às condições do nó, com relação à programação e remoção" para usar manchas e tolerâncias (por exemplo, # 42001). Mas ainda não chegamos e não chegaremos por enquanto. Portanto, a curto prazo, não há como um pod "tolerar" NetworkUnavailable ou qualquer outra condição de nó que você decida adicionar.

Se eu entendi o que @davidopp disse certo, então a função é NodeReady, que agora retorna verdadeiro ou falso ou desconhecido, marca uma lista com o que é necessário. Se puder retornar uma lista de valores não atendidos, você pode testar isso.

No caso do kubeadm, se NetworkUnavailable, é o único. kubeadm pode retornar verdadeiro. Este é o caso de não querermos que o plugin networking / cni seja passado no tempo de inicialização do kubeadm.

Porque se eu entendi bem, o taint's e a tolerância são definidos com base nesta função, pelo menos para kubeadm.

Corrija-me se eu estiver errado ;)

Pisando neste tópico porque encontrei este problema e é irritante:

Por que a prontidão da rede não pode se tornar uma contaminação que o kubelet adiciona e remove com base no estado da rede no nó?
Dessa forma, o nó pode estar "Pronto" para todos os pods que toleram a contaminação de prontidão da rede (aplicativos de rede de pod).

Quanto aos pods de rede de host, um controlador de admissão pode injetar tolerâncias para contaminação de prontidão de rede de pod.

Eu acho que se alinha com o plano de longo prazo no comentário de davidopp.

Eu acho que se alinha com o plano de longo prazo no comentário de davidopp.

Sim, exatamente. O plano de longo prazo é ter uma contaminação para cada condição do nó e parar de ter qualquer coisa interna no Kubernetes, prestar atenção às condições do nó. Começamos esse trabalho com o recurso 1.6 alpha que mencionei.

Ack. Existe uma razão para não mudar para manchas na versão do patch v1.6?

O código para adicionar manchas automaticamente com base nas condições do nó acabou de entrar em alfa no 1.6. Não está pronto para ser invocado. (E ele apenas lida com a condição de nó pronto atualmente, não com a rede).

Então, se bem entendi, por enquanto, uma vez que https://github.com/kubernetes/features/issues/166 está demorando mais para conseguir manchar a disponibilidade da rede corretamente, temos que ir com uma solução alternativa. Se pudermos enviar uma correção o mais rápido possível para o kubeadm, como # 43835, com um comentário para corrigir isso com https://github.com/kubernetes/features/issues/166 , muitos funcionários ficarão felizes.

@davidopp Suponho que você quis dizer " não confiado em ". Ainda estou perdendo a relação entre a condição automática para manchar a lógica que você mencionou com o kubelet postando manchas diretamente para problemas de rede.

Sim, obrigado, foi um erro de digitação, corrigido agora

Sim, você poderia fazer com que Kubelet adicionasse a contaminação. Pode não ser ideal ter Kubelet adicionando as manchas para algumas condições de nó e NodeController adicionando-as para outras condições de nó (o último é necessário porque apenas o mestre pode detectar nó inacessível), mas isso é apenas um argumento de engenharia de software, não algo fundamental. Meu plano era que o NodeController adicionasse as manchas para todas as condições do nó, mas não há nenhum requisito forte para fazer isso dessa forma.

Ack. Nesse caso, uma única condição de Nó tem vários atributos associados a ela que o Controlador de Nó pode não ser capaz de discernir.
@mikedanese Acho que o comportamento existente de kubeadm init resultando em um nó funcional é atraente. Espero que o requisito de adicionar uma fase validation não seja baseado principalmente neste problema.
@dcbw @thockin @yujuhong alguma

Observe que se você quiser que seu novo taint substitua a filtragem automática atual de nós por NetworkUnavailable, você precisará modificar a função que mencionei anteriormente (ou seja, removê-la do conjunto de condições que filtram um nó). Não sei que outros efeitos colaterais isso terá, uma vez que essa função pode ser usada em listas de nós diferentes apenas do agendador.

Existe uma maneira de instalar o 1.5.6 que deve estar funcionando no Ubuntu? Se houver, você poderia explicar como fazer? Obrigado!

Observe que se você quiser que seu novo taint substitua a filtragem automática atual de nós por NetworkUnavailable, você precisará modificar a função que mencionei anteriormente (ou seja, removê-la do conjunto de condições que filtram um nó). Não sei que outros efeitos colaterais isso terá, uma vez que essa função pode ser usada em listas de nós diferentes apenas do agendador.

@davidopp , precisamos ter cuidado com NetworkUnavailable vs. NodeReady. Existem duas condições distintas que realmente devem ser limpas:

nodeNetworkUnavailable - isso é específico para rotas de nuvem e apenas os controladores de rota de nuvem eliminam essa condição quando as rotas de nuvem entre nós foram configuradas. Os plug-ins de rede que criam sobreposições ou que não fazem roteamento L3 entre os nós não desejam ou usam essa condição. Esta condição não é adicionada por nenhum plugin de rede; é adicionado pelo kubelet especificamente quando GCE ou AWS são selecionados como provedores de nuvem. Não afeta o NodeReady, pois é uma condição separada.

NodeReady - afetado diretamente pelos plug-ins de rede (por exemplo, CNI ou kubenet ou tempos de execução remotos como dockershim / CRI-O).

Existem três questões distintas a serem consideradas:

1. Rotas de nuvem - se a infraestrutura de nuvem e o plug-in de rede exigem rotas de nuvem, a falta de rotas de nuvem (por exemplo, NodeNetworkUnavailable = true) precisa bloquear o agendamento hostNetwork = false pods
2. Plug-ins de rede - se o plug-in ainda não estiver pronto, será necessário bloquear a programação de pods hostNetwork = false. Este é separado de NodeNetworkUnavailable porque o plug-in pode não ter interação direta com um Routes Controller porque não depende de rotas de nuvem. Por exemplo, o kubenet pode ser usado localmente no nó se você tiver outra coisa (rotas de nuvem, flanela, etc) para configurar rotas de nó.
3. hostNetwork = true pods deve ignorar todas essas condições e ser programados, mas sujeito a quaisquer outras condições aplicáveis ​​(espaço em disco etc.)

NodeReady é um martelo muito grande. Estou pensando que provavelmente queremos uma condição NetworkPluginReady adicional para a prontidão do plug-in de rede (separada da prontidão de rotas de nuvem!) E então temos que direcionar isso para lugares que se importam :( Ou, realmente, novas impurezas, não condições.

Outra solução que encontrei.

Enquanto o kubeadm continua imprimindo '[apiclient] O primeiro nó foi registrado, mas ainda não está pronto', implantei 'kube-flannel.yml', que instala o flanneld. E funcionou sem alterar os arquivos de configuração.

1) kubeadm init --pod-network-cidr = 10.244.0.0 / 16 &
2) cp /etc/kubernetes/admin.conf ~ / .kube / config
3) kubectl apply -f kube-flannel-rbac.yml (necessário no kubeadm 1.6)
4) kubectl apply -f kube-flannel.yaml
Use kube-flannel.yaml em https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

Eu poderia tornar o nó mestre 'Pronto'. Mas, kube-dns falhou com a mensagem,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

Depois de alterar o plug-in de rede para weave-net, funcionou.

@dcbw Não sei o suficiente sobre o problema específico discutido nesta edição para dizer exatamente o que fazer. Eu só queria explicar o status atual das impurezas e como elas podem se aplicar aqui.

TESTE AS DEBS COM REMENDAS

O kubernetes-xenial-unstable agora tem uma compilação corrigida 1.6.1-beta.0.5+d8a384c1c5e35d-00 que @pipejakob e eu estamos testando hoje. Os nós não permanecem prontos até que uma rede de pod seja criada (por exemplo, aplicando configurações de tecer / flanela). Aprovação no teste de conformidade. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

É a direção geral de que as manchas podem expressar quase tudo
as condições podem e são, portanto, melhores em todos os sentidos?

Concordo que precisamos de um sinal mais granular. Ainda precisamos resolver o
interação entre kubelet, driver de rede, controlador de nuvem e provedor de nuvem
para desbloquear pods hostNetwork = false, mas hostNetwork = true não deve ser
bloqueado.

Em quinta-feira, 30 de março de 2017 às 19h24, Dan Williams [email protected]
escreveu:

Observe que se você deseja que o seu novo defeito substitua o atual automático
filtragem de nós com NetworkUnavailable, você precisará modificar o
função que mencionei anteriormente (ou seja, removê-la do conjunto de condições
que filtram um nó). Eu não sei quais outros efeitos colaterais
tem, uma vez que essa função pode ser usada em listas de nós que não sejam apenas
Agendador.

@davidopp https://github.com/davidopp precisamos ter cuidado com
NetworkUnavailable vs. NodeReady. Existem duas condições distintas que
realmente deve ser limpo:

nodeNetworkUnavailable - isso é específico para rotas de nuvem, e apenas nuvem
controladores de rota eliminam esta condição quando as rotas de nuvem entre os nós têm
foi configurado. Plug-ins de rede que criam sobreposições ou que não fazem L3
o roteamento entre os nós não deseja ou usa esta condição. Esta condição é
não adicionado por nenhum plugin de rede; é adicionado pelo kubelet especificamente quando
GCE ou AWS são selecionados como provedores de nuvem. Não afeta o NodeReady desde
é uma condição separada.

NodeReady - afetado diretamente pelos plug-ins de rede (por exemplo, CNI ou kubenet
ou tempos de execução remotos como dockershim / CRI-O).

Existem três questões distintas a serem consideradas:

1. Rotas de nuvem - se a infraestrutura de nuvem e o plug-in de rede
   exigem rotas de nuvem e, em seguida, falta de rotas de nuvem (por exemplo,
   NodeNetworkUnavailable = true) precisa bloquear o agendamento hostNetwork = false
   vagens
2. Plug-ins de rede - se o plug-in ainda não estiver pronto, ele precisa
   bloquear a programação de hostNetwork = false pods
3. hostNetwork = true pods deve ignorar todas essas condições e ser
   programado, mas sujeito a quaisquer outras condições aplicáveis ​​(espaço em disco, etc)

NodeReady é um martelo muito grande. Estou pensando que provavelmente queremos um
condição NetworkPluginReady adicional para a prontidão do plug-in de rede
(separado da prontidão das rotas da nuvem!) e então temos que sondar isso
para lugares que importam :(

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Para quem ainda está tentando a correção temporária removendo a linha de configuração kubelet KUBELET_NETWORK_ARGS, @ jc1arke encontrou uma solução mais simples - tenha duas sessões para o novo mestre e, enquanto espera que o primeiro nó esteja pronto, aplique uma configuração de rede de nó no segundo sessão:
Primeira sessão após executar kubeadmin init:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[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
...

Segunda sessão (usando Calico. Sua escolha pode variar, é claro):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Voltar para a primeira sessão:

...
[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 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

É a direção geral de que as manchas podem expressar quase tudo
as condições podem e são, portanto, melhores em todos os sentidos?

Bastante. Provavelmente, não podemos nos livrar de nenhuma das condições do nó devido a questões de compatibilidade com versões anteriores, mas podemos nos livrar de toda a lógica no mestre que executa ações com base nelas (como bloquear o agendamento ou expulsar pods). Além de tornar o comportamento mais óbvio (não há necessidade de memorizar quais condições bloqueiam o agendamento, quais causam despejo, quanto tempo esperamos pelo despejo, etc.), a reação às condições é configurável por pod.

Acabei de testar os debs de @mikedanese e @pipejakob , eles estão funcionando bem.

Testado em ubuntu / xenial:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Acabei de testar os debs de @mikedanese e @pipejakob , ainda congelou em
[apiclient] Created API client, waiting for the control plane to become ready

Esperei cerca de cinco minutos, mas nada mudou.
E ontem continuou repetindo
[apiclient] First node has registered, but is not ready yet

TTI acha que o problema ainda não tem solução?

Testado no Ubuntu 16.04:
kubeadm version: version.Info {Major: "1", Minor: "6+", GitVersion: "v1.6.1-beta.0.5 + d8a384c1c5e35d", GitCommit: "d8a384c1c5e35d5118f79808deb7bab41f3f7964Date", GitTree "2017", Git " -03-31T04: 20: 36Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

@ myqq0000 você pode postar a versão que está usando?

kubeadm version

@coeki Oh, esqueci. Acabei de editar e postar a versão em meu comentário anterior. :)

@mikedanese Você tem algum plano para atualizar o centos yum repo? Ou já está implantado no yum repo?

Tentei 1.6.1-beta.0.5+d8a384c1c5e35d-00 (o 1.6.1-beta.0.5+48c6a53cf4ff7d-00 mencionado em https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 parece não existir).

Parece funcionar bem.
Não relacionado: observe que se você estiver usando o weave, deverá aplicar https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml em vez do https 'padrão'

@mausch Você poderia me dizer como conseguir esses debs?

@ srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

@mikedanese debs corrigidos funcionam para mim. obrigado por todos trabalharem nisso! :sorriso:

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Obrigado. Eles trabalham para mim também com o provedor de rede da weave.

Alguma chance de construir a mesma correção para Centos também? Nosso sistema de portas usa principalmente centos para base de cluster de kubernetes. Se eu tiver a versão centos posso garantir aprox. 100 execuções de kubeadm init por dia como teste.

Os debs corrigidos do úteis para mim. kubeadm está notificando que o cluster está pronto, mas o nó em si não está.

Os nós kubectl apply -f https://git.io/weave-kube-1.6

No meu ambiente de teste (em vagrant, baseado em máquinas centos / 7), o kubeadm simplesmente trava. Usando o strace, posso vê-lo tentando se conectar ao servidor kubelet no mestre e fazendo loops de repetição FUTEX_WAIT e epoll_wait. Mas não há nenhuma saída de linha única vindo dele.

O kubelet falha ao iniciar, o que parece ser o motivo.
(Mas não consigo ver razões para o kublet não arrancar ..)

É este o problema deste problema?

Recebo binários do http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 repo.
Também tento atualizar os binários de https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> Onde posso obter uma versão corrigida do kubeadm para teste? <==

Observação: encontrei uma (reivindicada) versão corrigida do kubeadm referenciada neste problema em https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (a versão corrigida é esta: https: // heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), mas isso não funciona para mim. O comportamento ainda é o mesmo (sem saída alguma) ...

@ squall0gd Você pode nos mostrar a mensagem exata que está vendo? Com base no que você descreve, eu me pergunto se você realmente escolheu o novo .debs ou estava usando versões em cache mais antigas.

@thockin @davidopp, então, de acordo com a sugestão de Tim, vou requisitar um problema existente ou arquivar um novo para rastrear condições de prontidão de rede desemaranhadas e convertê-los todos em contaminações em vez de condições reais, e copiar na maior parte do https: // github. com / kubernetes / kubernetes / issues / 43815 # issuecomment -290597988 nele.

Aqui está o que parece estar funcionando para mim com o repo unstable (testei apenas o próprio mestre):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Isso realmente cuspiu error: taint "dedicated:" not found em um ponto, mas parece continuar independentemente.

Não executamos esses testes no branch 1.6?

@davidopp As condições do nó têm como objetivo fornecer informações adicionais para humanos, para entender o que está acontecendo, como o motivo, a mensagem e o tempo de transição.

Parece que o kubeadm não foi testado no branch de lançamento:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 aparentemente os testes kubeadm e2e foram desativados / não funcionais por cerca de uma semana antes do lançamento 1.6, IIRC

As condições do nó têm como objetivo fornecer informações adicionais para os humanos, para entender o que está acontecendo, como o motivo, a mensagem e o tempo de transição.

@ bgrant0607 destinam-se principalmente a informações humanas ou isso é apenas um efeito colateral feliz? Se principalmente para humanos, eles devem ser usados ​​para agendar decisões como são atualmente ou devemos nos afastar disso?

As manchas @dcbw têm o objetivo de se tornar o GUT da não programabilidade e da interrupção. Eventualmente, o planejador deve ignorar as condições.

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

Observe que se vamos adicionar uma contaminação aos nós, precisamos considerar

a) Compatibilidade com versões anteriores, como com a contaminação mestre: https://github.com/kubernetes/kubernetes/pull/43537

b) Desvio de versão. Ao atualizar clusters para 1.6, os kubelets serão de versões mistas e alguns podem ser tão antigos quanto 1.4.

então, para recapitular ou enquanto eu analiso isso:

baseado em @dcbw

nodeNetworkUnavailable é um provedor de nuvem, não vinculado ao kubeadm atm, podemos nos deparar com isso.

Mas o NodeReady, que é a causa raiz do loop, precisa ser mais granular. Isso é o que @davidopp quer ser uma contaminação, com base em uma lista que está marcando caixas, em relação à sonda / vivacidade, CNI pronto e etc.

bem, embora você possa argumentar, por que não rotular?

Mas @dcbw você achou um tópico mais adequado para esta discussão? Porque este se torna um balde para problemas de implantação e não realmente a raiz das coisas.

Eu sei, eu fiz parte de não chegar ao problema e postar hacks em torno dele :)

De qualquer forma, devemos discutir os fundamentos em outro lugar, garantir que um ETA on fix seja colocado aqui e seguir em frente.

Não sendo mal-humorado, mas bem :)

PS sim @ bgrant0607 deveríamos ter testado mais isso
PS2 Se eu ver isso errado, você pode me culpar;)

@coeki Eu também adicionaria uma solicitação para que as versões N-1 sejam mantidas em

@ kfox1111 gating também é um problema .... precisamos de uma estratégia melhor para isso :)

Por que deletar versões antigas? Isso poderia facilmente quebrar a automação das pessoas e impedir instalações repetidas.

As condições do nó têm como objetivo fornecer informações adicionais para os humanos, para entender o que está acontecendo, como o motivo, a mensagem e o tempo de transição.

Concordou. UX é definitivamente um dos principais motivos pelos quais provavelmente não podemos nos livrar das condições dos nós. No entanto, acredito que podemos nos livrar de todos os usos de condições de nó como um gatilho para ações mestras (como despejo e programação de bloqueio) e usar taints para isso.

No longo prazo (como a API v2 de longo prazo), é concebível que pudéssemos adicionar razão e mensagem às manchas e, em seguida, nos livrar das condições dos nós, mas eu realmente não pensei sobre isso e definitivamente não estou propondo formalmente fazer isso. (Já temos o equivalente ao tempo de transição em uma direção, ou seja, TimeAdded.)

@coeki não, o que eu estava falando não tem nada a ver com portas. Gating não pode encontrar todos os problemas, a menos que você tenha um portão que testa tudo o que poderia ser feito. Os operadores gostam de fazer coisas estranhas em seus ambientes. :) Proibitivamente caro para testar todas as coisas possíveis.

Estou pedindo para não excluir a versão antiga antes que a nova tenha feito pelo menos a primeira versão de correção de bugs. Para este exemplo, 1.6.1. No mínimo. Manter versões mais antigas é ainda melhor. Esta é uma prática recomendada para permitir que os operadores continuem a fazer progresso enquanto os bugs na nova versão são resolvidos.

@ kfox1111 , é isso que o gating faz, não

@davidopp Eu concordo que rótulos e manchas podem ter uma distinção diferente de uma forma de API de olhar para isso, UX e maquinário, mas está difuso agora. Eu também :)

De qualquer forma, você me atraiu para uma discussão, nós realmente não deveríamos ter nessa questão, esse foi o meu ponto.

Gostaria de perguntar novamente: se eu vir "kubeadm init" pendurado ali sem saída (tentando conectar ao servidor kubelet, que não conseguiu iniciar), estou sofrendo desse problema? E se for esse o caso, # 43835 é uma solução para mim?

Onde posso obter:

• qualquer uma das versões mais antigas (anteriores a 1.6.0) de kubeadm / kubectl / kubelet
• ou uma versão corrigida do kubeadm (incluindo # 43835 ou qualquer outra correção)?

Obrigado!

(nota: a versão corrigida do kubeadm referenciada no commit mencionado acima não funciona para mim ...)

@obnoxxx tente a dica do branch release-1.6.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese thanks! tentando...

Se você executar o kubeadm sem instalar o pacote do sistema operacional, você precisa

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

de https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese thanks. Estou instalando o pacote os (do kube repo) e depois instalando os binários do url da web sobre os binários do rpms ...

a versão 1.6.1-beta.0.12 não funcionou para mim:
kubeadm init ainda trava sem qualquer saída. (tentando conectar ao kubelet)

Não se esqueça do driver systemd também se estiver centos.

driver do sistema?

https://github.com/kubernetes/release/issues/306

nossa, obrigado, assim é melhor! :-)

@pipejakob Não tenho acesso a esses logs no momento, mas verifiquei a versão do kubeadm e era a mesma versão que o @webwurst tem. Além disso, verifiquei as possíveis kubeadm versões com apt-cache policy kubeadm . E havia apenas uma entrada - de kubernetes-xenial-unstable.
@mikedanese , tentei com flanela antes de postar;)
EDIT: Eu reconstruí a plataforma inteira e kubadm está funcionando bem: +1:

Pessoal, qual é o status quo para a correção? ele vai mudar para o repositório estável em breve?

Os debs com patch do

Alguém pode me dizer como construir uma versão corrigida do kubeadm para rhel (rpm)?

@mikedanese com debs corrigidos, o init relata sucesso, mas a mensagem "plugin de rede não está pronto: cni config uninitialized" persiste.

O nó mestre está em NotReady .

O weave-net (weaveworks / weave-kube: 1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) está em 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

O pod kube-dns está em 0/3 Pending .

@ChipmunkV Você provavelmente precisa configurar o kube-proxy para ser executado no espaço do usuário. Isso também tem sido um problema no 1.5.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Se valer a pena, kubernetes-xenial-unstable está funcionando bem para mim.

@pstadler , obrigado a @errordeveloper no bate-papo que apontou que tenho redes sobrepostas, reconfigurei IPALLOC_RANGE na trama.

Obrigado @thenayr. Eu poderia abrir o mestre Kubernetes, mas também poderia conectar um trabalhador a ele usando junção kubeadm. Postará mais atualizações em breve

@mikedanese , demorei uma eternidade para descobrir qual versão usar, até que li todos os comentários aqui. Nós realmente precisamos tornar muito mais fácil encontrar binários para uma determinada versão. Eu tentei usar o que ci-cross/latest.txt aponta (ou seja, v1.7.0-alpha.0.1982+70684584beeb0c ), e isso introduziu a nova bandeira kube-apiserver (ou seja, --proxy-client-key-file em d8be13fee85075abfc087632b3dbc586a10897ad), que não funciona com nenhuma das tags recentes em gcr.io/google_containers/kube-apiserver-amd64 ...

Como podemos tornar mais fácil descobrir quais revisões têm binários no intervalo? Ser capaz de listar diretórios seria bom, ou ter um arquivo de mapa simples ou qualquer coisa que não requeira saber ou adivinhar.

@errordeveloper estamos tentando fazer um lançamento para que possamos empurrar uma correção para o branch estável, deve ser feito em O (dias), espero. Há um link na descrição desse problema para os debs corrigidos na instável.

A versão anterior 1.5.6 estava funcionando para mim no CentOs 7, mas agora não consigo nem reverter porque a única versão do kubeadm em http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 é o 1.6 quebrado. 0 Alguma sugestão sobre como obter o Kubeadm 1.5.6 RPM?

Na verdade, é uma pena. As versões antigas parecem ter sido totalmente removidas. :-(

Meus resultados são estes no centos 7:

• Não consegui fazer com que o kubadm init me desse qualquer resultado, mesmo com um kubeadm atualizado e mais recente, sem fazer algo sobre o kubectl.
• Consegui fazer o kubectl começar com as instruções de @coeki e, em seguida, o kubeadm foi aprovado. Mas depois disso, nada funciona para mim. kubectl diz

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Alguma dica do que está acontecendo?

@obnoxxx por padrão, o apiserver não escuta no 8080, ele escuta na porta 6443 segura, você pode verificar com netstat -tunlp.
Você precisa copiar admin.conf de / etc / kubernetes para você $ HOME / .kube / config
certifique-se de alterar as permissões no arquivo em $ HOME / .kube /, depois disso, seu kubectl deverá ser capaz de entrar em contato com apiserver corretamente. HTH. Serguei

@apsinha Conhece esse tópico? Pode ser bom ter alguns produtos acompanhando, pois acho que haverá algumas lições importantes para o futuro.

Em cima da minha cabeça:

• 1.6.0 nunca passou por testes automatizados: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Binários / pacotes para versões mais antigas foram removidos, então as pessoas não podem reverter com segurança; interrompeu qualquer automação de instalação que presumia que continuassem disponíveis: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Nenhum anúncio público (que eu vi) de que isso está quebrado
• Nenhum cronograma fornecido sobre uma correção (eu sou um desenvolvedor, então eu sei o quão desagradável ser perguntado "quando será corrigido?" É, mas mesmo assim, as pessoas perguntarão isso, então é bom oferecer pelo menos um período de tempo estimado)
• Os usuários que continuam a entrar na conversa ficam confusos sobre o status das coisas, soluções alternativas e cronograma de correção
• Muita discussão técnica entre os contribuidores, muitos dos quais são sobre estratégia de longo prazo, combinados no mesmo segmento de usuários tentando descobrir o que está acontecendo e como lidar com o problema imediato

Sem desrespeito a todas as grandes pessoas que fazem do Kubernetes o que ele é. Só espero que haja alguns "momentos ensináveis" daqui para frente, pois isso parece ruim em termos da percepção pública de que o Kubernetes é confiável / estável. (Concedido, o kubeadm é alfa / beta, mas ainda tem muita visibilidade.)

Eu construí o kubeadm-1.5.6 usando kubernetes / release.rpm apenas para descobrir (para minha consternação) que

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone você precisa ajustar o .spec aqui .

@sbezverk obrigado pela dica! É melhor agora...

Isso é curioso:

• Não me lembro de copiar o admin.conf era necessário para mim em versões anteriores.
• Eu tentei com kubectl -s localhost:6443 antes, mas não foi suficiente.

De qualquer forma, agora posso continuar. obrigado novamente

v1.6.1 está em processo de lançamento. Isso será feito por EOD.

Algumas notas:

1. O problema com pacotes antigos sendo excluídos foi rastreado aqui: https://github.com/kubernetes/release/issues/234. Devido a algumas versões malucas do kubeadm e como essas coisas são classificadas em ordem alfabética, aparentemente não foi possível manter a versão 1.5.x do kubeadm no repo. ( @bostone, seu problema também é referenciado lá)
2. teste kubeadm e2e em PRs sendo rastreados aqui: https://github.com/kubernetes/kubeadm/issues/190
3. Quanto ao anúncio público - postei no twitter, mas dificilmente é oficial. Não está claro quais são os canais corretos para problemas críticos como este.

Todas essas são boas questões para abordar em um PM. @pipejakob gentilmente se ofereceu para resolver o problema pós-morte.

@obnoxxx O requisito para copiar / chown o admin.conf era necessário antes porque com 1.5 tínhamos o servidor API expondo uma porta insegura. Mudamos isso no 1.6. Agora você deve usar credenciais seguras para acessar o servidor API (consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese isso parece ótimo, obrigado!
Eu sou apenas um manequim - qual será o efeito desta versão 1.6.1 com relação a este problema?
O kubelet iniciará sem a alteração para /etc/systemd/system/kubelet.service.d/10-kubeadm.conf (solução alternativa de @coeki ) ou conterá a correção de # 43835 (que não pareceu ter nenhum efeito para mim)?

@jbeda obrigado pela explicação!

@jbeda Acho que a confusão vem do documento de instalação oficial do kubadm configurando o repositório YUM para http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. Esse repo tem apenas kubeadm-1.6.0

E novamente, para minha decepção, construir 1.5.6 rpms e instalar acabou com o mesmo problema exato. Executando kubeadm init está pendurado na mesma linha:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Acho que vou apenas esperar pelo lançamento 1.6.1 e torcer ...

1.6.1 está fora.

@mikedanese você testou o kubeadm antes de fechar este bug? No momento, estou encarando [apiclient] Created API client, waiting for the control plane to become ready há 10 minutos. No CentOS 7 com nova instalação 1.6.1

@bostone, você pode estar tendo este problema: # 43805

Tente editar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e adicionar --cgroup-driver=systemd

Lembre-se de executar systemctl daemon-reload; systemctl restart kubelet

@gtirloni com nossa sugestão, cheguei ao final de kubeadm init porém qualquer tentativa de executar o kubectl produz este erro: The connection to the server localhost:8080 was refused - did you specify the right host or port? Não tenho certeza de onde e como alterar isso ou qual é a porta correta em este ponto?

Não tenho certeza se isso está relacionado, mas aqui está o que vejo ao executar systemctl status kubelet :
`` `systemctl status kubelet -l
● kubelet.service - kubelet: o agente de nó do Kubernetes
Carregado: carregado (/etc/systemd/system/kubelet.service; ativado; predefinição do fornecedor: desativado)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Ativo: ativo (em execução) desde Seg. 03-04-2017 17:31:07 PDT; 11min atrás
Docs: http://kubernetes.io/docs/
PID principal: 10382 (kubelet)
CGroup: /system.slice/kubelet.service
├─10382 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --allow-privileged = true - -network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorization-mode = Webhook --client-ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = systemd
└─10436 journalctl -k -f

03 de abril 17:41:56 sdl02269 kubelet [10382]: W0403 17: 41: 56.645299 10382 cni.go: 157] Não é possível atualizar a configuração cni: nenhuma rede encontrada em /etc/cni/net.d
03 de abril 17:41:56 sdl02269 kubelet [10382]: E0403 17: 41: 56.645407 10382 kubelet.go: 2067] 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```

Sim, nós testamos. Os testes e2e estão passando no ramo de lançamento. Você pode estar encontrando outros problemas.

@bostone talvez você esteja perdendo essas etapas após kubeadm init ?

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

Você também precisa seguir a etapa 3 descrita aqui . Isso parece estar relacionado ao erro de configuração de cni que você está recebendo.

Também olhando para [apiclient] Cliente API criado, esperando que o plano de controle esteja pronto por 10 minutos já com o Ubuntu 16.04 e uma nova instalação do 1.6.1

@pingthings, eu recomendo ingressar no Slack Kubernetes e no canal kubeadm . Podemos ajudá-lo a depurar lá.

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-advertise-endereços, você precisa usar --apiserver-advertise-address.
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.

Isso não parece estar resolvido (Ubuntu LTS, kubeadm 1.6.1).

Primeiro, também experimentei kubeadm pendurado em "Cliente API criado, esperando o plano de controle ficar pronto" ao usar a bandeira --apiserver-advertise-address .. Os logs de diário dizem:

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Se eu não fornecer esse sinalizador, o kubeadm é aprovado, mas mesmo assim recebo o seguinte erro para o início do kubelet:

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

Kubelet se recusa a iniciar corretamente e não consigo me conectar ao cluster com kubectl forma alguma

Parece que as versões 1.5.x do kubeadm foram removidas não apenas do repositório centos, mas também do Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It torna difícil fazer o downgrade e, na verdade, quebra a compatibilidade com versões anteriores

@bostone

Você descobriu o truque em "esperar o avião de controle ficar pronto"? Vejo a mesma coisa depois de tentar todas as alterações com 1.6.1.

@gtirloni @srzjulio adicionar estes passos depois de kubeadm init não ajudou. Ele fez o serviço kubelet mudar de failed para active (running) mas ainda tenho a mensagem The connection to the server localhost:8080 was refused - did you specify the right host or port? . E se eu olhar para os serviços ouvindo, não consigo ver 8080 em lugar nenhum. O que posso ver é que o kubelet está escutando nestas portas:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Portanto, há alguma configuração errada (alterada?) Que aponta erroneamente para 8080?

@bostone , não é a porta kubelet que você precisa, é kube-apiserver, deve estar escutando na porta 6443.

@sbezverk Eu não modifiquei nenhum padrão no que diz respeito às portas (não está nas instruções) O que eu preciso fazer para mudar de 8080 para 6443?

@bostone se você não modificou nada no manifesto do apiserver, por padrão ele escutará na porta 6443. Você só precisa copiar /etc/kubernetes/admin.conf em $ HOME / .kube / config, alterar as permissões no arquivo de configuração e estará tudo pronto.

@sbezverk BTW - Estou executando todas as etapas de instalação como root, mas essas 3 linhas de instrução da saída kubeadm init sugerem o uso do usuário sudo. Qual é a recomendação sobre isso? Deve executar todas as etapas de instalação como um sudo também?

Ok, fiz todas as etapas do zero e parece que está melhor. Aqui estão as etapas que funcionaram para mim até agora e estou executando como root no CentOS 7.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Adicione -cgroup-driver=systemd a 10-kubeadm.conf e salve

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

Neste ponto, posso executar kubectl get nodes e ver meu nó mestre na lista.
Repita todas as etapas para o minion, exceto kubeadm init e, em vez disso, execute kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 conforme gerado por kubeadm init
Esta etapa é concluída e posso ver os nós de mestre e servo (s)

E agora - o problema:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

Portanto, parece que os nós nunca estão prontos. Alguma sugestão?

Imagino que sua trama não esteja sendo implantada corretamente porque você está usando o
arquivo yaml pré-1.6.

Tente "kubectl apply -f https://git.io/weave-kube-1.6 "

Na terça-feira, 4 de abril de 2017 às 12h24, Bo Stone [email protected] escreveu:

Ok, fiz todas as etapas do zero e parece que está melhor. Aqui estão
as etapas que funcionaram para mim até agora e estou executando como root.

gato <

[kubernetes]
nome = Kubernetes
baseurl = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
habilitado = 1
gpgcheck = 1
repo_gpgcheck = 1
gpgkey = https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Adicione -cgroup-driver = systemd a 10-kubeadm.conf e salve

systemctl enable docker && systemctl start docker

systemctl enable kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables = 1

systemctl stop firewalld; systemctl disable firewalld

kubeadm init

cp /etc/kubernetes/admin.conf $ HOME /

chown $ (id -u): $ (id -g) $ HOME / admin.conf

exportar KUBECONFIG = $ HOME / admin.conf

kubectl apply -f https://git.io/weave-kube

Neste ponto, posso executar kubectl get nodes e ver meu nó mestre no
Lista.
Repita todas as etapas para o minion, exceto, é claro, executando o kubeadm join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 conforme gerado pelo kubeadm
iniciar
Esta etapa é concluída e posso ver os nós de mestre e servo (s)

E agora - o problema:

kubectl get nodes

NOME STATUS IDADE VERSÃO
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1

kubectl describe node abc02918

Eventos:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet, sdl02918 Normal Iniciando o kubelet.
43m 43m 1 kubelet, sdl02918 Aviso ImageGCFailed incapaz de encontrar dados para o contêiner /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk O status do nó sdl02918 é agora: NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 NodeHasSufficientMemory normal Node sdl02918 status agora é: NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 NodeHasNoDiskPressure normal Node sdl02918 agora é: NodeHasNoDiskPressure
42m 42m 1 kube-proxy, sdl02918 Normal Iniciando Kube-proxy.

Portanto, parece que os nós nunca estão prontos. Alguma sugestão?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

Usando o CentOS e a versão 1.6.1-1 do kubeadm, e seguindo as etapas acima, obtenho um comportamento um pouco diferente: o cluster é relatado como pronto, mas eu fico preso nesta mensagem:

[apiclient] Temporarily unable to list nodes (will retry)

Nos registros, porém, ainda temos o mesmo erro:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning É isso aí! Ainda preciso implantar algumas imagens para ver se tudo funciona, mas posso ver todos os nós com o status Ready ! Obrigado a todos, pessoal (por agora :)

@bostone Eu segui a mesma receita que você usou, mas obtive resultados diferentes - não passei do kubeadm init. Qual versão do docker você está usando? talvez seja essa a diferença no meu caso?

@dcowden É tudo o que o yum escolhe no meu sistema Docker version 1.12.6, build 96d83a5/1.12.6 . Além disso, o que me ajudou foi reprovisionar todas as VMs que eu estava usando em vez de tentar consertar em cima das minhas instalações anteriores

@bostone obrigado. Vou fazer o downgrade para essa versão para ver se consigo uma configuração funcional. no meu sistema, o mais recente é uma versão estranha 17.03.1.ce (evidentemente, o melhor mais recente)

Não tenho certeza se é geralmente útil, mas tenho um manual do ansible que
faz todas as etapas para CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, mas pelo menos documenta o processo. Eu também faço algumas coisas como
alterne o docker para usar o registro de arquivo json e o armazenamento de sobreposição.

Pode ser útil como referência, mesmo se você não executar o manual.

Na terça-feira, 4 de abril de 2017 às 12h55, Dave Cowden [email protected]
escreveu:

@bostone https://github.com/bostone obrigado. eu vou fazer o downgrade para isso
versão para ver se consigo uma configuração de trabalho. no meu sistema o mais recente é um
versão estranha 17.03.1.ce (evidentemente, a melhor mais recente)

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning Obrigado! isso é muito útil!

Ok, aqui está uma complicação. após executar kubeadm reset no mestre e no minion e reiniciar os serviços docker e kubelet kubeadm init trava em Created API client, waiting for the control plane to become ready mais uma vez. Alguém pode fornecer etapas completas para redefinir o kubeadm?
@sjenning , você tentou executar novamente seu manual depois de executá-lo inicialmente?

@bostone, no meu caso, mover /var/lib/etcd/ resolveu o problema.

@autostatic o diretório estava vazio e renomeá-lo não ajudou. @sjenning seu playbook trava, criei um tíquete para você

Alguém tentou executar o painel na v1.6.1? Estou recebendo um erro que afirma o seguinte:

`Proibido (403)

O usuário " system: serviceaccount : kube- system: default " não pode listar namespaces no escopo do cluster. (obter namespaces)
`

Acho que preciso configurar mais RBAC, como você precisa para executar Flannel?

@srzjulio Você pode registrar uma nova edição para isso? Meu palpite é que o SIG Auth e a equipe do Dashboard deveriam trabalhar juntos. Provavelmente é uma mudança simples no YAML.

@srzjulio, você precisa atualizar as regras RBAC, nós as usamos para começar:

apiVersion: rbac.authorization.k8s.io/v1alpha1
kind: ClusterRoleBinding
metadados:
nome: cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
tipo: ClusterRole
nome: cluster-admin
assuntos:

• tipo: Grupo
  nome: sistema: masters
• tipo: Grupo
  nome: sistema: autenticado
• tipo: Grupo
  nome: sistema: não autenticado

Seja cuidadoso - a ligação que @sbezverk possui basicamente desativa o RBAC. Você terá um cluster superinseguro se fizer isso.

kind: Group
name: system:unauthenticated

Isso é particularmente ruim. Isso significa que qualquer pessoa que puder entrar em contato com seu servidor API, mesmo sem nenhuma credencial, pode executar comandos arbitrários.

@jbeda ele corresponde ao comportamento que tínhamos com 1.5.6 direto da caixa. Ele dá às pessoas a oportunidade de revisar e ajustar gradualmente a configuração de segurança, em vez de serem incapazes de fazer qualquer coisa com as novas regras de segurança.

Na verdade, tornar o sistema: não autenticado um administrador de cluster é muito pior do que 1.5.6

Se você não quiser autorização, use o autorizador AlwaysAllow

Se você quiser permitir tudo durante a auditoria, use uma combinação de RBAC, AlwaysAllow

Isso desabilitará solicitações anônimas, registrará negações de RBAC no log do servidor de API, mas continuará permitindo que todas as solicitações autenticadas façam o que quiserem

Desculpe, e eu repito isso novamente, isso não tem nada a ver com o problema original. E embora problemas e questões válidos, devemos mover a conversa para outro lugar.

Mais uma vez, desculpe, pressione Enter muito cedo, mas do jeito que as coisas estão:

1 - versão 1.6.0 causa problemas
2 - não são todos fixos
3 - passando para RBAC (bom na minha opinião) mas é um problema, por quê? ver ponto 4
4 - Isso não foi muito bem comunicado, e não há muitos documentos / blogs ou o que quer que seja para explicá-lo
5 - Eu me curvo a todas as pessoas que tentam salvar, mas precisamos de uma maneira melhor de fazer isso

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions é um bom guia para as opções mais granulares para abrir as permissões.

adicionar " --cgroup-driver = systemd " no kublet causa um novo problema no Centos / RHEL 7.3 (totalmente atualizado - também conhecido como docker 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

embora possamos ver claramente que native.cgroupdriver = systemd está definido no daemon docker:

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng por que você não atualiza o docker para 1.12.6? Funciona perfeitamente com esta versão.

@sbezverk : Acabei de atualizar para 1.12.5 e agora está funcionando! Muito Obrigado!

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 !

@sjenning @ReSearchITEng
Olá, tenho um manual do vagrant + ansible [0] muito semelhante ao que você criou, mas ainda não consigo fazê-lo funcionar, embora para mim esteja falhando na configuração da rede. Eu tentei com chita, tecido e flanela, e todos os três falharam (embora com sintomas diferentes).

Estou executando estas versões:
[ vagrant @ master ~] $ docker --version
Docker versão 1.12.6, compilação 3a094bd / 1.12.6
[ vagrant @ master ~] $ kubelet --version
Kubernetes v1.6.1
[ vagrant @ master ~] versão $ kubeadm
kubeadm version: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.1", GitCommit: "b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState: "clean", BuildDate: "2017-04-03T20: 33: 33: 27Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

erros:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Parece uma informação importante, mas não tenho certeza de como corrigi-lo:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Qualquer ajuda seria muito apreciada...

[0] - https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

Não consegui identificar o que há de errado com você.
Eu sugiro fortemente que você tente criar uma instalação separada usando os manuais aqui: https://github.com/ReSearchITEng/kubeadm-playbook e tente ver qual é a diferença.
PS: meus últimos testes são com 1.6.2, kube * e imagens e parece bom.

@kelseyhightower

@ReSearchITEng desculpe, esqueci de relatar, mas finalmente consegui fazer funcionar, meus arquivos vagrant + ansible estão aqui: https://github.com/thiagodasilva/kubernetes-swift

Eu também tive o mesmo problema, mas apenas copiei a configuração do cni no nó mestre para o local correspondente do nó de trabalho e, em seguida, tudo funcionou.

systemctl status kubelet.service -l

● kubelet.service - kubelet: o agente de nó do Kubernetes
Carregado: carregado (/etc/systemd/system/kubelet.service; ativado; predefinição do fornecedor: desativado)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Ativo: ativo (em execução) desde terça 06-06-2017 10:42:00 CST; 18min atrás
Docs: http://kubernetes.io/docs/
PID principal: 4414 (kubelet)
Memória: 43,0M
CGroup: /system.slice/kubelet.service
├─4414 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --network-plugin = cni - -cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorizatio -ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = cgroupfs
└─4493 journalctl -k -f

06 de junho 10:59:46 contiv1.com kubelet [4414]: W0606 10: 59: 46.215827 4414 cni.go: 157] Não é possível atualizar a configuração cni: nenhuma rede encontrada em /etc/cni/net.d
06 de junho 10:59:46 contiv1.com kubelet [4414]: E0606 10: 59: 46.215972 4414 kubelet.go: 2067] Rede de tempo de execução do contêiner não está pronta: NetworkReady = mensagem falsa pronta
06 de junho 10:59:51 contiv1.com kubelet [4414]: W0606 10: 59: 51.216843 4414 cni.go: 157] Não é possível atualizar a configuração cni: nenhuma rede encontrada em /etc/cni/net.d
06 de junho 10:59:51 contiv1.com kubelet [4414]: E0606 10: 59: 51.216942 4414 kubelet.go: 2067] Rede de tempo de execução do contêiner não está pronta: NetworkReady = mensagem falsa pronta
06 de junho 10:59:56 contiv1.com kubelet [4414]: W0606 10: 59: 56.217923 4414 cni.go: 157] Não é possível atualizar a configuração cni: nenhuma rede encontrada em /etc/cni/net.d
06 de junho 10:59:56 contiv1.com kubelet [4414]: E0606 10: 59: 56.218113 4414 kubelet.go: 2067] Rede de tempo de execução do contêiner não está pronta: NetworkReady = mensagem falsa pronta
06 de junho 11:00:01 contiv1.com kubelet [4414]: W0606 11: 00: 01.219251 4414 cni.go: 157] Não foi possível atualizar a configuração do cni: nenhuma rede encontrada em /etc/cni/net.d
Jun 06 11:00:01 contiv1.com kubelet [4414]: E0606 11: 00: 01.219382 4414 kubelet.go: 2067] Rede de tempo de execução do contêiner não está pronta: NetworkReady = mensagem falsa pronta
06 de junho 11:00:06 contiv1.com kubelet [4414]: W0606 11: 00: 06.220396 4414 cni.go: 157] Não foi possível atualizar a configuração do cni: nenhuma rede encontrada em /etc/cni/net.d
Jun 06 11:00:06 contiv1.com kubelet [4414]: E0606 11: 00: 06.220575 4414 kubelet.go: 2067] Rede de tempo de execução do contêiner não está pronta: NetworkReady = mensagem falsa pronta

O status de todos os nós:
[ root @ swarm net.d] # kubectl get node
NOME STATUS IDADE VERSÃO
contiv1.com Pronto 1h v1.6.4
contiv2.com Pronto 1h v1.6.4
swarm.com pronto 1h v1.6.4

Alguma resolução sobre isso? Não fui capaz de fazer isso mesmo depois de tentar todas as resoluções mencionadas.

Sendo novo na configuração do Kubernetes, fico muito confuso. Tentei seguir https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 que usa weave-kube para rede, mas também estou preso com o mesmo problema . Alguma maneira de resolver isso?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Por que isso ainda é um problema? Ubuntu 16.04 / CentOS 7.3 com as atualizações mais recentes usando os repositórios k8s oficiais com 1.6.4 e seguindo as etapas descritas aqui: https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen Não, isso afetou _apenas a v1.6.0_ . Espera-se que o kubelet não encontre uma rede, pois você não instalou nenhuma. Por exemplo, basta executar

kubectl apply -f https://git.io/weave-kube-1.6

para instalar o Weave Net e esses problemas irão embora. Você pode escolher instalar Flanela, Calico, Canal ou qualquer rede CNI se desejar

@luxas eu continuo vendo referências a isso, mas como devo aplicar algo a um cluster que não está funcionando? Não tenho nada para me conectar.

@drajen Acho que o ponto de @luxas é que este é o lugar errado para perguntar sobre a configuração.
Os vários guias de configuração o ajudarão a ultrapassar esse ponto - a etapa típica ausente nos guias mais antigos, que o luxas menciona de forma útil, em que você precisa aplicar uma configuração de rede antes que tudo comece a funcionar corretamente.

Sim, pode não ser óbvio e lamentamos por isso, mas também não podemos ter um único nome de provedor.

Conversado com @drajen no Slack e o problema estava relacionado ao cgroup, o kubelet não estava íntegro e não foi capaz de criar nenhum pod, daí o problema.

Agradeço a @luxas por https://github.com/kubernetes/kubeadm/issues/302

Ainda acertando isso no arch em 1.7, existe uma solução rápida em algum lugar?

Editar:

kubectl apply -f https://git.io/weave-kube-1.6

funcionou, parece que só precisávamos do CNI em execução

Pelo menos para CentOS / RHEL, certifique-se de atualizar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf e adicionar o sinalizador --cgroup-driver = "systemd"

Se você reinstalar novamente na mesma máquina, esta é uma reinicialização completa adequada:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(isso é necessário especialmente se você usar flanela)
Se você quiser fazer tudo em um, pode usar o projeto inteiro: https://github.com/ReSearchITEng/kubeadm-playbook/

Eu encontrei esse problema e absolutamente nada do que li acima funcionou. Então, tentei novamente com uma configuração muito mais controlada, mudando do Ubuntu para o CoreOS mais recente, indo para uma versão anterior do k8s para começar e, em geral, sendo muito anal sobre tudo o que é instalado em cada VM. NÃO estou usando o kubeadm, mas uma combinação de vagrant e ansible.

(por quê? porque eu não tinha ideia do que estava acontecendo no kubeadm e percebi dessa forma, pelo menos, eu teria controle e seria capaz de contornar quaisquer verificações de pré-vôo excessivamente zelosas, sem mencionar a sensação de que tinha mais controle de automação em geral, e também não ter que se preocupar com o aviso para do-not-apply-alpha-software-in-production.)

Quando tentei essa configuração com uma edição mais antiga (1.4.3) do k8s, essa abordagem foi perfeita. Em seguida, tentei atualizar para 1.71. Mais uma vez, AINDA estou encontrando o mesmo problema, apesar de não usar nenhum kubeadm.

Confirmei que estou executando chita em cada um dos meus nódulos, incluindo o Mestre e os três Trabalhadores em potencial. TODOS os meus nós estão relatando como NotReady, então não tenho certeza de como poderia aplicar a tecelagem (ou qualquer outra coisa) para fazê-lo funcionar.

Essa coisa toda parece galinha / ovo ... não é possível alocar um pod porque a rede está falhando, mas precisa da rede rodando para criar uma rede em /etc/cni/net.d a fim de poder alocar pods. E, novamente, tudo isso estava funcionando algumas horas atrás com o k8s 1.4.3. Estou muito frustrado!

Eu apreciaria qualquer ideia que alguém pudesse dar.

Notas de rodapé:

No mestre: journalctl -r -u kubelet me dá

24 de julho 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: E0724 00: 48: 16.592274 7647 kubelet.go: 2136] Rede de tempo de execução do contêiner não está pronta: NetworkReady = motivo falso mensagem: docker : plugin de rede não é
24 de julho 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: W0724 00: 48: 16.590588 7647 cni.go: 189] Não é possível atualizar a configuração do cni: nenhuma rede encontrada em / etc / cni / net .d

docker ps | grep calico

(truncado para facilitar a leitura)
cde ... quay.io/calico/ leader-elector @ sha256 : ... "/run.sh --election = c" 8 horas atrás Até 8 horas
f72 ... calico / kube-policy-controller @ sha256 : ... "/ dist / controller" 8 horas atrás Até 8 horas
c47 ... gcr.io/google_containers/pause-amd64:3.0 "/ pause" 8 horas atrás Até 8 horas

Não há /etc/cni/net.d

Da minha caixa kubectl:
kubectl get nodes
10.0.0.111 NotReady, SchedulingDisabled 8h v1.7.1 + coreos.0
10.0.0.121 NotReady 8h v1.7.1 + coreos.0
10.0.0.122 NotReady 8h v1.7.1 + coreos.0
10.0.0.123 NotReady 8h v1.7.1 + coreos.0

kubectl apply -f https://git.io/weave-kube-1.6

NÃO consertei nada e na verdade só parece criar mais problemas.

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl apply -f https://git.io/weave-kube-1.6
serviceaccount "weave-net" criada
clusterrolebinding "weave-net" criado
daemonset "weave-net" criado
Erro do servidor (Proibido): clusterroles.rbac.authorization.k8s.io "weave-net" é proibido: tentativa de conceder privilégios extras: [PolicyRule {Recursos: ["pods"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["pods"], APIGroups: [""], Verbos: ["list"]} PolicyRule {Recursos: ["pods"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["namespaces"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["namespaces"], APIGroups: [""], Verbos: ["list"]} PolicyRule {Recursos: ["namespaces"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["nodes"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["nodes"], APIGroups: [""], Verbos: ["list"]} PolicyRule {Recursos: ["nodes"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["get"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["list"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["watch"]}] user = & {kube-admin [sistema: a uthenticated] map []} ownerrules = [] ruleResolutionErrors = []

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl get pods --namespace = kube-system
NOME PRONTO STATUS REINICIA IDADE
kube-apiserver-10.0.0.111 1/1 Executando 1 8h
kube-controller-manager-10.0.0.111 1/1 Executando 1 8h
kube-dns-v20-fcl01 0/3 Pendente 0 8h
kube-proxy-10.0.0.111 1/1 Executando 1 8h
kube-proxy-10.0.0.121 1/1 Executando 1 8h
kube-proxy-10.0.0.122 1/1 Executando 1 8h
kube-proxy-10.0.0.123 1/1 Executando 1 8h
kube-scheduler-10.0.0.111 1/1 Executando 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 Pendente 0 8h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 Running 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

Uma investigação mais aprofundada dos erros de tecelagem indica que eles (a) não podem se conectar ao apiserver, ou então (b) no caso daquele marcado como "Executando", ele está reclamando que não pode se conectar a si mesmo.

@billmilligan Tendo problemas semelhantes, o dns para de funcionar poucos minutos após o contêiner ter iniciado

@Paxa @billmilligan Se você deseja obter ajuda, não comente sobre este problema. Em vez disso, abra novos no repo kubeadm com detalhes suficientes solicitados.

@luxas Respeitosamente, tenho que questionar se esse é um problema novo. Como estou obtendo o mesmo resultado com a configuração do k8s sem kubeadm que todos os outros estão obtendo com o kubeadm, isso parece eliminar o kubeadm como a origem do problema. Talvez esta questão deva ser renomeada de acordo?

@billmilligan respeitosamente, já que o problema é sobre o kubeadm e você pode reproduzi-lo sem o kubeadm, este é o lugar errado para arquivá-lo? Acho que este tópico resolveu o problema do kubeadm. Este é um novo problema. Acho que vai receber mais atenção como um novo problema. Como as pessoas neste tópico pensam que já está resolvido e o estão ignorando.

Eu uso o kubeadm e fui afetado por esse problema, que foi resolvido desde 1.6.1. Implantei perdas de k8s desde então, então realmente acho que você tem um problema separado.

@ kfox1111 Obrigado pelo feedback. Vou registrar um novo problema, mas o número de pessoas que ainda parecem estar enfrentando isso em outro lugar no 1.7.x ainda me faz pensar.

TL; DR;

A mensagem de erro

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

NÃO é necessariamente ruim.

Essa mensagem de erro informa que você precisa fazer o plug-in em um provedor de implementação de especificações CNI de terceiros .

O que é CNI e como se integra ao Kubernetes?

CNI significa Container Network Interface e define uma especificação que o kubelet usa para criar uma rede para o cluster. Consulte esta página para mais informações sobre como o Kubernetes usa a especificação CNI para criar uma rede para o cluster.

O Kubernetes não se importa como a rede é criada, desde que atenda à especificação CNI.

kubelet é responsável por conectar novos pods à rede (pode ser uma rede overlay, por exemplo).
kubelet lê um diretório de configuração (geralmente /etc/cni/net.d ) para redes CNI usarem.
Quando um novo Pod é criado, o kubelet lê os arquivos no diretório de configuração exec para o binário CNI especificado no arquivo de configuração (o binário geralmente está em /opt/cni/bin ). O binário que será executado pertence e é instalado por terceiros (como Weave, Flannel, Calico, etc.).

kubeadm é uma ferramenta genérica para ativar clusters Kubernetes e não sabe qual solução de rede você deseja e não favorece ninguém em específico. Depois que kubeadm init é executado, não existe tal binário CNI nem configuração . Isso significa que kubeadm init NÃO É SUFICIENTE para colocar um cluster totalmente funcional em funcionamento.

Isso significa que depois de kubeadm init , os logs do kubelet dirão

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

isso é muito esperado. Se não fosse esse o caso, teríamos preferido um provedor de rede específico.

Então, como faço para "consertar" esse erro?
A próxima etapa no guia de primeiros passos do kubeadm é "Instalando uma rede pod".
Isso significa kubectl apply um manifesto de seu provedor de rede CNI preferencial.

O DaemonSet copiará os binários CNI necessários para /opt/cni/bin e a configuração necessária para /etc/cni/net.d/ . Também executará o daemon real que configura a rede entre os nós (escrevendo regras de iptables, por exemplo).

Depois que o provedor CNI for instalado, o kubelet notará que "ah, tenho algumas informações sobre como configurar a rede" e usará a configuração de terceiros e os binários.

E quando a rede é configurada pelo provedor terceirizado (por kubelet invocando-a), o Nó se marca como Ready .

Como esse problema está relacionado ao kubeadm?

No final do ciclo v1.6, um PR foi mesclado que mudou a maneira como o kubelet relatou o status Ready/NotReady . Em versões anteriores, kubelet sempre relatou o status de Ready , independentemente de a rede CNI ter sido configurada ou não. Na verdade, isso estava meio errado e foi alterado para respeitar o status da rede CNI. Ou seja, NotReady quando CNI não foi inicializado e Ready quando inicializado.

O kubeadm na v1.6.0 esperou incorretamente que o nó mestre estivesse no estado Ready antes de prosseguir com o restante das kubeadm init tarefas. Quando o comportamento do kubelet mudava para relatar NotReady quando o CNI não era inicializado, o kubeadm esperaria para sempre até que o Nó recebesse Ready .

ESTE PROBLEMA É ESSE PROBLEMA DE QUE ESPERA MAL DE CONCEPÇÃO NO LADO KUBEADM

No entanto, corrigimos rapidamente a regressão na v1.6.1 e a lançamos alguns dias após a v1.6.0.

Leia a retrospectiva para obter mais informações sobre isso e por que a v1.6.0 pode ser lançada com essa falha.

Então, o que você faz se acha que vê esse problema no kubeadm v1.6.1 +?

Bem, eu realmente acho que você não sabe. Este problema ocorre quando kubeadm init está em um deadlock.
Nenhum usuário ou mantenedor viu isso na v1.6.1 +.

O que você VAI ver é

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

depois de cada kubeadm init em todas as versões acima da v1.6, mas isso NÃO É RUIM

De qualquer forma, abra um novo problema se você vir algo inesperado com o kubeadm

Por favor, não comente mais sobre este assunto. Em vez disso, abra um novo.

@billmilligan Então você só precisa de kubectl apply um manifesto de provedor de CNI para colocar seu cluster em funcionamento, eu acho

Estou resumindo o que foi dito acima, mas espero que de uma forma mais clara e detalhada.
Se você tiver dúvidas sobre como funciona o CNI, consulte os canais de suporte normais como StackOverflow, um problema ou Slack.

(Por último, desculpe por tanto texto em negrito, mas senti que era necessário para chamar a atenção das pessoas.)