Skip to content

Introduction

What is Gardener

Gardener

Gardener provides Kubernetes clusters as a service and is itself fundamentally based on Kubernetes. We believe that Kubernetes is the preferred solution for managing cloudbased software, even when it involves Kubernetes itself. While the concept of selfhosting - running Kubernetes components within Kubernetes - is popular in the community, the Gardener project has developed a unique method to cater to our cloud platform's need to provision hundreds or even thousands of clusters.

Gardener uses a so called "Seed" cluster to host the control plane (API server, scheduler, controllers, etcd persistence, etc.) of an enduser's workload cluster (the so called "Shoot" cluster) as pods. This allows one "Seed" cluster to host the control planes of multiple "Shoot" clusters. This approach eliminates the need for dedicated hardware or virtual machines for the "Shoot" cluster control planes.

Therefore, the control plane is hosted in pods/containers watched by the "Seed" cluster, allowing them to be deployed with a replica count of 1 and scaled out only when the control plane is under pressure, eliminating the need for high availability (HA) reasons. This approach simplifies the deployments (standard Kubernetes deployment) and makes updates easier (standard Kubernetes rolling update).

The "Shoot" cluster is composed solely of worker nodes (with no control plane), allowing users to have full administrative access to their clusters. Moreover, on OSC, we manage a central cluster used to provision and operate all Garden clusters in an OSC region and provide internal central services such as monitoring, logging, and DNS.

Arch

For more details on the Gardener approach itself and general architecture, please refer to the upstream Gardener documentation.

API

The user can interact with the following APIs to manage the clusters and orchestrate applications:

The complete upstream Gardener API group reference can be found here.