Kubeadm: comment renouveler le certificat lorsque le certificat apiserver a expiré ?

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

@zalmanzhao as -tu réussi à résoudre ce problème ?

J'ai créé un cluster kubeadm v1.9.3 peu plus d'un an et cela fonctionnait bien pendant tout ce temps. Je suis allé mettre à jour un déploiement aujourd'hui et j'ai réalisé que j'étais exclu de l'API car le certificat avait expiré. Je ne peux même pas kubeadm alpha phase certs apiserver , car j'obtiens failure loading apiserver certificate: the certificate has expired (la version de kubeadm est actuellement 1.10.6 puisque je veux mettre à jour).

Ajouter insecure-skip-tls-verify: true à ~/.kube/config → clusters[0].cluser n'aide pas non plus – je vois You must be logged in to the server (Unauthorized) en essayant de kubectl get pods (https://github. com/kubernetes/kubernetes/issues/39767).

Le cluster fonctionne, mais il vit sa propre vie jusqu'à ce qu'il s'autodétruise ou que les choses soient réparées 😅 Malheureusement, je n'ai pas pu trouver de solution à ma situation en #206 et je me demande comment m'en sortir. Le seul document pertinent que j'ai pu extraire était un article de blog intitulé _'Comment modifier les certificats expirés dans le cluster kubernetes'_ , qui semblait prometteur à première vue. Cependant, cela ne convenait pas à la fin car ma machine principale n'avait pas /etc/kubernetes/ssl/ dossier /etc/kubernetes/pki/ ) - soit j'ai une version différente de k8s, soit j'ai simplement supprimé ce dossier sans m'en rendre compte.

@errordeveloper pourriez-vous s'il vous plaît recommander quelque chose ? J'adorerais réparer les choses sans kubeadm reset et sans récréation de la charge utile.

@kachkaev Avez-vous eu de la chance de renouveler les certificats sans réinitialiser le kubeadm ?
Si c'est le cas, merci de partager, j'ai le même problème ici avec k8s 1.7.4. Et je n'arrive pas à mettre à niveau (plan de mise à niveau kubeadm $) car l'erreur réapparaît en me disant que le certificat a expiré et qu'il ne peut pas répertorier les maîtres de mon 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

Malheureusement, j'ai finalement abandonné. La solution était de créer un nouveau cluster, de restaurer toute la charge utile dessus, de changer d'enregistrement DNS et enfin de supprimer le cluster d'origine 😭

Merci @kachkaev d' avoir répondu. Je vais quand même réessayer.
Si je trouve quelque chose, je m'assurerai de le poster ici...

Si vous utilisez une version de kubeadm antérieure à 1.8, où je comprends que la rotation des certificats #206 a été mise en place (en tant que fonctionnalité bêta ) ou que vos certificats ont déjà expiré, vous devrez alors mettre à jour manuellement vos certificats (ou recréer votre cluster qui il semble que certains (pas seulement @kachkaev) finissent par y recourir).

Vous devrez vous connecter en SSH à votre nœud maître. Si vous utilisez kubeadm >= 1.8, passez à 2.

1. Mettez à jour Kubeadm, si nécessaire. J'étais sur 1.7 auparavant.

$ 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. Sauvegardez les anciens certificats et clés apiserver, apiserver-kubelet-client et 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. Générez de nouveaux certificats et clés apiserver, apiserver-kubelet-client et 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. Sauvegarder les anciens fichiers de configuration

$ 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. Générez de nouveaux fichiers de configuration.

Il y a ici une remarque importante. Si vous êtes sur AWS, vous devrez transmettre explicitement le paramètre --node-name dans cette demande. Sinon, vous obtiendrez une erreur du type : 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 dans vos journaux sudo journalctl -u kubelet --all | tail et le nœud maître signalera qu'il s'agit de Not Ready lorsque vous exécutez kubectl get nodes .

Assurez-vous de remplacer les valeurs passées dans --apiserver-advertise-address et --node-name par les valeurs correctes pour votre environnement.

$ 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. Assurez-vous que votre kubectl cherche au bon endroit pour vos fichiers de configuration.

$ 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. Redémarrez votre nœud maître

$ sudo /sbin/shutdown -r now

1. Reconnectez-vous à votre nœud maître, récupérez votre jeton et vérifiez que votre nœud maître est « Prêt ». Copiez le jeton dans votre presse-papiers. Vous en aurez besoin à l'étape suivante.

$ kubectl get nodes
$ kubeadm token list

Si vous n'avez pas de token valide. Vous pouvez en créer un avec :

$ kubeadm token create

Le jeton devrait ressembler à 6dihyb.d09sbgae8ph2atjw

1. SSH dans chacun des nœuds esclaves et reconnectez-les au maître

$ 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. Répétez l'étape 9 pour chaque nœud de connexion. Depuis le nœud maître, vous pouvez vérifier que tous les nœuds esclaves sont connectés et sont prêts avec :

$ kubectl get nodes

J'espère que cela vous mènera là où vous devez être @davidcomeyne.

Merci beaucoup @danroliver !
Je vais certainement essayer cela et poster mes découvertes ici.

@danroliver Merci ! Je viens de l'essayer sur un ancien cluster à nœud unique, de même que les étapes jusqu'à 7. Cela a fonctionné.

@danroliver a travaillé pour moi. Merci.

N'a pas fonctionné pour moi, a dû mettre en place un nouveau cluster. Mais content que ça aide les autres !

merci @danroliver . ça marche pour moi
et ma version de kubeadm est la 1.8.5

Merci @danroliver d' avoir mis en place les étapes. J'ai dû faire de petits ajouts à vos étapes. Mon cluster exécute la version 1.9.3 et se trouve dans un centre de données privé hors Internet.

Sur le Maître

1. Préparez un kubeadm config.yml .

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

1. Sauvegarder les certificats et les fichiers de configuration

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. Les commandes kubeadm sur master avaient --config config.yml comme ceci :

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. Créer un jeton

Sur les serviteurs

j'ai dû déménager

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

Merci @danroliver ! Seul mon cluster à nœud unique, il suffisait de suivre les étapes 1 à 6 (pas de redémarrage) puis d'envoyer un SIGHUP à kube-apiserver . Je viens de trouver l'identifiant du conteneur avec docker ps et de définir le signal avec docker kill -s HUP <container id> .

Merci beaucoup @danroliver ! Sur notre cluster mono-maître/multi-workers, faire les étapes de 1 à 7 était suffisant, nous n'avons pas eu à reconnecter chaque nœud de travail au maître (ce qui était la partie la plus pénible).

Merci pour ce super pas à pas, @danroliver ! Je me demande comment ce processus pourrait être appliqué à un cluster multi-maître (bare metal, exécutant actuellement 1.11.1), et de préférence sans temps d'arrêt. Mes certificats n'ont pas encore expiré, mais j'essaie d'apprendre comment les régénérer/renouveler avant que cela ne se produise.

@kcronin
s'il vous plaît jeter un oeil à ce nouveau document:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
J'espère que cela pourra aider.

@danroliver : Merci beaucoup, ça marche.

Il n'est pas nécessaire de redémarrer les serveurs.
Il suffit de recréer les pods kube-system (apiserver, schduler, ...) par ces deux commandes :

systemctl redémarrer kubelet
pour i dans $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | rev | awk '{print $1}' | rev);
faire docker stop $i; terminé

J'ai dû gérer cela également sur un cluster 1.13, dans mon cas les certificats étaient sur le point d'expirer donc légèrement différents
Traitant également d'une seule instance maître\contrôle sur site, vous n'avez donc pas à vous soucier d'une configuration HA ou des spécificités d'AWS
N'ont pas inclus les marches arrière comme les autres gars l'ont inclus ci-dessus

Étant donné que les certificats n'avaient pas expiré, le cluster avait déjà des charges de travail que je voulais continuer à travailler
Je n'ai pas eu à gérer les certificats etcd non plus pour le moment, j'ai donc omis

Donc, à un niveau élevé, je devais

• Sur le maître
  
  
  
  • Générer de nouveaux certificats sur le maître
  
  
  • Générer de nouveaux kubeconfigs avec des certificats intégrés
  
  
  • Générer de nouveaux certificats kubelet - client et serveur
  
  
  • Générer un nouveau jeton pour le nœud de travail kubelets
  
  
• Pour chaque travailleur
  
  
  
  • Égoutter l'ouvrier d'abord sur le maître
  
  
  • ssh au travailleur, arrêtez le kubelet, supprimez les fichiers et redémarrez le kubelet
  
  
  • Déconnecter l'ouvrier sur le maître
  
  
• Sur le maître à la fin
  
  
  
  • Supprimer le jeton
  
  

# 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

Permet de créer un nouveau jeton pour les nœuds rejoignant le cluster (après le redémarrage de kubelet)

# On master
sudo kubeadm token create

Maintenant pour chaque travailleur - un à la fois

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

ssh vers le nœud de travail

# 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

Retour au maître et déconnecter le travailleur

kubectl uncordon WORKER-NODE-NAME

Une fois que tous les travailleurs ont été mis à jour - Supprimer le jeton - expirera dans 24h, mais débarrassons-nous en

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

@pmcgrath Merci d'avoir publié ces étapes. J'ai réussi à les suivre et à renouveler mes certificats, et à obtenir un cluster fonctionnel.

Si vous utilisez une version de kubeadm antérieure à 1.8, où je comprends que la rotation des certificats #206 a été mise en place (en tant que fonctionnalité bêta ) ou que vos certificats ont déjà expiré, vous devrez alors mettre à jour manuellement vos certificats (ou recréer votre cluster qui il semble que certains (pas seulement @kachkaev) finissent par y recourir).

Vous devrez vous connecter en SSH à votre nœud maître. Si vous utilisez kubeadm >= 1.8, passez à 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.

Il y a ici une remarque importante. Si vous êtes sur AWS, vous devrez transmettre explicitement le paramètre --node-name dans cette demande. Sinon, vous obtiendrez une erreur du type : 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 dans vos journaux sudo journalctl -u kubelet --all | tail et le nœud maître signalera qu'il s'agit de Not Ready lorsque vous exécutez kubectl get nodes .

Assurez-vous de remplacer les valeurs passées dans --apiserver-advertise-address et --node-name par les valeurs correctes pour votre environnement.

$ 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 vous n'avez pas de token valide. Vous pouvez en créer un avec :

$ kubeadm token create

Le jeton devrait ressembler à 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

J'espère que cela vous mènera là où vous devez être @davidcomeyne.

C'est ce dont j'ai besoin uniquement pour 1.14.2 .. des conseils sur la façon de

J'ai dû gérer cela également sur un cluster 1.13, dans mon cas les certificats étaient sur le point d'expirer donc légèrement différents
Traitant également d'une seule instance maître\contrôle sur site, vous n'avez donc pas à vous soucier d'une configuration HA ou des spécificités d'AWS
N'ont pas inclus les marches arrière comme les autres gars l'ont inclus ci-dessus

Étant donné que les certificats n'avaient pas expiré, le cluster avait déjà des charges de travail que je voulais continuer à travailler
Je n'ai pas eu à gérer les certificats etcd non plus pour le moment, j'ai donc omis

Donc, à un niveau élevé, je devais

* 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

Permet de créer un nouveau jeton pour les nœuds rejoignant le cluster (après le redémarrage de kubelet)

# On master
sudo kubeadm token create

Maintenant pour chaque travailleur - un à la fois

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

ssh vers le nœud de travail

# 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

Retour au maître et déconnecter le travailleur

kubectl uncordon WORKER-NODE-NAME

Une fois que tous les travailleurs ont été mis à jour - Supprimer le jeton - expirera dans 24h, mais débarrassons-nous en

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

Je sais que ce problème est fermé mais j'ai le même problème sur 1.14.2 et le guide ne donne aucune erreur mais je ne peux pas me connecter au cluster et réémettre le jeton (je reçois un échec d'authentification)

Un cluster k8s créé à l'aide de kubeadm v1.9.x a rencontré le même problème ( apiserver-kubelet-client.crt expiré le 2 juillet) à l'âge de v1.14.1 lol

J'ai dû me référer à 4 sources différentes pour renouveler les certificats, régénérer les fichiers de configuration et ramener le simple cluster à 3 nœuds.

@danroliver a donné de très bonnes instructions structurées, très proches du guide ci-dessous d'IBM.
[Renouvellement des certificats de cluster Kubernetes] d'IBM WoW ! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

REMARQUE : IBM Financial Crimes Insight avec Watson private est alimenté par k8, je ne l'ai jamais su.

Problème avec l'étape 3 et l'étape 5

L'étape 3 ne devrait PAS avoir la phase dans la commande

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

L'étape 5 devrait être utilisée ci-dessous, kubeadm alpha n'a pas kubeconfig all, c'est une phase d'initialisation kubeadm à la place

# 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

dans la version 1.15, nous avons ajouté une meilleure documentation pour le renouvellement des certificats :
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

De plus, après 1,15 kubeadm upgrade , les certificats seront automatiquement renouvelés pour vous !

Un cluster k8s créé à l'aide de kubeadm v1.9.x a rencontré le même problème (apiserver-kubelet-client.crt a expiré le 2 juillet) à l'âge de v1.14.1 lol

les versions antérieures à la 1.13 ne sont déjà pas prises en charge.
nous encourageons fortement les utilisateurs à suivre ce projet en évolution rapide.

actuellement, des discussions sont en cours au sein du groupe de travail LongTermSupport pour que les versions de kubernetes soient prises en charge pendant de plus longues périodes, mais l'établissement du processus peut prendre un certain temps.

Merci @pmorie .
Fonctionne pour Kube version 1.13.6

Juste un commentaire et une demande de fonctionnalité : cette expiration de certificat nous a frappés en production sur notre cluster Kubernetes 1.11.x ce matin. Nous avons tout essayé ci-dessus (et vers les liens), mais avons rencontré de nombreuses erreurs, avons abandonné après quelques heures, nous sommes complètement bloqués avec un gros cluster flexible. Heureusement, nous étions à environ 2 semaines de la mise à niveau vers Kubernetes 1.15 (et de la construction d'un nouveau cluster), nous avons donc fini par créer un nouveau cluster 1.15 à partir de zéro et copier toutes nos données utilisateur.

J'aurais vraiment aimé qu'il y ait eu un avertissement avant que cela ne se produise. Nous sommes passés d'un "cluster incroyablement stable" à "un cauchemar infernal complètement brisé" sans aucun avertissement, et avons probablement connu notre pire temps d'arrêt de tous les temps. Heureusement, c'était un vendredi après-midi sur la côte ouest, donc relativement peu impactant.

De tout ce qui a été discuté ci-dessus et dans tous les billets liés, la seule chose qui aurait fait un énorme
la différence pour nous n'est pas mentionnée: commencez à afficher un avertissement lorsque les certificats vont bientôt expirer . (Par exemple, si vous utilisez kubectl et que le certificat expire dans quelques semaines, dites-le-moi !).

Désolé pour vos ennuis. Normalement, c'est la responsabilité de l'exploitant
pour surveiller l'expiration des certificats sur le disque. Mais je suis d'accord que le manque
de surveillance facile peut causer des problèmes. C'est l'une des raisons pour lesquelles nous avons ajouté un
commande pour vérifier l'expiration du certificat dans kubeadm. Voir
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Veuillez également noter qu'après la version 1.15, kubeadm renouvellera automatiquement les certificats sur
améliorer. Ce qui encourage également les utilisateurs à mettre à niveau plus souvent.
Le 20 juillet 2019 03:49, "William Stein" [email protected] a écrit :

Juste un commentaire et une demande de fonctionnalité : cette expiration de certificat nous a frappés
production sur notre cluster Kubernetes 1.11.x ce matin. Nous avons essayé
tout ci-dessus (et aux liens), mais a frappé de nombreuses erreurs, a abandonné après un
quelques heures complètement coincé avec un gros cluster arrosé. Heureusement,
nous étions à environ 2 semaines de la mise à niveau vers Kubernetes 1.15 (et de la construction
un nouveau cluster) nous avons donc fini par créer un nouveau cluster 1.15 à partir de zéro
et en copiant toutes nos données d'utilisateur.

J'aurais vraiment aimé qu'il y ait eu un avertissement avant que cela ne se produise. Nous venons
est passé de « cluster incroyablement stable » à « complètement brisé infernal
cauchemar" sans aucun avertissement, et nous avons probablement connu notre pire temps d'arrêt.
Heureusement, c'était un vendredi après-midi sur la côte ouest, donc relativement peu
impactant.

De tout ce qui a été discuté ci-dessus et dans tous les billets liés, la seule chose
ça aurait fait un énorme
la différence pour nous n'est pas mentionnée: commencez à afficher un avertissement lorsque certsvont bientôt expirer . (Par exemple, si vous utilisez kubectl et que le certificat est
expirera dans quelques semaines, dites-le-moi s'il vous plaît !).

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKLODNC5WWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKLODNC5WWZHJFALOJKTDN5WW
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@neolit123 Merci; nous ajouterons quelque chose à notre propre infrastructure de surveillance pour vérifier périodiquement les problèmes de certification à venir, comme expliqué dans votre commentaire.

@danroliver Merci beaucoup pour votre réponse. Cela m'a fait gagner beaucoup de temps.
Un point qui mérite d'être mentionné est les certificats liés à "etcd", qui devraient être renouvelés de la même manière. Il n'est pas nécessaire de recharger la configuration puisqu'il est utilisé dans les fichiers de métadonnées YAML comme références.

Pour Kubernetes v1.14, je trouve cette procédure proposée par @desdic la plus utile :

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • sauvegarder et régénérer tous les certificats :
  
  

$ 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>

• sauvegardez et régénérez tous les fichiers kubeconfig :

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

• copier nouveau admin.conf :

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

Pour Kubernetes v1.14, je trouve cette procédure la plus utile :

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

J'ai créé le correctif une fois que mon propre cluster a été réparé. J'espérais que quelqu'un d'autre pourrait l'utiliser

@danroliver a donné de très bonnes instructions structurées, très proches du guide ci-dessous d'IBM.
[Renouvellement des certificats de cluster Kubernetes] d'IBM WoW ! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

Joli! Je me demande quand cela a été publié. J'aurais certainement trouvé cela utile lorsque je traversais cela.

Remarque sur les jetons dans K8s 1.13.x (éventuellement d'autres versions de K8s)
Si vous avez fini par régénérer votre certificat CA ( /etc/kubernetes/pki/ca.crt ), vos jetons (voir kubectl -n kube-system get secret | grep token ) peuvent avoir une ancienne CA et devront être régénérés. Les jetons en difficulté comprenaient kube-proxy-token , coredns-token dans mon cas (et d'autres), ce qui empêchait les services critiques de cluster de s'authentifier avec l'API K8s.
Pour régénérer les jetons, supprimez les anciens et ils seront recréés.
Il en va de même pour tous les services parlant à l'API K8s, tels que PV Provisioner, Ingress Controllers, cert-manager , etc.

Merci pour ce super pas à pas, @danroliver ! Je me demande comment ce processus pourrait être appliqué à un cluster multi-maître (bare metal, exécutant actuellement 1.11.1), et de préférence sans temps d'arrêt. Mes certificats n'ont pas encore expiré, mais j'essaie d'apprendre comment les régénérer/renouveler avant que cela ne se produise.

Salut @kcronin , comment avez-vous résolu avec la configuration multi-maîtres ? Je ne sais pas comment procéder avec --apiserver-advertise-addresscar j'ai 3 IP et pas une seule.

Merci

@pmcgrath Si j'ai 3 masters, dois-je répéter les étapes sur chaque master ? ou quel est le . Cas

@SuleimanWA , vous pouvez copier admin.conf , ainsi que le fichier CA, si CA a été régénéré.
Pour tout le reste, vous devez répéter les étapes pour régénérer les certs (pour etcd, kubelet, scheduler, etc.) sur chaque master

@anapsix
J'exécute un cluster 1.13.x et apiserver signale 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] après avoir renouvelé les certificats en exécutant kubeadm alpha certs renew all .

Pour régénérer les jetons, supprimez les anciens et ils seront recréés.

De quel jeton parlez-vous dans ce cas ? Est-ce que celui généré par kubeadm ou comment puis-je supprimer le jeton ?

-----METTRE À JOUR-----
J'ai compris que c'était le secret lui-même. Dans mon cas, le contrôleur kube n'était pas activé, le secret n'a donc pas été généré automatiquement.

utilisation de la version élevée：

kubeadm alpha certs renouvelle tout

Lorsque le kubelet du premier nœud maître est en panne (systemctl stop kubelet), les autres nœuds maîtres ne peuvent pas contacter CA sur le premier nœud maître. Cela entraîne le message suivant jusqu'à ce que kubelet sur le nœud maître d'origine soit remis en ligne :

kubectl obtenir des nœuds
Erreur du serveur (InternalError) : une erreur sur le serveur ("") a empêché la demande de réussir (obtenir des nœuds)

Existe-t-il un moyen de transférer le rôle CA vers d'autres nœuds maîtres pendant que le kublet sur le nœud CA d'origine est en panne ?

@anapsix
J'exécute un cluster 1.13.x et apiserver signale 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] après avoir renouvelé les certificats en exécutant kubeadm alpha certs renew all .

Pour régénérer les jetons, supprimez les anciens et ils seront recréés.

De quel jeton parlez-vous dans ce cas ? Est-ce que celui généré par kubeadm ou comment puis-je supprimer le jeton ?

-----METTRE À JOUR-----
J'ai compris que c'était le secret lui-même. Dans mon cas, le contrôleur kube n'était pas activé, le secret n'a donc pas été généré automatiquement.

Salut, j'ai fait cette tâche mais pas sur la version 1.13. Puis-je demander quelques petites choses si vous l'avez déjà fait?
Donc en gros je vais faire :
kubeadm alpha certs renouvelle tout (ce qui met à jour le dossier du plan de contrôle cert uber pki/ sur les maîtres).
kubeadm init phase kubeconfig pour mettre à jour les fichiers de configuration kube. (Sur Maître et ouvrier).
Redémarrez kubelet sur tous les nœuds.

Dois-je toujours créer un jeton et exécuter une jointure sur les nœuds de travail ? Si possible, pouvez-vous partager les étapes que vous avez effectuées ?