Project Gardener implements the automated management and operation of Kubernetes clusters as a service. Its main principle is to leverage Kubernetes concepts for all of its tasks.
Recently, most of the vendor specific logic has been developed in-tree. However, the project has grown to a size where it is very hard to extend, maintain, and test. With GEP-1 we have proposed how the architecture can be changed in a way to support external controllers that contain their very own vendor specifics. This way, we can keep Gardener core clean and independent.
This controller operates on the
OperatingSystemConfig resource in the
extensions.gardener.cloud/v1alpha1 API group. It supports CoreOS Container Linux and Flatcar Container Linux (“a friendly fork of CoreOS Container Linux”).
--- apiVersion: extensions.gardener.cloud/v1alpha1 kind: OperatingSystemConfig metadata: name: pool-01-original namespace: default spec: type: coreos units: ... files: ...
Please find a concrete example in the
After reconciliation the resulting data will be stored in a secret within the same namespace (as the config itself might contain confidential data). The name of the secret will be written into the resource’s
... status: ... cloudConfig: secretRef: name: osc-result-pool-01-original namespace: default command: /usr/bin/coreos-cloudinit -from-file=<path> units: - docker-monitor.service - kubelet-monitor.service - kubelet.service
The secret has one data key
cloud_config that stores the generation.
An example for a
ControllerRegistration resource that can be used to register this controller to Gardener can be found here.
Please find more information regarding the extensibility concepts and a detailed proposal here.
How to start using or developing this extension controller locally
You can run the controller locally on your machine by executing
make start. Please make sure to have the kubeconfig to the cluster you want to connect to ready in the
Feedback and Support
Please find further resources about out project here: