kubeadm alpha certs renew all should give a msg tell user to restart components

[zgfh]

What keywords did you search in kubeadm issues before filing this one?

#1540
#2186
#2185

Is this a BUG REPORT or FEATURE REQUEST?

FEATURE REQUEST

Versions

kubeadm version (use kubeadm version):
1.19.2
Environment:

• Kubernetes version (use kubectl version): 1.19.2
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release): centos7.6
• Kernel (e.g. uname -a):
• Others:

What happened?

What you expected to happen?

after run kubeadm alpha certs renew all,user need restart all components to make cert work
we should tell user what need to do ,like:

renew all cert done.
now, you need restart apiserver,kube-controller,schedule to make certs work
if you use docker, you can run: systemctl restart docker

I also find when I upgrade same version with kubeadm upgrade apply v1.19.2 --certificate-renewal=true
it skip renew certs, I think it will be better if we change to update certs and restart related pods

...
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Current and new manifests of kube-apiserver are equal, skipping upgrade
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Current and new manifests of kube-controller-manager are equal, skipping upgrade
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Current and new manifests of kube-scheduler are equal, skipping upgrade
...

How to reproduce it (as minimally and precisely as possible)?

Anything else we need to know?

[neolit123]

I also find when I upgrade same version with kubeadm upgrade apply v1.19.2 --certificate-renewal=true
it skip renew certs, I think it will be better if we change to update certs and restart related pods

this is debatable, i think we should only renew certs if the upgrade happened.

after run kubeadm alpha certs renew all,user need restart all components to make cert work
we should tell user what need to do ,like:

this seems like a good idea, but we should adjust the message here:

Done renewing certificates. You must restart the kube-apiserver, kube-controller-manager and kube-scheduler, so that they can use the new certificates.

this section of the docs should also include a note that component restart is required.
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#automatic-certificate-renewal

[zgfh]

this is debatable, i think we should only renew certs if the upgrade happened.

if we only renew certs, It will be dangerous if the user don't know to restart
I have a idea, when we renew certs, we add or update a annotations xx-certificates-expire-time: "2020-09-27T18:24:50Z" ,it will make pod restart

[SataQiu]

/assign @zgfh

[neolit123]

if we only renew certs, It will be dangerous if the user don't know to restart
I have a idea, when we renew certs, we add or update a annotations xx-certificates-expire-time: "2020-09-27T18:24:50Z" ,it will make pod restart

i'd prefer if we don't renew certificates if component upgrade was skipped, because the primary purpose of the upgrade command is to upgrade. the separate utility to renew on demand is exposed for a reason.

i think kubernetes/kubernetes#95134 is all we can do here for now and that PR is LGTM/approved.

thanks!
/close

[k8s-ci-robot]

@neolit123: Closing this issue.

In response to this:

if we only renew certs, It will be dangerous if the user don't know to restart
I have a idea, when we renew certs, we add or update a annotations xx-certificates-expire-time: "2020-09-27T18:24:50Z" ,it will make pod restart

i'd prefer if we don't renew certificates if component upgrade was skipped, because the primary purpose of the upgrade command. the separate utility to renew on demand is exposed for a reason.

i think kubernetes/kubernetes#95134 is all we can do here for now and that PR is LGTM/approved.

thanks!
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.