<p>Os certificados de fase alfa do kubeadm renovam todos também devem atualizar os certificados nos arquivos KubeConfig</p>

@MalloZup
claro, mas observe que as fases de junção são de alta prioridade.

soa bem! Muito obrigado.

Oi,

há mais uma coisa em relação a este tópico.

kubeadm alpha phase kubeconfig all mostra esta mensagem se os arquivos conf estiverem no lugar ao emitir o comando:

[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

Ele não verifica se os certificados expiraram, portanto, em minha opinião, up-to-date é um erro de leitura.

Para obter os certificados atualizados nos arquivos, é PRECISO remover os arquivos antecipadamente, então o log se parece com:

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"   

No meu caso, achei que estou bem, mas alguns dias depois, os pods estáticos não conseguiram se comunicar devido a certificados desatualizados.

Cumprimentos
Andreas

Atribuído a @MalloZup

@MalloZup : GitHub não me permitiu atribuir os seguintes usuários: MalloZup.

Observe que apenas membros do kubernetes e colaboradores do repo podem ser atribuídos e que as questões / PRs podem ter apenas 10 responsáveis ​​ao mesmo tempo.
Para obter mais informações, consulte o guia do contribuidor

oi @adoerler thx pelo problema. Em relação às informações enganosas, enviei um PR https://github.com/kubernetes/kubernetes/pull/73798.

Vou dar uma olhada no resto do problema assim que tiver tempo. Obrigado pelo tempo e precisão do problema

@adoerler , enviei um DOC pr por sua sugestão. Sinta-se à vontade para dar uma olhada tia: rocket:
(https://github.com/kubernetes/website/pull/12579)

Olá @MalloZup ,

obrigado pelo PR!

Estou perdendo uma frase sobre os arquivos kubeconfig, porque certs renew é apenas uma parte do jogo.
Algo como:

Após a renovação dos certificados, não se esqueça de recriar os arquivos KubeConfig usando kubeadm alpha phase kubeconfig ...

THX. Não adicionei o documento porque estava pensando que poderíamos renovar também os arquivos kubeconfig. O restante, reiniciando pods, podemos delegar ao usuário e escrever documentos mínimos. @fabriziopandini @lubomir @ereslibre Estou faltando alguma coisa nesta implementação? Tia

@MalloZup Não tenho um conhecimento profundo de como funciona a renovação de certificados.

Pessoalmente, gostaria de esclarecer um pouco a história geral antes de tomar medidas - incluindo o que foi proposto acima -:

• o que deve ser gerenciado por kubeadm alpha phase certs renew
• o que deve ser gerenciado automaticamente durante kubeadm upgrade
• o que deve ser documentado (e gerenciado pelos usuários)
• como isso se aplica a clusters HA
• como isso é afetado por variantes de cluster (como por exemplo, External etcd, External CA)
• etc.

mas deixo a palavra final para pessoas mais qualificadas do que eu nesta área

Acho que devemos reservar um tempo em uma reunião para discutir qual deve ser nossa política de renovação de certificados recomendada. a página sobre gerenciamento de certificados pode precisar de alguns detalhes extras:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

e precisamos escrever um pequeno guia, para clusters de plano de controle único como um começo, pelo menos.

o que os usuários têm feito é descobrir as coisas por conta própria:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ este comentário e um acima contêm guias feitos pelo usuário.

este é um sinal de que precisamos adicionar um guia oficial.
cc @timothysc @liztio

/ assign @ereslibre

Nosso cluster com algumas centenas de usuários está preso no momento. Posso ter um guia rápido sobre o que fazer com um certificado expirado?

@ dimm0

o que os usuários têm feito é descobrir as coisas por conta própria:
# 581 (comentário)
^ este comentário e um acima contêm guias feitos pelo usuário.

estes são os únicos guias que temos ATM.

[root<strong i="5">@controller0</strong> ~]# kubeadm alpha phase certs apiserver --apiserver-advertise-address 1.2.3.4
Error: unknown flag: --apiserver-advertise-address
Usage:

Flags:
  -h, --help   help for phase

Global Flags:
      --log-file string   If non-empty, use this log file
      --rootfs string     [EXPERIMENTAL] The path to the 'real' host root filesystem.
      --skip-headers      If true, avoid header prefixes in the log messages
  -v, --v Level           log level for V logs

error: unknown flag: --apiserver-advertise-address
[root<strong i="6">@controller0</strong> ~]# kubeadm alpha phase certs apiserver
This command is not meant to be run on its own. See list of available subcommands.

em 1.13 fases de inicialização foram graduadas para comando de inicialização pai:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

em 1.12 a bandeira deve estar lá:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 em breve ficará sem suporte.

removendo o ciclo de vida / etiqueta ativa.
passando para 1.15.

possíveis idéias de atualização de documentos aqui:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
Pergunta: em 1.14 com HA mestre, é suficiente seguir https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 em um único mestre, ou temos que reunir os mestres secundários novamente para buscar novamente os certificados?

reunir os nós do plano de controle secundário, parece uma opção rápida e viável em 1,14.
não temos nenhum documento ainda em termos de rotações de certificados HA.
(sem mencionar que ainda devemos adicionar etapas adequadas, como https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139).

--Experimental-upload-certs não fornece a base para uma solução mais fácil para a rotação de certificados em HA?

uma maneira de fazer a rotação de certificados HA é:

• em um único nó de plano de controle, siga as etapas mencionadas acima para atualizar seus certificados
• na mesma chamada de nó CP:

kubeadm init phase upload-certs --experimental-upload-certs

armazene a chave certs.

kubeadm token create --print-join-command

armazene o comando de junção com o token.

reúna o resto dos nós do plano de controle usando o token e a chave certs, um por um usando --certs-key .... --experimental-control-plane-join

para os trabalhadores: drene, junte-se novamente usando o novo token, uncordon, um por um.

opcionalmente, exclua os tokens resultantes.

@ neolit123
Em um cluster de 3 mestres, no momento em que alterarmos os certificados no mestre "primário", o etcd parará de funcionar, pois os certificados são alterados (e o quorum deve ser de no mínimo 51%)? Se for assim, talvez tenhamos de isolar de alguma forma os 2 mestres secundários e só então mudar os certificados? É possível "cordon master"?

Não sou um especialista aqui, mas não acho que a cópia automática do certificado deva entrar neste cenário

Certificados de cópia automática manipulam CA, front-proxy-CA, etcd-CA (com 10 anos TTL) e chave SA (sem TTL)

O comando de renovação de certificado toca todos os outros certificados (com TTL de 1 ano), que são diferentes entre os mestres.
AFAIK, atualmente não há nada que controle a renovação de certificados para arquivos kubeconfig

ok, eu não considerei o que "cópia certs" realmente faz aqui.
precisamos escrever documentos cert rotate adequados, de qualquer maneira.

/atribuir
/ lifecycle ativo

Estou começando a trabalhar nessa questão.
Existem diferentes pontos a serem abordados (_atualizado em 14 de maio de 2019_)

• Mesmo com a rotação de certificados ativada, kubelet.conf aponta para certificados desatualizados (já rastreados por https://github.com/kubernetes/kubeadm/issues/1317)
• A rotação de certificados não atualiza certificados apiserver / etcd / front-proxy-client (corrigidos por https://github.com/kubernetes/kubernetes/pull/76862)
• Os certificados de fase alfa do Command kubeadm renovam todos não atualizam os arquivos KubeConfig (corrigidos por https://github.com/kubernetes/kubernetes/pull/77180)
• Documentação sobre renovação de certificados (com mais detalhes sobre onde o comando deve ser executado, quando, kubeconfig, HA)

E tratarei de todos eles em RPs separados

@ neolit123 @fabriziopandini
são as etapas que você mencionou também para girar o certificado de CA? Isso também pode ser documentado? Que tal girar as chaves privadas, incluindo a da CA?

@ tushar00jain a rotação do certificado CA é rastreada em outra edição https://github.com/kubernetes/kubeadm/issues/1350
Este problema se concentra apenas em certificados assinados

@fabriziopandini eu estava pensando em fechar este tíquete hoje porque você conseguiu enviar PRs para as peças de renovação. o tíquete deve ser fechado?

Mesmo com a rotação de certificados habilitada, kubelet.conf aponta para certificados desatualizados (já rastreados por # 1317)

sim, isso é rastreado em uma edição separada, possivelmente precisa de discussão / documentos em termos de quais soluções alternativas devemos fornecer.

A rotação de certificados não atualiza certificados apiserver / etcd / front-proxy-client (corrigidos por kubernetes / kubernetes # 76862)

Os certificados de fase alfa do Command kubeadm renovam todos não atualizam os arquivos KubeConfig (corrigidos por kubernetes / kubernetes # 77180)

Documentação sobre renovação de certificados (com mais detalhes sobre onde o comando deve ser executado, quando, kubeconfig, HA)

o 3 acima deve ser feito.

/perto
Conforme o comentário acima, a maior parte do trabalho já está concluída; o bit que falta é rastreado em uma edição separada / dedicada

@fabriziopandini : Fechando esta edição.

Alguém pode me explicar como foi tratada a parte "Mesmo com a rotação de certificados habilitada, kubelet.conf aponta para certificados desatualizados"? O único problema vinculado que menciona isso explicitamente fechado em favor de outro problema que é fechado com "Não tenho certeza se isso é um problema, então abra um novo tíquete, se for".
Estou em 1.16 e não vejo nenhuma renovação acontecendo em kubelet.conf com sudo kubeadm alpha certs renew all . O que estou faltando? @ neolit123

uma rápida recapitulação de uma longa discussão.

1. rotação de certificados para todos os certificados, exceto kubelet.conf, agora são gerenciados por kubeadm alpha cert renew.
2. a rotação de certificados para kubelet.conf será gerenciada pelo próprio kubelet (a menos que o usuário opte pela rotação automática de certificados)

Este segundo ponto já funciona a partir de hoje para todos os nós, exceto aquele em que você executa o kubeadm init; https://github.com/kubernetes/kubernetes/pull/84118 vai consertar isso

@fabriziopandini Obrigado por isso, faz sentido.

Para qualquer outra pessoa que enfrente o problema de os certs em kubelte.conf estarem desatualizados entre agora e quando o acima for corrigido, achei este artigo útil:

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check -certificate-expiration

Em nós criados com kubeadm init, antes do kubeadm versão 1.17, há um bug em que você precisa modificar manualmente o conteúdo de kubelet.conf. Após a conclusão do kubeadm init, você deve atualizar o kubelet.conf para apontar para os certificados de cliente kubelet girados, substituindo client-certificate-data e client-key-data por:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

@AndrewSav Obrigado por isso. Usei o operador promethes para monitorar o cluster. Recentemente, recebi um alerta "O certificado da API do Kubernetes expira em menos de 7 dias", acho que está relacionado a esse problema. Eu atualizei o conteúdo do kubelet.conf nos nós mestres. Mas ainda recebo o alerta. Você tem alguma sugestão? Tks.

@tannh se você instalou o cluster com kubeadm, use kubeadm para verificar o experation certs. Caso contrário, seu problema provavelmente não está relacionado.

Em nós criados com kubeadm init, antes do kubeadm versão 1.17, há um bug em que você precisa modificar manualmente o conteúdo de kubelet.conf. Após a conclusão do kubeadm init, você deve atualizar o kubelet.conf para apontar para os certificados de cliente kubelet girados, substituindo client-certificate-data e client-key-data por:

isso também estará nas notas de lançamento do 1.17.

@adoerler Ainda estou executando a versão antiga do kubeadm, como posso atualizar o kubelet.conf, admin.con, ... etc, após a renovação do certificado?

Executei "kubeadm alpha certs renew all", que gerou novos certificados, então preciso editar todos os .conf em / etc / kubernetes, como? onde exatamente eles devem apontar?
e no caso de nós múltiplos mestres, devo executar o comando em todos os mestres?

Olá @SuleimanWA ,

Eu não posso te dizer o que fazer em um env multi master, eu tive apenas um master em minha configuração.

Isso é o que eu fiz:

Em primeiro lugar, certifique-se de remover os arquivos conf existentes do caminho, porque os arquivos existentes não serão sobrescritos!

mv /etc/kubernetes/admin.conf /backup
mv /etc/kubernetes/kubelet.conf /backup
mv /etc/kubernetes/controller-manager.conf /backup
mv /etc/kubernetes/scheduler.conf /backup

em seguida, atualize esses arquivos:

user<strong i="13">@master</strong>:~$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address=<INSERT-YOUR-APISERVER-IP-HERE>
I0124 21:56:14.253641   15040 version.go:236] remote version is much newer: v1.13.2; falling back to: stable-1.12
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"    

Para aplicar os novos certificados nos pods do sistema estático, a maneira mais fácil para mim era simplesmente reiniciar o servidor mestre.

Não se esqueça de copiar client-certificate-data e client-key-data de /etc/kubernetes/admin.conf para seu .kube/config .

Espero que isto ajude

Andreas

Alguma ideia de como executar este comando em 1.14.10? Tudo que eu consigo é:

kubeadm alpha phase kubeconfig all --apiserver-advertise-address=192.168.102.170 Error: unknown flag: --apiserver-advertise-address

Então os documentos dizem:
kubeadm alpha phase kubeconfig all
e eu recebo:
This command is not meant to be run on its own. See list of available subcommands.

Obrigado

Olá @provgregoryabdo ,

qual é a sua saída de kubeadm version ?

BR Andreas

@provgregoryabdo os phase saíram do alfa e foram para o init em versões posteriores para que você possa usar algo como

kubeadm init phase kubeconfig all --apiserver-advertise-address=<your_address>

@adoerler obrigado pela ajuda!