Control plane in k3d #255
Control plane in k3d #255
Conversation
|
The CI cleanup is missing (in scripts). Without it we get errors like these from the runners: |
|
Why do we need k3d in the mini-lab if we already have kind for the same use-case? |
k3d will be used in the autonomous control plane for hosting the initial metal-stack and gardener components. |
#254 is focused on running k3s on the host for the control plane. Are you now looking at the option of running k3s in a container instead of on the host? |
No, with this PR @qrnvttrl only ensures that all components still work in k3s |
I previously managed Metal-Stack and Gardener on k3s for a client without any issues, which isn't surprising given that k3s passes the Kubernetes conformance tests. On the other hand, if @qrnvttrl is switching the mini-lab from kind to k3d, I would prefer that over introducing a new flavor. |
Description
#254
With this PR a new MINI_LAB_FLAVOR "k3s" is added.
Enabling this flavor, deploys the metal-stack and gardener control plane in k3d (k3s in docker, one docker container providing a complete k3s setup)
We use 1 server (control plane in k3s) and 1 agent (worker node in k3s), because with only one node the pod limit is exceeded. The traefik and servicelb load balancers provided by k3s are disabled because gardener comes with its own istio ingress gateway, which collides with traefik and servicelb.