Gardener automates the full lifecycle of Kubernetes clusters as a service. Additionally, it has several extension points allowing external controllers to plug-in to the lifecycle. As a consequence, there are several configuration options for the various custom resources that are partially required.
This document describes the
When we use the terms “operator/administrator” we refer to both the people deploying and operating Gardener. Gardener consists out of four components:
gardener-apiserver, a Kubernetes-native API extension that serves custom resources in the Kubernetes-style (like
Shoots), and a component that contains multiple admission plugins.
gardener-controller-manager, a component consisting out of multiple controllers that implement reconciliation and deletion flows for some of the custom resources (e.g., it contains the logic for maintaining
gardener-scheduler, a component that assigns newly created
Shootclusters to appropriate
gardenlet, a component running in seed clusters and consisting out of multiple controllers that implement reconciliation and deletion flows for some of the custom resources (e.g., it contains the logic for reconciliation and deletion of
Each of these components have various configuration options.
gardener-apiserver uses the standard API server library maintained by the Kubernetes community, and as such it mainly supports command line flags.
The two other components are using so-called componentconfig files that describe their configuration in a Kubernetes-style versioned object.
The Gardener controller manager does only support one command line flag which should be a path to a valid controller-manager configuration file. Please take a look at this example configuration.
The Gardener scheduler also only supports one command line flag which should be a path to a valid scheduler configuration file. Please take a look at this example configuration. Information about the concepts of the Gardener scheduler can be found here
The Gardenlet also only supports one command line flag which should be a path to a valid gardenlet configuration file. Please take a look at this example configuration. Information about the concepts of the Gardenlet can be found here
After successful deployment of the four components you need to setup the system.
Let’s first focus on some “static” configuration.
gardenlet starts it scans the
garden namespace of the garden cluster for
Secrets that have influence on its reconciliation loops, mainly the
Internal domain secret, contains the DNS provider credentials (having appropriate privileges) which will be used to create/delete so-called “internal” DNS records for the Shoot clusters, please see this for an example.
Default domain secrets (optional), contain the DNS provider credentials (having appropriate privileges) which will be used to create/delete DNS records for a default domain for shoots (e.g.,
example.com), please see this for an example.
:warning: Please note that the mentioned domain secrets are only needed if you have at least one seed cluster that is not tainted with
Seeds with this taint don’t create any DNS records for shoots scheduled on it, hence, if you only have such seeds, you don’t need to create the domain secrets.
Alerting secrets (optional), contain the alerting configuration and credentials for the AlertManager to send email alerts. It is also possible to configure the monitoring stack to send alerts to an AlertManager not deployed by Gardener to handle alerting. Please see this for an example.
OpenVPN Diffie-Hellmann Key secret (optional), contains the self-generated Diffie-Hellmann key used by OpenVPN in your landscape, please see this for an example.
Global monitoring secrets (optional), contains basic authentication credentials for the Prometheus aggregating metrics for all clusters.
Apart from this “static” configuration there are several custom resources extending the Kubernetes API and used by Gardener. As an operator/administrator you have to configure some of them to make the system work.
As an end-user/stakeholder/customer you are using a Gardener landscape that has been setup for you by another team.
You don’t need to care about how Gardener itself has to be configured or how it has to be deployed.
Take a look at this document - it describes which resources are offered by Gardener.
You may want to have a more detailed look for