Kubeadm: ¿Cómo renovar el certificado cuando expiró apiserver cert?

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

@zalmanzhao, ¿

Creé un clúster kubeadm v1.9.3 poco más de un año y funcionó bien todo este tiempo. Fui a actualizar una implementación hoy y me di cuenta de que no podía acceder a la API porque el certificado expiró. Ni siquiera puedo kubeadm alpha phase certs apiserver , porque obtengo failure loading apiserver certificate: the certificate has expired (la versión de kubeadm es actualmente 1.10.6 ya que quiero actualizar).

Agregar insecure-skip-tls-verify: true a ~/.kube/config → clusters[0].cluser tampoco ayuda; veo You must be logged in to the server (Unauthorized) cuando intento kubectl get pods (https: // github. com / kubernetes / kubernetes / issues / 39767).

El clúster está funcionando, pero vive su propia vida hasta que se autodestruye o hasta que las cosas se arreglan 😅 Desafortunadamente, no pude encontrar una solución para mi situación en el # 206 y me pregunto cómo salir de ella. El único material relevante que pude desenterrar fue una publicación de blog llamada _'Cómo cambiar los certificados caducados en el clúster de kubernetes'_ , que parecía prometedora a primera vista. Sin embargo, al final no encajó porque mi máquina maestra no tenía la carpeta /etc/kubernetes/ssl/ (solo /etc/kubernetes/pki/ ) - o tengo una versión diferente de k8s o simplemente eliminé esa carpeta sin darme cuenta.

@errordeveloper, ¿ podrías recomendar algo? Me encantaría arreglar cosas sin kubeadm reset y recreación de carga útil.

@kachkaev ¿
Si es así, comparta, tengo el mismo problema aquí con k8s 1.7.4. Y parece que no puedo actualizar (plan de actualización de $ kubeadm) porque el error vuelve a aparecer y me dice que el certificado ha expirado y que no puede enumerar los maestros en mi clúster:

[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

Desafortunadamente, me di por vencido al final. La solución fue crear un nuevo clúster, restaurar toda la carga útil en él, cambiar los registros DNS y finalmente eliminar el clúster original 😭 Al menos no hubo tiempo de inactividad porque tuve la suerte de tener pods saludables en los viejos k8 durante la transición.

Gracias @kachkaev por responder. No obstante, lo intentaré de nuevo.
Si encuentro algo, me aseguraré de publicarlo aquí ...

Si está utilizando una versión de kubeadm anterior a 1.8, donde entiendo que la rotación de certificados # 206 se implementó (como una función beta ) o sus certificados ya expiraron, entonces deberá actualizar manualmente sus certificados (o volver a crear su clúster que parece que algunos (no solo @kachkaev) terminan recurriendo a).

Necesitará SSH en su nodo maestro. Si está utilizando kubeadm> = 1.8, pase al 2.

1. Actualice Kubeadm, si es necesario. Estaba en 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. Realice una copia de seguridad de los certificados y claves antiguos de apiserver, apiserver-kubelet-client y 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. Genere nuevos certificados y claves de apiserver, apiserver-kubelet-client y 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. Copia de seguridad de archivos de configuración antiguos

$ 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. Genere nuevos archivos de configuración.

Aquí hay una nota importante. Si está en AWS, deberá pasar explícitamente el parámetro --node-name en esta solicitud. De lo contrario, obtendrá un error 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 en sus registros sudo journalctl -u kubelet --all | tail y el nodo maestro informará que es Not Ready cuando ejecute kubectl get nodes .

Asegúrese de reemplazar los valores pasados ​​en --apiserver-advertise-address y --node-name con los valores correctos para su entorno.

$ 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. Asegúrese de que su kubectl esté buscando en el lugar correcto sus archivos de configuración.

$ 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. Reinicia tu nodo maestro

$ sudo /sbin/shutdown -r now

1. Vuelva a conectarse a su nodo maestro y tome su token, y verifique que su nodo maestro esté "Listo". Copie el token en su portapapeles. Lo necesitará en el siguiente paso.

$ kubectl get nodes
$ kubeadm token list

Si no tiene un token válido. Puedes crear uno con:

$ kubeadm token create

El token debería verse como 6dihyb.d09sbgae8ph2atjw

1. SSH en cada uno de los nodos esclavos y vuelva a conectarlos al maestro

$ 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 el paso 9 para cada nodo de conexión. Desde el nodo maestro, puede verificar que todos los nodos esclavos se hayan conectado y estén listos con:

$ kubectl get nodes

Con suerte, esto te lleva a donde necesitas estar @davidcomeyne.

¡Muchas gracias @danroliver !
Definitivamente lo intentaré y publicaré mis hallazgos aquí.

@danroliver ¡Gracias! Lo probé en un antiguo clúster de un solo nodo, también lo hizo con los pasos hasta 7. Funcionó.

@danroliver funcionó para mí. Gracias.

No funcionó para mí, tuve que configurar un nuevo clúster. ¡Pero me alegro de haber ayudado a otros!

gracias @danroliver . esto funciona para mi
y mi versión de kubeadm es 1.8.5

Gracias @danroliver por armar los pasos. Tuve que hacer pequeñas adiciones a tus pasos. Mi clúster está ejecutando v1.9.3 y está en un centro de datos privado fuera de Internet.

En el maestro

1. Prepare un kubeadm config.yml .

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

1. Certificados de respaldo y archivos 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. Los comandos kubeadm en el maestro tenían --config config.yml así:

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. Crear token

En los minions

Tuve que moverme

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

¡Gracias @danroliver! Solo mi clúster de un solo nodo fue suficiente para seguir los pasos 1-6 (sin reiniciar) y luego enviar un SIGHUP a kube-apiserver . Acabo de encontrar la identificación del contenedor con docker ps y establezca la señal con docker kill -s HUP <container id> .

¡Muchas gracias @danroliver! En nuestro clúster de un solo maestro / múltiples trabajadores, hacer los pasos del 1 al 7 fue suficiente, no tuvimos que volver a conectar cada nodo trabajador al maestro (que fue la parte más dolorosa).

¡Gracias por este gran paso a paso, @danroliver! Me pregunto cómo se podría aplicar este proceso a un clúster multimaestro (bare metal, actualmente ejecutando 1.11.1), y preferiblemente sin tiempo de inactividad. Mis certificados aún no han expirado, pero estoy tratando de aprender a regenerarlos / renovarlos antes de que eso suceda.

@kcronin
por favor, eche un vistazo a este nuevo documento:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
Espero que ayude.

@danroliver : Muchas gracias, está funcionando.

No es necesario reiniciar los servidores.
Es suficiente recrear los pods del sistema kube (apiserver, schduler, ...) con estos dos comandos:

systemctl reiniciar kubelet
para i en $ (docker ps | egrep 'admin | controlador | programador | api | fron | proxy' | rev | awk '{print $ 1}' | rev);
docker stop $ i; hecho

Tuve que lidiar con esto también en un clúster 1.13, en mi caso, los certificados estaban a punto de caducar de manera ligeramente diferente
También se trata de una única instancia principal / de control en las instalaciones, por lo que no tuvo que preocuparse por la configuración de HA o las especificaciones de AWS.
No he incluido los pasos hacia atrás como los otros chicos han incluido arriba

Dado que los certificados no habían expirado, el clúster ya tenía cargas de trabajo que quería seguir trabajando
Tampoco tuve que lidiar con los certificados etcd en este momento, por lo que se han omitido

Entonces en un alto nivel tuve que

• En el maestro
  
  
  
  • Genere nuevos certificados en el maestro
  
  
  • Genere nuevos kubeconfigs con certificados integrados
  
  
  • Genere nuevos certificados de kubelet: cliente y servidor
  
  
  • Genere un nuevo token para los kubelets del nodo trabajador
  
  
• Para cada trabajador
  
  
  
  • Drene al trabajador primero en el maestro
  
  
  • ssh al trabajador, detenga el kubelet, elimine archivos y reinicie el kubelet
  
  
  • Descordón al trabajador del maestro
  
  
• En maestro al final
  
  
  
  • Eliminar 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

Creemos un nuevo token para los nodos que se vuelven a unir al clúster (después del reinicio de kubelet)

# On master
sudo kubeadm token create

Ahora para cada trabajador, uno a la vez

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

ssh al nodo trabajador

# 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

Volver a dominar y descordonar al trabajador

kubectl uncordon WORKER-NODE-NAME

Después de que se hayan actualizado todos los trabajadores, eliminar el token, caducará en 24 horas, pero eliminémoslo.

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

@pmcgrath Gracias por publicar esos pasos. Me las arreglé para seguirlos y renovar mis certificados, y obtener un clúster de trabajo.

Si está utilizando una versión de kubeadm anterior a 1.8, donde entiendo que la rotación de certificados # 206 se implementó (como una función beta ) o sus certificados ya expiraron, entonces deberá actualizar manualmente sus certificados (o volver a crear su clúster que parece que algunos (no solo @kachkaev) terminan recurriendo a).

Necesitará SSH en su nodo maestro. Si está utilizando kubeadm> = 1.8, pase al 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.

Aquí hay una nota importante. Si está en AWS, deberá pasar explícitamente el parámetro --node-name en esta solicitud. De lo contrario, obtendrá un error 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 en sus registros sudo journalctl -u kubelet --all | tail y el nodo maestro informará que es Not Ready cuando ejecute kubectl get nodes .

Asegúrese de reemplazar los valores pasados ​​en --apiserver-advertise-address y --node-name con los valores correctos para su entorno.

$ 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

Si no tiene un token válido. Puedes crear uno con:

$ kubeadm token create

El token debería verse como 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

Con suerte, esto te lleva a donde necesitas estar @davidcomeyne.

Esto es lo que necesito solo para 1.14.2 .. alguna pista sobre cómo

Tuve que lidiar con esto también en un clúster 1.13, en mi caso, los certificados estaban a punto de caducar de manera ligeramente diferente
También se trata de una única instancia principal / de control en las instalaciones, por lo que no tuvo que preocuparse por la configuración de HA o las especificaciones de AWS.
No he incluido los pasos hacia atrás como los otros chicos han incluido arriba

Dado que los certificados no habían expirado, el clúster ya tenía cargas de trabajo que quería seguir trabajando
Tampoco tuve que lidiar con los certificados etcd en este momento, por lo que se han omitido

Entonces en un alto nivel tuve 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

Creemos un nuevo token para los nodos que se vuelven a unir al clúster (después del reinicio de kubelet)

# On master
sudo kubeadm token create

Ahora para cada trabajador, uno a la vez

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

ssh al nodo trabajador

# 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

Volver a dominar y descordonar al trabajador

kubectl uncordon WORKER-NODE-NAME

Después de que se hayan actualizado todos los trabajadores, eliminar el token, caducará en 24 horas, pero eliminémoslo.

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

Sé que este problema está cerrado, pero tengo el mismo problema en 1.14.2 y la guía no da errores, pero no puedo conectarme al clúster y volver a emitir el token (me falla la autenticación)

Un clúster k8s creado con kubeadm v1.9.x experimentó el mismo problema ( apiserver-kubelet-client.crt expiró el 2 de julio) a la edad de v1.14.1 lol

Tuve que consultar 4 fuentes diferentes para renovar los certificados, regenerar los archivos de configuración y recuperar el simple clúster de 3 nodos.

@danroliver dio
[Renovación de certificados de clúster de Kubernetes] de IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

NOTA: IBM Financial Crimes Insight con Watson private funciona con k8s, nunca lo supe.

Problema con el paso 3 y el paso 5

El paso 3 NO debe tener la fase en el comando

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

El paso 5 debe usarse a continuación, kubeadm alpha no tiene kubeconfig all, esa es una fase de inicio de kubeadm en su lugar

# 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

en 1.15 hemos agregado una mejor documentación para la renovación del certificado:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Además, después de 1.15 kubeadm upgrade renovará automáticamente los certificados por usted.

Un clúster de k8s creado con kubeadm v1.9.x experimentó el mismo problema (apiserver-kubelet-client.crt expiró el 2 de julio) a la edad de v1.14.1 lol

las versiones anteriores a la 1.13 ya no son compatibles.
recomendamos encarecidamente a los usuarios que se mantengan al día con este proyecto en rápido movimiento.

Actualmente, el grupo de trabajo LongTermSupport está discutiendo para que las versiones de kubernetes sean compatibles durante períodos de tiempo más prolongados, pero establecer el proceso puede llevar un tiempo.

Gracias @pmorie .
Funciona para la versión 1.13.6 de kube

Solo un comentario y una solicitud de función: esta caducidad de certificado nos llegó en producción en nuestro clúster de Kubernetes 1.11.x esta mañana. Intentamos todo lo anterior (y los enlaces), pero encontramos numerosos errores, nos dimos por vencidos después de unas horas y nos quedamos completamente atascados con un gran grupo con mangueras. Afortunadamente, estábamos a unas 2 semanas de actualizar a Kubernetes 1.15 (y construir un nuevo clúster), por lo que terminamos creando un nuevo clúster 1.15 desde cero y copiando todos nuestros datos de usuario.

Ojalá hubiera habido alguna advertencia antes de que esto sucediera. Pasamos de un "clúster increíblemente estable" a una "pesadilla infernal completamente rota" sin previo aviso, y probablemente tuvimos nuestro peor tiempo de inactividad. Afortunadamente, era un viernes por la tarde en la costa oeste, por lo que tuvo un impacto relativamente mínimo.

De todo lo discutido anteriormente y en todos los boletos vinculados, lo único que habría hecho una gran
La diferencia para nosotros no se menciona: comience a mostrar una advertencia cuando los certificados caduquen pronto . (Por ejemplo, si usa kubectl y el certificado caducará en unas pocas semanas, ¡dígamelo!).

Perdón por tus problemas. Normalmente es responsabilidad del operador
para supervisar la caducidad de los certificados en disco. Pero estoy de acuerdo en que la falta
de fácil monitoreo puede causar problemas. Esa es una de las razones por las que agregamos un
comando para verificar la caducidad del certificado en kubeadm. Ver
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

También tenga en cuenta que después de 1.15 kubeadm renovará automáticamente los certificados en
potenciar. Lo que también anima a los usuarios a actualizar con más frecuencia.
El 20 de julio de 2019 a las 03:49, "William Stein" [email protected] escribió:

Solo un comentario y una solicitud de función: el vencimiento de este certificado nos golpeó
producción en nuestro clúster de Kubernetes 1.11.x esta mañana. Nosotros tratamos
todo lo anterior (y a los enlaces), pero encontró numerosos errores, se rindió después de un
pocas horas quedando completamente atascado con un gran grupo con manguera. Afortunadamente,
estábamos a unas dos semanas de actualizar a Kubernetes 1.15 (y construir
un nuevo clúster), por lo que terminamos creando un nuevo clúster 1,15 desde cero
y copiando todos nuestros datos de usuario.

Ojalá hubiera habido alguna advertencia antes de que esto sucediera. Nosotros solo
pasó de un "cúmulo increíblemente estable" a "un infierno completamente roto
nightmare "sin previo aviso, y probablemente tuvimos nuestro peor tiempo de inactividad.
Afortunadamente, era un viernes por la tarde en la costa oeste, así que relativamente
impactante.

De todo lo comentado anteriormente y en todos los tickets vinculados, lo único
eso hubiera hecho una masiva
diferencia para nosotros no se menciona: comience a mostrar una advertencia cuando los certificadosvan a caducar pronto . (Por ejemplo, si usa kubectl y el certificado es
caducará dentro de unas semanas, ¡por favor dímelo!).

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVDVREXWJWK3TUL52HS4DFVDVREXWJWKNM2 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@ neolit123 Gracias; Agregaremos algo a nuestra propia infraestructura de monitoreo para verificar periódicamente los próximos problemas de certificados, como se explica en su comentario.

@danroliver Muchas
Un punto que vale la pena mencionar son los certificados relacionados con "etcd", que deben renovarse de la misma manera. No es necesario volver a cargar la configuración, ya que se utiliza en archivos YAML de metadatos como referencias.

Para Kubernetes v1.14, encuentro que este procedimiento propuesto por @desdic es el más útil:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • Haga una copia de seguridad y vuelva a generar todos los 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>

• Haga una copia de seguridad y vuelva a generar todos los archivos kubeconfig:

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

• copiar nuevo admin.conf :

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

Para Kubernetes v1.14, este procedimiento me parece el más útil:

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

Creé la solución una vez que arreglé mi propio clúster ... esperaba que alguien más pudiera usarlo

@danroliver dio
[Renovación de certificados de clúster de Kubernetes] de IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

¡Bonito! Me pregunto cuándo se publicó esto. Ciertamente, me habría resultado útil cuando estaba pasando por esto.

Nota sobre tokens en K8s 1.13.x (posiblemente otras versiones de K8s)
Si ha vuelto a generar su certificado de CA ( /etc/kubernetes/pki/ca.crt ), es posible que sus tokens (consulte kubectl -n kube-system get secret | grep token ) tengan una CA antigua y deberán regenerarse. Los tokens con problemas incluían kube-proxy-token , coredns-token en mi caso (y en otros), lo que provocó que los servicios críticos del clúster no pudieran autenticarse con la API de K8.
Para regenerar tokens, elimine los antiguos y se volverán a crear.
Lo mismo ocurre con cualquier servicio que se comunique con la API de K8, como PV Provisioner, Ingress Controllers, cert-manager , etc.

¡Gracias por este gran paso a paso, @danroliver! Me pregunto cómo se podría aplicar este proceso a un clúster multimaestro (bare metal, actualmente ejecutando 1.11.1), y preferiblemente sin tiempo de inactividad. Mis certificados aún no han expirado, pero estoy tratando de aprender a regenerarlos / renovarlos antes de que eso suceda.

Hola @kcronin , ¿cómo lo resolviste con la configuración multimaestro? No sé cómo proceder con --apiserver-advert-addressya que tengo 3 IP y no solo una.

Gracias

@pmcgrath En caso de que tenga 3 maestros, ¿debo repetir los pasos en cada maestro? o cuál es el. caso

@SuleimanWA , puede copiar admin.conf over, así como el archivo CA, si CA fue regenerado.
Para todo lo demás, debe repetir los pasos para regenerar certificados (para etcd, kubelet, programador, etc.) en cada maestro.

@anapsix
Estoy ejecutando un clúster 1.13.x y un servidor informa 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] después de renovar los certificados ejecutando kubeadm alpha certs renew all .

Para regenerar tokens, elimine los antiguos y se volverán a crear.

¿A qué ficha se refiere en este caso? ¿Es el generado por kubeadm o cómo puedo eliminar el token?

-----ACTUALIZAR-----
Descubrí que es el secreto en sí. En mi caso, el controlador kube no estaba activo, por lo que el secreto no se generó automáticamente.

uso de la versión alta:

Los certificados kubeadm alpha renuevan todo

Cuando se desactiva el kubelet del primer nodo maestro (systemctl stop kubelet), otros nodos maestros no pueden comunicarse con CA en el primer nodo maestro. Esto resulta en el siguiente mensaje hasta que kubelet en el nodo maestro original vuelva a estar en línea:

kubectl obtener nodos
Error del servidor (InternalError): un error en el servidor ("") ha impedido que la solicitud se realice correctamente (obtener nodos)

¿Hay alguna manera de transferir el rol de CA a otros nodos maestros mientras el kublet en el nodo de CA original está inactivo?

@anapsix
Estoy ejecutando un clúster 1.13.x y un servidor informa 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] después de renovar los certificados ejecutando kubeadm alpha certs renew all .

Para regenerar tokens, elimine los antiguos y se volverán a crear.

¿A qué ficha se refiere en este caso? ¿Es el generado por kubeadm o cómo puedo eliminar el token?

-----ACTUALIZAR-----
Descubrí que es el secreto en sí. En mi caso, el controlador kube no estaba activo, por lo que el secreto no se generó automáticamente.

Hola, hice esta tarea pero no en la versión 1.13. ¿Puedo preguntar algunas cosas si ya lo ha hecho?
Así que básicamente haré:
Los certificados kubeadm alpha renuevan todo (que actualiza la carpeta pki / del certificado del plano de control en Masters).
kubeadm init fase kubeconfig para actualizar los archivos de configuración de kube. (Sobre amo y trabajador).
Reinicie kubelet en todos los nodos.

¿Todavía necesito crear un token y ejecutar la combinación en los nodos trabajadores? Si es posible, ¿puede compartir los pasos que realizó?