Reasons to run cloud controller manager as daemonset?

[Sven Nebel]

Hi!

I wonder, what are the historical reasons for the cloud provider to be run as a daemonset, example.

I can see some providers such as AWS still seem to be running (or have run) in daemonset mode, see.

While others, such as GCP, seem to have move over, see.

I am guessing it is related to the in-tree/kube-controller-manager mode?

Thanks in advance.

[Walter Fender]

The referenced GCP code is from the kube-up installer.

It assumes that control plane components will be statically installed rather than being scheduled.

Without the scheduler the concept of DaemonSet is essentially meaningless.

I suspect you're right that at some level this is related to the CCM's KCM history.

I'm not an AWS expert but I suspect it has to do with a desire for control plane components to have HA.

CCM like the KCM uses leader election when there are multiple instances running to ensure HA.

1 instance is the current leader and the rest of the instances should be in hot stand-by mode.

It is also desirable to ensure that each CCM instance is running on a different Node.

My guess is DaemonSet was seen as a quick and convenient way to achieve this.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cloud-provider" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cloud...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cloud-provider/058f77da-1a69-47b3-8509-d39341a022adn%40googlegroups.com.

[Sven Nebel]

Thank you for your response!