<p>O kubeadm foi redefinido com sucesso, mas o ip do nó ainda está no kubeadm-config configmap</p>

cc @fabriziopandini

Idealmente, haveria uma maneira de "atualizar" o ClusterStatus. Executamos clusters com teste de caos, é inteiramente possível que um nó de plano de controle seja encerrado sem aviso e sem oportunidade de executar kubeadm reset . Idealmente, haveria uma maneira limpa de atualizar o ClusterStatus explicitamente para remover os nós do plano de controle que sabemos que não estão mais no cluster. Isso é algo que deve ser feito antes de executar kubeadm join --control-plane ... ou possivelmente está embutido?

Alguns comentários aqui:

kubeadm-config ConfigMap remove este ip do nó.

@pytimer Eu sei que ter um endereço de API de nó deixado no status de cluster não é o ideal, mas estou interessado em entender se essa "falta de limpeza" gera problemas ou não. Você já tentou entrar no mesmo plano de controle novamente? você já tentou entrar em outro plano de controle? Não espero problemas, mas obter uma confirmação neste ponto será muito apreciado.

Ainda tenho uma pergunta, por que kubeadm reset não exclui este nó diretamente do cluster? Em vez disso, execute kubectl delete nodemanualmente.

@luxas pode ser um pouco de contexto histórico pode ajudar aqui.
Meu palpite é que o nó não teve o privilégio de se excluir (mas isso se aplica a nós de trabalho, não a nós de plano de controle ...)

Idealmente, haveria uma maneira de "atualizar" o ClusterStatus / haveria uma maneira limpa de atualizar o ClusterStatus explicitamente

@danbeaulieu, esse é um bom ponto. ter um comando explícito para sincronizar o status do cluster e / ou impor a sincronização automática quando o kubeadm é executado é uma boa ideia.
No entanto, sendo kubeadm sem qualquer tipo de loop de controle em execução contínua, acho que sempre haverá a possibilidade de ter ClusterStatus fora de sincronia.
Isso não deve ser um problema ou, mais especificamente, ter ip de nó para nós que não existem mais (falta de limpeza) não deve ser um problema.
Em vez disso, se existir um nó e o ip do nó correspondente estiver faltando no ClusterStatus (inicialização errada), isso pode criar problemas, por exemplo, para atualizações.

Você poderia gentilmente relatar se as suposições acima foram confirmadas por seus testes de caos? qualquer feedback será realmente apreciado.

@fabriziopandini Eu ingressei no mesmo nó do plano de controle, falhou.

Minhas etapas de adesão:

O segundo ip do nó do plano de controle é 192.168.46.212 .

• remova o membro etcd do nó 192.168.46.212 do cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f neste nó de plano de controle.
• execute kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 novamente.

registros de junção do kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Vejo o código kubeadm e acho que esse problema pode ser causado por 192.168.46.212 deixado no kubeadm-config ConfigMap.

Kubeadm obtém endpoints de api de kubeadm-config ConfigMap quando o nó de controle de junção de junção e endpoints de etcd são iguais aos endpoints de api. Mas 912.168.46.212 nó do plano de controle foi removido e ainda não foi unido, portanto, verifique a integridade do cluster etcd incorretamente.

Quando eu removo o endpoint de 192.168.46.212 api do kubeadm-config ConfigMap e ingresso neste nó de plano de controle novamente, ele se une com sucesso.

@pytimer obrigado!
Isso deve ser investigado. Já existe uma lógica que tenta sincronizar a suposta lista de endpoints do etcd com o endpoint real da lista do etcd, mas algo parece não estar funcionando corretamente

Sim, isso parece um bug. Temos um plano de controle de 3 nós ASG. Se encerrarmos uma instância, uma nova será criada de acordo com as regras do ASG. Durante esse tempo, o nó encerrado é listado como não íntegro na lista de membros do etcd. Quando a nova instância surge, antes de executar kubeadm join... , ela remove o membro não íntegro do etcd. No momento em que executamos kubeadm join... o cluster etcd está íntegro com 2 nós de acordo com o etcd. No entanto, o kubeadm usa o ClusterStatus como sua fonte de verdade, que ainda tem a instância antiga listada.

A solução alternativa para nós é logo após fazer o gerenciamento de associação etcd é atualizar o kubeadm-config ConfigMap com a verdade do cluster e, em seguida, executar kubeadm join... .

Idealmente, kubeadm join... usaria etcd como a fonte da verdade e atualizaria o kubeadm-config ConfigMap de acordo.

@fabianofranz Talvez tenha encontrado a causa deste problema.

Ao sincronizar os endpoints etcd com a lista real de endpoints etcd, a sincronização é bem-sucedida. Mas atribua os endpoints reais do etcd ao cliente etcd Endpoints , esta variável do cliente não é um ponteiro, então quando outro código usa o cliente, estes endpoints do cliente ainda são endpoints antigos, não os endpoints reais após a sincronização.

Corrigi este problema no meu repositório fork, você pode verificar este PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. E eu testando join the same control-plane node caso de usuário, juntei-me ao sucesso.

@pytimer Parece ótimo! Bem localizado!
Você poderia gentilmente enviar um PR? IMO, isso será elegível para escolha seletiva.

@ neolit123 @timothysc ^^^

@fabianofranz O primeiro PR está errado, esqueci de confirmar o CLA.

Este PR https://github.com/kubernetes/kubernetes/pull/71945 você pode verificar. Se houver alguma coisa errada, espero que você indique.

@fabriziopandini Eu ingressei no mesmo nó do plano de controle, falhou.

Minhas etapas de adesão:

O segundo ip do nó do plano de controle é 192.168.46.212 .

• remova o membro etcd do nó 192.168.46.212 do cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f neste nó de plano de controle.
• execute kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 novamente.

registros de junção do kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Vejo o código kubeadm e acho que esse problema pode ser causado por 192.168.46.212 deixado no kubeadm-config ConfigMap.

Kubeadm obtém endpoints de api de kubeadm-config ConfigMap quando o nó de controle de junção de junção e endpoints de etcd são iguais aos endpoints de api. Mas 912.168.46.212 nó do plano de controle foi removido e ainda não foi unido, portanto, verifique a integridade do cluster etcd incorretamente.

Quando eu removo o endpoint de 192.168.46.212 api do kubeadm-config ConfigMap e ingresso neste nó de plano de controle novamente, ele se une com sucesso.

Recebi o mesmo erro na versão 1.13.2 do kubeadm, tentei remover o nó manualmente e atualizar o kubeadm-config, não funciona, os nós etcd restantes ainda tentam conectar o nó removido

Quando eu removo o endpoint de 192.168.46.212 api do kubeadm-config ConfigMap e ingresso neste nó de plano de controle novamente, ele se une com sucesso.

@pytimer Você pode explicar como removeu manualmente o antigo api-server?

Estou executando o 1.13.3; removendo o servidor antigo manualmente por meio de:

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

Ainda não consigo entrar no cluster devido ao erro:

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

Em seguida, matei os pods de API e os pods de etcd (2 de cada).

Eles são recriados, mas ainda tenho o mesmo erro ao tentar conectar o nó adicional.

Tive o mesmo problema em 1.13.3 (configuração de cluster HA: 3 nós mestres + 3 trabalhadores). Nó mestre substituído com sucesso somente após as próximas etapas:

Excluir nó do cluster

kubectl delete node master03

Baixe etcdctl (por exemplo, em master01)

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

Remova o nó mestre do etcd

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

Remover do kubeadm-config

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong Agora kubeadm reset não pode remover o membro etcd, então você descobriu que o cluster etcd ainda conecta o nó etcd removido. Você deve remover manualmente o membro do etcd usando o etcdctl agora.

Eu envio um PR para implementar a remoção do nó etcd ao reiniciar, você pode ver. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Você pode seguir os passos de @Halytskyi . O PR: https://github.com/kubernetes/kubernetes/pull/71945 corrige endpoints de sincronização etcd quando se junta ao nó do plano de controle, não pode remover o membro etcd.

Remova o membro etcd do cluster etcd quando redefinir, você pode ver kubernetes / kubernetes # 74112.

Isso ainda parece ser um bug no 1.13.4.

Ainda precisamos atualizar manualmente o mapa de configuração kubeadm ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

Não é o caso de que a correção em
kubernetes / kubernetes # 71945 usaria a associação do cluster etcd como a fonte da verdade para os membros do cluster? Se não, o que exatamente aquele PR corrigiu?

Curiosamente, ele funciona esporadicamente porque em mapas de alcance golang, como ClusterStatus , é não-determinístico . Portanto, se o primeiro ponto de extremidade que encontrar for de um ponto de extremidade antigo que não existe mais, as coisas falham. Se encontrar um endpoint íntegro, ele atualizará o ClusterStatus do etcd Sync ...

Acredito que a causa raiz disso seja um bug no etcd clientv3, onde o bug faz com que o cliente não tente novamente os outros endpoints se o primeiro falhar https://github.com/etcd-io/etcd/issues/9949.

Use o seguinte problema para rastrear melhorias de redefinição

• https://github.com/kubernetes/kubeadm/issues/1312 Remova os nós do plano de controle do ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Remova membros etcd do cluster etcd (

@fabriziopandini Há pelo menos um outro problema aqui que não está relacionado a kubeadm reset .

Se um nó falhar sem a chance de realizar a redefinição do kubeadm (encerramento da instância, falha de hardware etc.)
O cluster é deixado em um estado em que ClusterStatus.apiEndpoints ainda lista um nó que não está mais no cluster. Isso requer a solução alternativa de ler, editar e atualizar o mapa de configuração antes de executar kubeadm join . O Kubeadm provavelmente tem 2 opções:

1) Implementar a nova tentativa do cliente etcd se a discagem falhar
2) Aguarde até que o bug go-grpc seja corrigido e, em seguida, que a correção chegue ao cliente etcd

Esse problema pode ser um bom problema para rastrear qualquer uma dessas opções.

Se um nó falhar sem a chance de realizar a redefinição do kubeadm (encerramento da instância, falha de hardware etc.)
O cluster é deixado em um estado em que ClusterStatus.apiEndpoints ainda lista um nó que não está mais no cluster. Isso requer a solução alternativa de ler, editar e atualizar o mapa de configuração antes de executar kubeadm join .

isso é verdade, sem chamar reset, você terá que atualizar manualmente o ClusterStatus.
não temos um comando que faça isso. se você acha que este é um recurso que o kubeadm deve suportar, envie um tíquete separado.

Acabei de experimentar isso hoje em 1.14.1

A instância executando um dos meus nós mestres falhou, o que impediu que ele fosse removido normalmente. Quando um novo nó tentou entrar, ele falhou ao se juntar devido ao erro descrito neste tíquete.

Tive que remover manualmente o membro etcd via etcdctl, então eu poderia ingressar em um novo nó. Também removi manualmente o nó do ConfigMap kubeadm-config, mas não tenho certeza se isso era necessário.

@Halytskyi Obrigado seção etcdctl ajudou para mim .....

Experimentei isso hoje em 1.15.5

No meu caso, entrei no cluster, mas com a versão 1.16. em seguida, excluiu este nó kubectl delete node , faça downgrade para 15.5.5 e tente reingressar (mesmo ip, mesmo nome de host, versão diferente) e obteve o erro etcd não íntegro.

Resolvido por (com base na resposta @Halytskyi, mas com etcdctl atualizado):

• Exclua o nó do kubeadm-config configmap

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• kubeadm reset -f no nó problemático && iptables -t -f -X e assim por diante.

• delete membro etcd (esta é a chave):

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

`` `shell
root @ k8s-nebula-m-115-2 : ~ / etcdctl / etcd-v3.4.3-linux-amd64 # ./etcdctl --endpoints https://127.0.0.1 : 2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key lista de membros
289ed62da3c6e9e5, iniciado, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, falso
917e16b9e790c427, iniciado, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, falso
ad6b76d968b18085, iniciado, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, falso

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

E, em seguida, volte a trabalhar.

isso pode acontecer se kubeadm reset for interrompido e não puder excluir o nó do CM do kubeadm.
nesse caso, você precisa excluí-lo manualmente do CM do kubeadm.

Portanto, se eu excluir o nó com kubectl delete node foobar ele não
excluí-lo do membro do etcd? Mas se eu fizer kubeadm reset no nó que eu quero
apagar, então é isso? 🙄

Na quarta-feira, 30 de outubro de 2019, 13:27 Lubomir I. Ivanov, notificaçõ[email protected]
escrevi:

isso pode acontecer se kubeadm reset for interrompido e não puder excluir o
nó do CM kubeadm.
nesse caso, você precisa excluí-lo manualmente do CM do kubeadm.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECT7BPQ#issuecomment-547877054 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

"kubeadm reset" deve excluí-lo do kubeadm CM, mas chamar "kubectl delete node" também é necessário, o que exclui o objeto Node API.

No meu caso, a exclusão do nó do configmap não o excluiu do
Eu precisava do cluster etcd para etcdctl delete member manualmente.

Na quinta-feira, 31 de outubro de 2019 às 16:28, Lubomir I. Ivanov [email protected]
escrevi:

"kubeadm reset" deve excluí-lo do kubeadm CM, mas chamando "kubectl
delete node "também é necessário, o que exclui o objeto Node API.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYGI4Y#issuecomment-548430963 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

O kubeadm reset também deve remover o membro etcd do cluster etcd.
tente executá-lo com, por exemplo, --v = 5 e veja o que ele faz.

no entanto, lembre-se de que kubeadm reset é um comando de melhor esforço, portanto, se ele falhar por algum motivo, poderá apenas imprimir um aviso.

portanto, kubectl delete node não o exclui do etcd. Em vez disso, a execução no nó kubeadm reset faz isso.
parece quebrado para mim, eu acho que kubectl delete node deveria excluí-lo do etcd também. Ou estou perdendo um caso de uso óbvio?
talvez perguntando se também deveria ser excluído de lá?
De qualquer forma, obrigado pelo esclarecimento @ neolit123 , primeiro

portanto, existem responsabilidades diferentes.
kubectl delete node, exclui o objeto Node API - você deve fazer isso quando tiver certeza de que não quer mais o nó por perto,
antes disso, você deve chamar kubeadm reset nesse nó. o que eu faço é limpar o estado do disco e também remover o membro etcd (se este for um nó de plano de controle e se você estiver usando a opção padrão em que as instâncias de etcd estão sendo executadas por nó de plano de controle)

kubeadm reset redefine o nó, mas não exclui o objeto Node por alguns motivos:

• redefinir apenas redefine o nó e você pode ingressar nele novamente. o nome do nó permanece reservado.
• o próprio nó não tem privilégios suficientes para excluir seu objeto Nó. isso é responsabilidade do dono do "admin.conf" (por exemplo, administrador).

kubeadm reset é um comando de melhor esforço

Em relação a isso: quando kubeadm reset não consegue ser concluído por qualquer motivo (incluindo uma falha grave do servidor subjacente para que a reinicialização do kubeadm nunca seja executada em primeiro lugar), existem opções para reconciliar manualmente o estado além da edição manual o objeto kubeadm-config configmap e removendo o nó?

se o nó estiver com falha de hardware e você não puder chamar kubeadm reset nele, serão necessárias etapas manuais. você teria que:
1) remova o IP do plano de controle do kubeadm-config CM ClusterStatus
2) remova o membro etcd usando etcdctl
3) exclua o objeto Node usando kubectl (se você não quiser mais o Node por perto)

1 e 2 se aplicam apenas aos nós do plano de controle.

Existe alguma maneira de automatizar esse failover se o kubeadm reset não puder ser executado?

Os mesmos problemas em 1.9. Obrigado pelas soluções.