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 ContainerRuntime resource in the extensions.gardener.cloud/v1alpha1 API group.
It manages objects that are requesting (.spec.type=gvisor) to enable the gVisor container runtime sandbox for a worker pool of a shoot cluster.
The ContainerRuntime can be configured in the shoot manifest in .spec.povider.workers[].cri.containerRuntimes an example can be found here:
kind: Shoot
apiVersion: core.gardener.cloud/v1beta1
metadata:
name: gvisor-shoot
namespace: garden-local
spec:
...
provider:
workers:
- name: worker-xyz
...
cri:
name: containerd
containerRuntimes:
- type: gvisor
...GVisor can be configured with additional configuration flags by adding them to the configFlags field in the providerConfig. Right now we only allow the "net-raw" flag to be set. All other flags are ignored.
...
- type: gvisor
providerConfig:
apiVersion: gvisor.os.extensions.gardener.cloud/v1alpha1
kind: GVisorConfiguration
configFlags:
"net-raw" "true"
...
...Based on the configuration in the shoot manifest the ContainerRuntime resource is created:
---
apiVersion: extensions.gardener.cloud/v1alpha1
kind: ContainerRuntime
metadata:
name: my-container-runtime
spec:
binaryPath: /var/bin/containerruntimes
type: gvisor
providerConfig:
apiVersion: gvisor.runtime.extensions.config.gardener.cloud/v1alpha1
configFlags:
net-raw: "true"
kind: GVisorConfiguration
workerPool:
name: worker-ubuntu
selector:
matchLabels:
worker.gardener.cloud/pool: worker-xyzYou 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 ./dev/kubeconfig file.
Static code checks and tests can be executed by running make verify. We are using Go modules for Golang package dependency management and Ginkgo/Gomega for testing.
Feedback and contributions are always welcome. Please report bugs or suggestions as GitHub issues or join our Slack channel #gardener (please invite yourself to the Kubernetes workspace here).
Please find further resources about out project here: