mirror of https://github.com/k3s-io/k3s
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
37 lines
1.8 KiB
37 lines
1.8 KiB
2 years ago
|
# Move the ServiceLB load-balancer controller into the K3s cloud provider
|
||
|
|
|
||
|
|
Date: 2022-09-29
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
K3s includes a stub cloud-provider the implements just enough node lifecycle functionality (the
|
||
|
|
`cloudprovider.Instances` interface) to get node addresses set properly, and clear the Uninitialized taint
|
||
|
|
that is added to nodes when they first join the cluster. The cloud-provider interface also has extension
|
||
|
|
points for load-balancer controllers, but we did not implement these, in favor of running a standalone
|
||
|
|
ServiceLB controller that is directly hooked into the core Wrangler controllers.
|
||
|
|
|
||
|
|
Because it doesn't make use of the existing load-balancer interface, the ServiceLB controller must implement
|
||
|
|
all the logic to watch Services, ensure that it's only handling services of the correct type and state, manage
|
||
|
|
finalizers, and so on. This would all be handled by core Kubernetes code if we implemented the
|
||
|
|
`cloudprovider.LoadBalancer` interface.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
We will move the ServiceLB code into the cloud-controller, as a backend for the LoadBalancer interface
|
||
|
|
implementation. Existing behavior for disabling node lifecycle functionality will be retained, such that users
|
||
|
|
can still use ServiceLB alongside other cloud-controller-managers that handle node lifecycle. Support for
|
||
|
|
customizing ServiceLB behavior via node labels will be retained.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
* K3s uses less resources when ServiceLB is disabled, as several core controllers are no longer started
|
||
|
|
unconditionally.
|
||
|
|
* The `--disable-cloud-controller` flag now disables the CCM's `cloud-node` and `cloud-node-lifecycle`
|
||
|
|
controllers that were historically the only supported controllers.
|
||
|
|
* The `--disable=servicelb` flag now disables the CCM's `service` controller.
|
||
|
|
* If the cloud-controller and servicelb are both disabled, the cloud-controller-manager is not run at all.
|