Kubeadm: como renovar o certificado quando apiserver cert expirou?

Duplicado de https://github.com/kubernetes/kubeadm/issues/206.

@zalmanzhao você conseguiu resolver esse problema?

Eu criei um cluster kubeadm v1.9.3 pouco mais de um ano e estava funcionando bem o tempo todo. Fui atualizar uma implantação hoje e percebi que meu acesso à API foi bloqueado porque o certificado expirou. Não consigo nem kubeadm alpha phase certs apiserver , porque obtenho failure loading apiserver certificate: the certificate has expired (a versão do kubeadm é atualmente 1.10.6 pois quero atualizar).

Adicionar insecure-skip-tls-verify: true a ~/.kube/config → clusters[0].cluser também não ajuda - vejo You must be logged in to the server (Unauthorized) ao tentar kubectl get pods (https: // github. com / kubernetes / kubernetes / issues / 39767).

O cluster está funcionando, mas vive sua própria vida até que se autodestrua ou até que as coisas sejam consertadas 😅 Infelizmente, não consegui encontrar uma solução para minha situação em # 206 e estou me perguntando como sair dela. O único material relevante que consegui extrair foi uma /etc/kubernetes/ssl/ (apenas /etc/kubernetes/pki/ ) - ou eu tenho uma versão diferente do k8s ou simplesmente apaguei essa pasta sem perceber.

@errordeveloper, você poderia recomendar algo? Adoraria consertar as coisas sem kubeadm reset e recreação de carga útil.

@kachkaev Você teve alguma sorte ao renovar os certificados sem redefinir o kubeadm?
Em caso afirmativo, compartilhe, estou tendo o mesmo problema aqui com k8s 1.7.4. E não consigo atualizar (plano de atualização $ kubeadm) porque o erro aparece novamente informando que o certificado expirou e que ele não pode listar os mestres em meu cluster:

[ERROR APIServerHealth]: the API Server is unhealthy; /healthz didn't return "ok"
[ERROR MasterNodesReady]: couldn't list masters in cluster: Get https://172.31.18.88:6443/api/v1/nodes?labelSelector=node-role.kubernetes.io%2Fmaster%3D: x509: certificate has expired or is not yet valid

Infelizmente, desisti no final. A solução foi criar um novo cluster, restaurar toda a carga útil nele, trocar os registros DNS e, finalmente, excluir o cluster original 😭 Pelo menos não houve tempo de inatividade porque tive a sorte de ter pods saudáveis ​​no antigo k8s durante a transição.

Obrigado @kachkaev por responder. Mesmo assim, vou tentar novamente.
Se eu encontrar algo, farei questão de postar aqui ...

Se você estiver usando uma versão do kubeadm anterior a 1.8, onde eu entendo que a rotação de certificado # 206 foi colocada em prática (como um recurso beta ) ou seus certificados já expiraram, você precisará atualizar manualmente seus certificados (ou recriar seu cluster, que parece que alguns (não apenas @kachkaev) acabam recorrendo).

Você precisará conectar-se ao nó mestre com SSH. Se você estiver usando kubeadm> = 1.8, pule para 2.

1. Atualize o Kubeadm, se necessário. Eu estava no 1.7 anteriormente.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Faça backup de certificados e chaves antigos do apiserver, apiserver-kubelet-client e front-proxy-client.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Gere certificados e chaves novos apiserver, apiserver-kubelet-client e front-proxy-client.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Faça backup de arquivos de configuração antigos

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Gere novos arquivos de configuração.

Há uma observação importante aqui. Se você estiver na AWS, precisará passar explicitamente o parâmetro --node-name nesta solicitação. Caso contrário, você obterá um erro como: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal em seus logs sudo journalctl -u kubelet --all | tail e o nó mestre relatará que é Not Ready quando você executar kubectl get nodes .

Certifique-se de substituir os valores passados ​​em --apiserver-advertise-address e --node-name pelos valores corretos para o seu ambiente.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Certifique-se de que seu kubectl esteja procurando seus arquivos de configuração no lugar certo.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Reinicie o seu nó mestre

$ sudo /sbin/shutdown -r now

1. Reconecte-se ao seu nó mestre, pegue seu token e verifique se o seu nó mestre está "Pronto". Copie o token para sua área de transferência. Você precisará dele na próxima etapa.

$ kubectl get nodes
$ kubeadm token list

Se você não tiver um token válido. Você pode criar um com:

$ kubeadm token create

O token deve ser semelhante a 6dihyb.d09sbgae8ph2atjw

1. SSH em cada um dos nós escravos e reconecte-os ao mestre

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repita a Etapa 9 para cada nó de conexão. No nó mestre, você pode verificar se todos os nós escravos se conectaram e estão prontos para:

$ kubectl get nodes

Esperançosamente, isso o levará aonde você precisa ser @davidcomeyne.

Muito obrigado @danroliver !
Com certeza vou tentar isso e postar minhas descobertas aqui.

@danroliver Obrigado! Apenas tentei em um antigo cluster de nó único, então fiz as etapas até 7. Funcionou.

@danroliver funcionou para mim. Obrigada.

Não funcionou para mim, tive que configurar um novo cluster. Mas que bom que ajudou outros!

obrigado @danroliver . funciona para mim
e minha versão do kubeadm é 1.8.5

Obrigado @danroliver por colocar os passos juntos. Tive de fazer pequenos acréscimos aos seus passos. Meu cluster está executando a v1.9.3 e está em um datacenter privado fora da Internet.

No mestre

1. Prepare um kubeadm config.yml .

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: <master-ip>
kubernetesVersion: 1.9.3

1. Certificados de backup e arquivos conf

mkdir ~/conf-archive/
for f in `ls *.conf`;do mv $f ~/conf-archive/$f.old;done

mkdir ~/pki-archive
for f in `ls apiserver* front-*client*`;do mv $f ~/pki-archive/$f.old;done

1. Os comandos kubeadm no mestre tinham --config config.yml assim:

kubeadm alpha phase certs apiserver --config ./config.yml 
kubeadm alpha phase certs apiserver-kubelet-client --config ./config.yml 
kubeadm alpha phase certs front-proxy-client --config ./config.yml
kubeadm alpha phase kubeconfig all --config ./config.yml --node-name <master-node>
reboot

1. Criar token

Sobre os lacaios

Eu tive que me mudar

mv /etc/kubernetes/pki/ca.crt ~/archive/
mv /etc/kubernetes/kubelet.conf ~/archive/
systemctl stop kubelet
kubeadm join --token=eeefff.55550009999b3333 --discovery-token-unsafe-skip-ca-verification <master-ip>:6443

Obrigado @danroliver! Apenas meu cluster de nó único foi o suficiente para seguir as etapas 1 a 6 (sem reinicialização) e enviar um SIGHUP para kube-apiserver . Acabei de encontrar a id do contêiner com docker ps e definir o sinal com docker kill -s HUP <container id> .

Muito obrigado @danroliver! Em nosso cluster de mestre único / vários trabalhos, as etapas de 1 a 7 foram suficientes, não foi necessário reconectar todos os nós de trabalho ao mestre (o que foi a parte mais dolorosa).

Obrigado por este ótimo passo a passo, @danroliver! Estou me perguntando como esse processo pode ser aplicado a um cluster multimestre (bare metal, atualmente executando 1.11.1) e, de preferência, sem tempo de inatividade. Meus certificados ainda não expiraram, mas estou tentando aprender como regenerá-los / renová-los antes que isso aconteça.

@kcronin
por favor, dê uma olhada neste novo documento:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
espero que ajude.

@danroliver : Muito obrigado, está funcionando.

Não é necessário reiniciar os servidores.
É suficiente recriar pods do sistema Kube (apiserver, schduler, ...) por estes dois comandos:

systemctl restart kubelet
para i em $ (docker ps | egrep 'admin | controlador | planejador | api | fron | proxy' | rev | awk '{print $ 1}' | rev);
faça docker para $ i; feito

Eu tive que lidar com isso também em um cluster 1.13, no meu caso os certificados estavam prestes a expirar de forma um pouco diferente
Também lidando com uma única instância master \ control no local, então não precisa se preocupar com uma configuração de HA ou especificações AWS
Não incluiu as etapas de volta como os outros caras incluíram acima

Como os certificados não haviam expirado, o cluster já tinha cargas de trabalho que eu queria continuar trabalhando
Não teve que lidar com certificados etcd neste momento, então omiti

Então, em um alto nível, eu tive que

• No mestre
  
  
  
  • Gere novos certificados no mestre
  
  
  • Gere novos kubeconfigs com certificados incorporados
  
  
  • Gerar novos certicates Kubelet - cliente e servidor
  
  
  • Gere um novo token para os kubelets do nó de trabalho
  
  
• Para cada trabalhador
  
  
  
  • Drene o trabalhador primeiro no mestre
  
  
  • ssh para o trabalhador, pare o kubelet, remova arquivos e reinicie o kubelet
  
  
  • Desacorde o trabalhador no mestre
  
  
• No mestre no final
  
  
  
  • Excluir token
  
  

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Vamos criar um novo token para os nós que se reintegram ao cluster (após a reinicialização do kubelet)

# On master
sudo kubeadm token create

Agora, para cada trabalhador - um de cada vez

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh para o nó de trabalho

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

De volta ao mestre e desamarrar o trabalhador

kubectl uncordon WORKER-NODE-NAME

Depois que todos os workers forem atualizados - Remover token - irá expirar em 24h, mas vamos nos livrar dele

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

@pmcgrath Obrigado por postar essas etapas. Consegui segui-los e renovar meus certificados e obter um cluster funcional.

Se você estiver usando uma versão do kubeadm anterior a 1.8, onde eu entendo que a rotação de certificado # 206 foi colocada em prática (como um recurso beta ) ou seus certificados já expiraram, você precisará atualizar manualmente seus certificados (ou recriar seu cluster, que parece que alguns (não apenas @kachkaev) acabam recorrendo).

Você precisará conectar-se ao nó mestre com SSH. Se você estiver usando kubeadm> = 1.8, pule para 2.

1. Update Kubeadm, if needed. I was on 1.7 previously.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Backup old apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Generate new apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Backup old configuration files

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Generate new configuration files.

Há uma observação importante aqui. Se você estiver na AWS, precisará passar explicitamente o parâmetro --node-name nesta solicitação. Caso contrário, você obterá um erro como: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal em seus logs sudo journalctl -u kubelet --all | tail e o nó mestre relatará que é Not Ready quando você executar kubectl get nodes .

Certifique-se de substituir os valores passados ​​em --apiserver-advertise-address e --node-name pelos valores corretos para o seu ambiente.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Ensure that your `kubectl` is looking in the right place for your config files.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Reboot your master node

$ sudo /sbin/shutdown -r now

1. Reconnect to your master node and grab your token, and verify that your Master Node is "Ready". Copy the token to your clipboard. You will need it in the next step.

$ kubectl get nodes
$ kubeadm token list

Se você não tiver um token válido. Você pode criar um com:

$ kubeadm token create

O token deve ser semelhante a 6dihyb.d09sbgae8ph2atjw

1. SSH into each of the slave nodes and reconnect them to the master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repeat Step 9 for each connecting node. From the master node, you can verify that all slave nodes have connected and are ready with:

$ kubectl get nodes

Esperançosamente, isso o levará aonde você precisa ser @davidcomeyne.

Isso é o que eu preciso apenas para 1.14.2 .. quaisquer dicas sobre como

Eu tive que lidar com isso também em um cluster 1.13, no meu caso os certificados estavam prestes a expirar de forma um pouco diferente
Também lidando com uma única instância master \ control no local, então não precisa se preocupar com uma configuração de HA ou especificações AWS
Não incluiu as etapas de volta como os outros caras incluíram acima

Como os certificados não haviam expirado, o cluster já tinha cargas de trabalho que eu queria continuar trabalhando
Não teve que lidar com certificados etcd neste momento, então omiti

Então, em um alto nível, eu tive que

* On the master

  * Generate new certificates on the master
  * Generate new kubeconfigs with embedded certificates
  * Generate new kubelet certicates - client and server
  * Generate a new token for the worker node kubelets

* For each worker

  * Drain the worker first on the master
  * ssh to the worker, stop the kubelet, remove files and restart the kubelet
  * Uncordon the worker on the master

* On master at the end

  * Delete token

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Vamos criar um novo token para os nós que se reintegram ao cluster (após a reinicialização do kubelet)

# On master
sudo kubeadm token create

Agora, para cada trabalhador - um de cada vez

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh para o nó de trabalho

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

De volta ao mestre e desamarrar o trabalhador

kubectl uncordon WORKER-NODE-NAME

Depois que todos os workers forem atualizados - Remover token - irá expirar em 24h, mas vamos nos livrar dele

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

Eu sei que este problema foi resolvido, mas eu tenho o mesmo problema em 1.14.2 e o guia não dá erros, mas não consigo me conectar ao cluster e reemitir o token (recebo falha na autenticação)

Um cluster k8s criado usando kubeadm v1.9.x teve o mesmo problema ( apiserver-kubelet-client.crt expirou em 2 de julho) na idade de v1.14.1 lol

Tive que consultar 4 fontes diferentes para renovar os certificados, regenerar os arquivos de configuração e trazer de volta o cluster simples de 3 nós.

@danroliver deu
[Renovando certificados de cluster Kubernetes] do IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

NOTA: IBM Financial Crimes Insight com Watson private é desenvolvido por k8s, nunca soube disso.

Problema com as etapas 3 e 5

A etapa 3 NÃO deve ter a fase no comando

$ sudo kubeadm alpha certs renew apiserver
$ sudo kubeadm alpha certs renew apiserver-kubelet-client
$ sudo kubeadm alpha certs renew front-proxy-client

A etapa 5 deve ser usada a seguir, kubeadm alpha não tem kubeconfig all, que é uma fase de inicialização do kubeadm

# kubeadm init phase kubeconfig all
I0705 12:42:24.056152   32618 version.go:240] remote version is much newer: v1.15.0; falling back to: stable-1.14
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

em 1.15 nós adicionamos melhor documentação para renovação de certificado:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

além disso, após 1,15 kubeadm upgrade renovará automaticamente os certificados para você!

Um cluster k8s criado usando kubeadm v1.9.x teve o mesmo problema (apiserver-kubelet-client.crt expirou em 2 de julho) na idade de v1.14.1 lol

versões anteriores a 1.13 já não são suportadas.
nós encorajamos fortemente os usuários a acompanhar este projeto em rápida evolução.

atualmente, há discussões em andamento no Grupo de trabalho LongTermSupport, para que as versões do kubernetes tenham suporte por períodos mais longos, mas o estabelecimento do processo pode demorar um pouco.

Obrigado @pmorie .
Funciona com o kube versão 1.13.6

Apenas um comentário e solicitação de recurso: esta expiração de certificado nos atingiu na produção em nosso cluster Kubernetes 1.11.x esta manhã. Tentamos tudo acima (e para os links), mas encontramos vários erros, desistimos depois de algumas horas e ficamos completamente presos em um grande cluster hosed. Felizmente, estávamos a cerca de 2 semanas de fazer o upgrade para o Kubernetes 1.15 (e construir um novo cluster), então acabamos criando um novo cluster 1.15 do zero e copiando todos os nossos dados de usuário.

Eu gostaria muito que tivesse havido algum aviso antes que isso acontecesse. Nós apenas passamos de "cluster incrivelmente estável" para "pesadelo infernal completamente destruído" sem qualquer aviso, e provavelmente tivemos nosso pior tempo de inatividade de todos os tempos. Felizmente, era uma tarde de sexta-feira na costa oeste, com um impacto relativamente mínimo.

De tudo o que foi discutido acima e em todos os tickets vinculados, a única coisa que teria feito um enorme
a diferença para nós não é mencionada: comece a exibir um aviso quando os certificados expirarão em breve . (Por exemplo, se você usar kubectl e o certificado expirar em algumas semanas, diga-me!).

Desculpe por seus problemas. Normalmente é responsabilidade do operador
para monitorar os certificados no disco para expiração. Mas eu concordo que a falta
de fácil monitoramento pode causar problemas. Essa é uma das razões pelas quais adicionamos um
comando para verificar a expiração do certificado no kubeadm. Ver
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Observe também que após 1.15 o kubeadm renovará automaticamente os certificados em
melhoria. O que incentiva os usuários a atualizarem com mais frequência também.
Em 20 de julho de 2019 03:49, "William Stein" [email protected] escreveu:

Apenas um comentário e solicitação de recurso: esta expiração de certificado nos atingiu em
produção em nosso cluster Kubernetes 1.11.x esta manhã. Nós tentamos
tudo acima (e para links), mas achei vários erros, desisti após um
poucas horas ficando completamente preso em um grande aglomerado de mangueiras. Felizmente,
estávamos a cerca de 2 semanas de fazer o upgrade para o Kubernetes 1.15 (e construir
um novo cluster), então acabamos criando um novo cluster 1.15 do zero
e copiar todos os nossos dados de usuário.

Eu gostaria muito que tivesse havido algum aviso antes que isso acontecesse. Nós apenas
passou de "cluster incrivelmente estável" para "infernal completamente quebrado
pesadelo "sem qualquer aviso e provavelmente nosso pior tempo de inatividade de todos os tempos.
Felizmente, era uma tarde de sexta-feira na costa oeste, de modo relativamente mínimo
impactante.

De tudo discutido acima e em todos os tickets vinculados, uma coisa
isso teria feito um enorme
diferença para nós não é mencionada: comece a exibir um aviso quando certsvão expirar em breve . (Por exemplo, se você usar kubectl, e o certificado for
vai expirar em algumas semanas, diga-me!).

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NCYFA#issuecomment-513420308 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@ neolit123 Obrigado; adicionaremos algo à nossa própria infraestrutura de monitoramento para verificar periodicamente os próximos problemas de certificação, conforme explicado em seu comentário.

@danroliver Muito
Um ponto que vale a pena mencionar são os certificados relacionados ao "etcd", que devem ser renovados da mesma forma. Não há necessidade de recarregar a configuração, pois ela é usada em arquivos YAML de metadados como referências.

Para o Kubernetes v1.14, considero este procedimento proposto por @desdic o mais útil:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • faça backup e gere novamente todos os certificados:
  
  

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --apiserver-advertise-address <IP>

• faça backup e gere novamente todos os arquivos kubeconfig:

$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,mv kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all
$ reboot

• copiar novo admin.conf :

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Para o Kubernetes v1.14, considero este procedimento o mais útil:

* https://stackoverflow.com/a/56334732/1147487

Eu criei a correção uma vez que meu próprio cluster foi consertado .. esperava que outra pessoa pudesse usá-lo

@danroliver deu
[Renovando certificados de cluster Kubernetes] do IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

Agradável! Eu me pergunto quando isso foi publicado. Eu certamente teria achado isso útil quando estava passando por isso.

Nota sobre tokens em K8s 1.13.x (possivelmente outras versões K8s)
Se você acabou gerando novamente seu certificado CA ( /etc/kubernetes/pki/ca.crt ), seus tokens (consulte kubectl -n kube-system get secret | grep token ) podem ter CA antigo e terão que ser regenerados. Os tokens problemáticos incluíram kube-proxy-token , coredns-token no meu caso (e outros), o que impediu os serviços críticos de cluster de autenticar com a API K8s.
Para regenerar tokens, exclua os antigos e eles serão recriados.
O mesmo vale para quaisquer serviços que se comuniquem com a API K8s, como PV Provisioner, Ingress Controllers, cert-manager , etc.

Obrigado por este ótimo passo a passo, @danroliver! Estou me perguntando como esse processo pode ser aplicado a um cluster multimestre (bare metal, atualmente executando 1.11.1) e, de preferência, sem tempo de inatividade. Meus certificados ainda não expiraram, mas estou tentando aprender como regenerá-los / renová-los antes que isso aconteça.

Olá @kcronin , como você resolveu a configuração multi-master? Não sei como proceder com --apiserver-advertise-addresspois tenho 3 IPs e não apenas um.

Obrigado

@pmcgrath Caso eu tenha 3 mestres, devo repetir os passos em cada mestre? ou o que é. caso

@SuleimanWA , você pode copiar admin.conf , bem como o arquivo CA, se o CA foi regenerado.
Para todo o resto, você deve repetir as etapas para regenerar certificados (para etcd, kubelet, planejador, etc.) em cada mestre

@anapsix
Estou executando um cluster 1.13.x e apiserver está relatando Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] depois que renovei os certificados executando kubeadm alpha certs renew all .

Para regenerar tokens, exclua os antigos e eles serão recriados.

A qual token você está se referindo neste caso? Aquele é gerado pelo kubeadm ou como posso excluir o token?

-----ATUALIZAR-----
Eu descobri que é o próprio segredo. No meu caso, o controlador do kube não estava ativo, então o segredo não foi gerado automaticamente.

uso de versão alta:

kubeadm alpha certs renova todos

Quando o kubelet do primeiro nó mestre é desativado (systemctl stop kubelet), outros nós mestre não podem entrar em contato com a CA no primeiro nó mestre. Isso resulta na seguinte mensagem até que o kubelet no nó mestre original seja colocado on-line novamente:

kubectl get nodes
Erro do servidor (InternalError): um erro no servidor ("") impediu que a solicitação fosse bem-sucedida (obter nós)

Existe uma maneira de transferir a função CA para outros nós mestres enquanto o kublet no nó CA original está desativado?

@anapsix
Estou executando um cluster 1.13.x e apiserver está relatando Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] depois que renovei os certificados executando kubeadm alpha certs renew all .

Para regenerar tokens, exclua os antigos e eles serão recriados.

A qual token você está se referindo neste caso? Aquele é gerado pelo kubeadm ou como posso excluir o token?

-----ATUALIZAR-----
Eu descobri que é o próprio segredo. No meu caso, o controlador do kube não estava ativo, então o segredo não foi gerado automaticamente.

Olá, fiz esta tarefa, mas não na versão 1.13. Posso perguntar algumas coisas se você já fez isso?
Então, basicamente, vou fazer:
kubeadm alpha certs renew all (que atualiza o plano de controle cert uber pki / pasta no Masters).
kubeadm init phase kubeconfig para atualizar os arquivos de configuração do kube. (No Mestre e trabalhador).
Reinicie o kubelet em todos os nós.

Ainda preciso criar um token e executar a junção nos nós de trabalho? Se possível, você pode compartilhar as etapas executadas?