Cleanup external CA mode

[fabriziopandini]

While testing v1.13 we discovered a regression in certs phases for sparse CA that was fixed by kubernetes/kubernetes#71232

However, there is room for improving the current implementation as per comment kubernetes/kubernetes#71232 (review), but this requires a little bit of more thinking.

[seh]

Also pertinent: #1276.

[fabriziopandini]

@seh
kubernetes/kubernetes#71232 merged, so now at head certificate management should support sparse certificates scenarios. Could you kindly give a feedback if all the cases are addressed?

[seh]

Could you kindly give a feedback if all the cases are addressed?

It's working well for my case, which is probably unusual: I run in "external etcd mode" and the faux "external front proxy mode," in that I create those keys and certificates myself and place them on the master machines; problems there were what motivated #807 and #918, both solved now.

I had been creating all the certificates myself, avoiding the "certs" phase altogether. Now I'm taking advantage of kubeadm init's improvements and allowing it to generate the API server certificates. Doing so allows me to run my master machines in an auto-scaling group, rather than creating each one as a "pet" with an accompanying network interface with a predetermined IP address (and hence a predetermined node name). Since I don't need to know the IP address ahead of time to create the API server certificate myself, I can let my cloud environment create the network interface, query the assigned IPv4 DNS name at boot time, feed that into kubeadm init --node-name, and let kubeadm's "certs" phase use that node name in the API server certificate.

On that note, a diversion: I've noticed that the kubelet now logs a message periodically about overriding the cloud provider-supplied hostname with the hostname specified via the --hostname-override flag. That means that the kubelet would probably get the right hostname (per kubernetes/kubernetes#64659, kubernetes/kubernetes#64661, and kubernetes/website#8873), but kubeadm init needs that overridden hostname first, as it uses a more naïve way to determine a default node name. It seems like a chicken-and-egg problem; once the kubelet is running with a cloud provider, it can figure out the right node name it should use, but before the kubelet runs with a cloud provider, kubeadm init has to choose a node name and then reconfigure the kubelet.

[fabriziopandini]

@seh good to know the certs part is working, so I'm closing the issue
/close

For the kubelet part eventually let's move the discussion to a separated issue, even if at first sight this is more a kubelet/cloud provider issue than a kubeadm issue.

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

@seh good to know the certs part is working, so I'm closing the issue
/close

For the kubelet part eventually let's move the discussion to a separated issue, even if at first sight this is more a kubelet/cloud provider issue than a kubeadm issue.

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.

[spiffxp]

/milestone clear