<p>Les certificats de phase alpha de kubeadm renouvellent tous devraient également mettre à jour les certificats dans les fichiers KubeConfig</p>

@MalloZup
bien sûr, mais veuillez noter que les phases de jointure sont une priorité élevée.

ça a l'air bien! Merci beaucoup.

Salut,

il y a encore une chose à propos de ce sujet.

kubeadm alpha phase kubeconfig all affiche ce message si des fichiers de configuration sont en place lors de l'exécution de la commande:

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

Il ne vérifie pas si les certificats sont expirés, donc à mon avis, up-to-date est trompeur.

Pour obtenir les certificats mis à jour dans les fichiers, il faut absolument supprimer les fichiers à l'avance, ce que le journal ressemble à:

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

Dans mon cas, je pensais que je vais bien, mais quelques jours plus tard, les pods statiques ne pouvaient pas communiquer en raison de certificats obsolètes.

Meilleures salutations
Andreas

Attribué à @MalloZup

@MalloZup : GitHub ne m'a pas permis d'attribuer les utilisateurs suivants: MalloZup.

Notez que seuls les membres de kubernetes et les collaborateurs du
Pour plus d'informations, veuillez consulter le guide du contributeur

salut @adoerler merci pour le problème. En ce qui concerne les informations trompeuses, j'ai envoyé un PR https://github.com/kubernetes/kubernetes/pull/73798.

J'examinerai le reste de la question une fois que j'aurai le temps. Merci pour l'heure et la précision du problème

@adoerler j'ai envoyé un DOC pr pour votre suggestion. N'hésitez pas à jeter un oeil à tia: rocket:
(https://github.com/kubernetes/website/pull/12579)

Salut @MalloZup ,

merci pour PR!

Il me manque une phrase sur les fichiers kubeconfig, car certs renew n'est qu'une partie du jeu.
Quelque chose comme:

Une fois les certificats renouvelés, n'oubliez pas de recréer les fichiers KubeConfig en utilisant kubeadm alpha phase kubeconfig ...

Merci. Je n'ai pas ajouté le document parce que je pensais qu'en fait nous pourrions renouveler également les fichiers kubeconfig. Le reste des pods de redémarrage que nous pouvons déléguer à l'utilisateur et écrire un document minimal. @fabriziopandini @lubomir @ereslibre Il me manque quelque chose sur cette implémentation? Tia

@MalloZup Je n'ai pas une connaissance approfondie du fonctionnement du renouvellement des certificats.

Personnellement, je voudrais clarifier un peu l'historique général avant de prendre des mesures - y compris ce qui est proposé ci-dessus -:

• ce qui doit être géré par kubeadm alpha phase certs renew
• ce qui doit être géré automatiquement pendant kubeadm upgrade
• ce qui doit être documenté (et géré par les utilisateurs)
• comment cela s'applique aux clusters HA
• comment cela est impacté par les variantes de cluster (comme par exemple, externe etcd, externe CA)
• etc.

mais je laisse le dernier mot à des personnes plus compétentes que moi dans ce domaine

Je pense que nous devrions réserver du temps à une réunion pour discuter de ce que devrait être notre politique de renouvellement des certificats recommandée. la page sur la gestion des certificats peut nécessiter des détails supplémentaires:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

et nous devons écrire un petit guide, au moins pour les clusters à plan de contrôle unique.

ce que les utilisateurs ont fait, c'est de comprendre les choses par eux-mêmes:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ ce commentaire et celui ci-dessus contiennent des guides créés par l'utilisateur.

c'est un signe que nous devons ajouter un guide officiel.
cc @timothysc @liztio

/ assign @ereslibre

Notre cluster avec quelques centaines d'utilisateurs est actuellement bloqué. Puis-je avoir un guide très rapide sur ce qu'il faut faire avec un certificat expiré?

@ dimm0

ce que les utilisateurs ont fait, c'est de comprendre les choses par eux-mêmes:
# 581 (commentaire)
^ ce commentaire et celui ci-dessus contiennent des guides créés par l'utilisateur.

ce sont les seuls guides que nous avons ATM.

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

Flags:
  -h, --help   help for phase

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

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

en 1.13, les phases init sont passées à la commande init parent:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

en 1.12, le drapeau devrait être là:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 ne sera bientôt plus supporté.

suppression du cycle de vie / étiquette active.
passage à 1.15.

les documents possibles mettent à jour les idées ici:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
Question: en 1.14 avec master HA, suffit-il de suivre le https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 sur un seul master, ou il faut à nouveau rejoindre les maîtres secondaires pour récupérer les certificats?

rejoindre les nœuds secondaires du plan de contrôle semble être une option rapide et viable dans 1,14.
nous n'avons pas encore de documentation en termes de rotations de certificats HA.
(sans oublier que nous devons encore ajouter des étapes appropriées comme https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139 l'a fait).

--Experimental-upload-certs ne fournit-il pas la base d'une solution plus simple à la rotation des certificats dans HA?

une façon de faire la rotation des certificats HA est:

• sur un seul nœud de plan de contrôle, suivez les étapes mentionnées ci-dessus pour mettre à jour ses certificats
• sur le même appel de nœud CP:

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

stocker la clé de certificats.

kubeadm token create --print-join-command

stockez la commande de jointure avec le jeton.

rejoignez le reste des nœuds du plan de contrôle à l'aide du jeton et de la clé de certificats, un par un en utilisant --certs-key .... --experimental-control-plane-join

pour les ouvriers: vidangez, rejoignez en utilisant le nouveau jeton, uncordon, un par un.

supprimez éventuellement les jetons résultants.

@ neolit123
Dans un cluster à 3 maîtres, au moment où nous changeons les certificats sur le maître "primaire", etcd cessera de fonctionner, car les certificats sont modifiés (et le quorum doit être au minimum de 51%)? Si tel est le cas, peut-être devons-nous en quelque sorte boucler les 2 maîtres secondaires et alors seulement changer les certificats? Le "cordon maître" est-il possible?

Je ne suis pas un expert ici, mais je ne pense pas que la copie automatique du certificat devrait entrer dans cette image

Les certificats de copie automatique gèrent CA, front-proxy-CA, etcd-CA (avec 10 ans de TTL) et clé SA (sans TTL)

La commande de renouvellement de certificat touche tous les autres certificats (avec TTL d'un an), qui sont différents selon les maîtres.
AFAIK, actuellement, il n'y a rien qui gère le renouvellement des certificats pour les fichiers kubeconfig

ok, je n'ai pas considéré ce que fait réellement la "copie de certificats" ici.
nous devons écrire des documents de rotation de certificat appropriés, de toute façon.

/attribuer
/ cycle de vie actif

Je commence à travailler sur ce problème.
Il y a différents points à traiter (_ mis à jour le 14 mai 2019_)

• Même avec la rotation des certificats activée, kubelet.conf pointe vers des certificats obsolètes (déjà suivis par https://github.com/kubernetes/kubeadm/issues/1317)
• La rotation des certificats ne met pas à jour les certificats apiserver / etcd / front-proxy-client (corrigé par https://github.com/kubernetes/kubernetes/pull/76862)
• Les certificats de phase alpha de la commande kubeadm renouveler tout ne mettent pas à jour les fichiers KubeConfig (corrigé par https://github.com/kubernetes/kubernetes/pull/77180)
• Documentation sur le renouvellement des certificats (avec plus de détails sur l'endroit où la commande doit être exécutée, quand, kubeconfig, HA)

Et je les aborderai tous dans des PR séparés

@ neolit123 @fabriziopandini
les étapes que vous avez mentionnées sont-elles également pour la rotation du certificat CA? Cela peut-il également être documenté? Qu'en est-il de la rotation des clés privées, y compris celle de l'autorité de certification?

La rotation https://github.com/kubernetes/kubeadm/issues/1350
Ce numéro se concentre uniquement sur les certificats signés

@fabriziopandini Je cherchais à fermer ce ticket aujourd'hui car vous avez pu envoyer des PR pour les pièces de renouvellement. le billet doit-il être fermé?

Même avec la rotation des certificats activée, kubelet.conf pointe vers des certificats obsolètes (déjà suivis par # 1317)

oui, cela est suivi dans un numéro séparé, nécessite éventuellement une discussion / documentation en termes de solutions de contournement que nous devrions fournir.

La rotation des certificats ne met pas à jour les certificats apiserver / etcd / front-proxy-client (corrigé par kubernetes / kubernetes # 76862)

La commande kubeadm alpha phase certs renew all ne met pas à jour les fichiers KubeConfig (corrigé par kubernetes / kubernetes # 77180)

Documentation sur le renouvellement des certificats (avec plus de détails sur l'endroit où la commande doit être exécutée, quand, kubeconfig, HA)

les 3 ci-dessus doivent être effectués.

/Fermer
Comme indiqué ci-dessus, la plupart des travaux sont déjà terminés; le bit manquant est suivi dans un numéro séparé / dédié

@fabriziopandini : Clôture de ce numéro.

Quelqu'un peut-il m'expliquer comment la partie "Même avec la rotation des certificats activée, kubelet.conf pointe vers des certificats obsolètes" a-t-elle été traitée? Le seul problème lié qui mentionne cela a été explicitement fermé en faveur d'un autre problème qui est fermé par "Je ne sais pas si c'est un problème, alors ouvrez un nouveau ticket si c'est le cas".
Je suis sur 1.16 et je ne vois aucun renouvellement à kubelet.conf avec sudo kubeadm alpha certs renew all . Que manque-t-il? @ neolit123

un bref récapitulatif d'une très très longue discussion.

1. rotation des certificats pour tous les certificats mais kubelet.conf est maintenant géré par kubeadm alpha cert renouveler.
2. la rotation des certificats pour kubelet.conf sera gérée par kubelet lui-même (sauf si l'utilisateur se désiste de la rotation automatique des certificats)

Ce deuxième point fonctionne déjà à partir d'aujourd'hui pour tous les nœuds sauf celui où vous exécutez kubeadm init; https://github.com/kubernetes/kubernetes/pull/84118 va résoudre ce problème

@fabriziopandini Merci pour cela, c'est logique.

Pour toute autre personne confrontée au problème des certificats dans kubelte.conf qui sont obsolètes entre maintenant et lorsque ce qui précède est corrigé, j'ai trouvé cet article utile:

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

Sur les nœuds créés avec kubeadm init, avant la version 1.17 de kubeadm, il existe un bogue où vous devez modifier manuellement le contenu de kubelet.conf. Une fois kubeadm init terminé, vous devez mettre à jour kubelet.conf pour qu'il pointe vers les certificats clients kubelet pivotés, en remplaçant client-certificate-data et client-key-data par:

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

@AndrewSav Merci pour cela. J'ai utilisé l'opérateur promethes pour surveiller le cluster. J'ai récemment reçu une alerte "Le certificat d'API Kubernetes expire dans moins de 7 jours", je pense que c'est lié à ce problème. J'ai mis à jour le contenu de kubelet.conf sur les nœuds maîtres. Mais je reçois toujours l'alerte. Avez-vous des suggestions? Tks.

@tannh si vous avez installé le cluster avec kubeadm, utilisez kubeadm pour vérifier l'expérience des certificats. Sinon, votre problème n'est probablement pas lié.

Sur les nœuds créés avec kubeadm init, avant la version 1.17 de kubeadm, il existe un bogue où vous devez modifier manuellement le contenu de kubelet.conf. Une fois kubeadm init terminé, vous devez mettre à jour kubelet.conf pour qu'il pointe vers les certificats clients kubelet pivotés, en remplaçant client-certificate-data et client-key-data par:

cela figurera également dans les notes de publication de la version 1.17.

@adoerler J'utilise toujours l'ancienne version de kubeadm, comment puis-je mettre à jour kubelet.conf, admin.con, ... etc, après le renouvellement du certificat?

J'ai lancé "kubeadm alpha certs renew all", qui a généré de nouveaux certificats, puis j'ai besoin de modifier tous les .conf sous / etc / kubernetes, comment? où exactement doivent-ils pointer?
et en cas de nœuds multi-maîtres, dois-je exécuter la commande dans tous les maîtres?

Salut @SuleimanWA ,

Je ne peux pas vous dire quoi faire sur un env multi master, je n'ai eu qu'un seul master dans ma configuration.

Voici ce que j'ai fait:

Tout d'abord, assurez-vous de déplacer les fichiers de configuration existants, car les fichiers existants ne seront pas écrasés!

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

puis mettez à jour ces fichiers:

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

Pour appliquer les nouveaux certificats dans les pods système statiques, le moyen le plus simple pour moi était de simplement redémarrer le serveur maître.

N'oubliez pas de copier client-certificate-data et client-key-data de /etc/kubernetes/admin.conf à votre .kube/config local.

J'espère que cela t'aides

Andreas

Une idée comment exécuter cette commande sur 1.14.10? Tout ce que je reçois, c'est:

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

Ensuite, les documents disent:
kubeadm alpha phase kubeconfig all
et j'obtiens:
This command is not meant to be run on its own. See list of available subcommands.

Merci

Salut @provgregoryabdo ,

quelle est votre sortie kubeadm version ?

BR Andreas

@provgregoryabdo les commandes phase déplacées hors de l'alpha et vers l'initialisation dans les versions ultérieures afin que vous puissiez utiliser quelque chose comme

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

@adoerler merci pour l'aide!