Deploying the Gardener into a Kubernetes cluster
Similar to Kubernetes, Gardener consists out of control plane components (Gardener API server, Gardener controller manager, Gardener scheduler), and an agent component (Gardenlet). The control plane is deployed in the so-called garden cluster while the agent is installed into every seed cluster. Please note that it is possible to use the garden cluster as seed cluster by simply deploying the Gardenlet into it.
We are providing Helm charts in order to manage the various resources of the components. Please always make sure that you use the Helm chart version that matches the Gardener version you want to deploy.
Deploying the Gardener control plane (API server, controller manager, scheduler)
The configuration values depict the various options to configure the different components.
Please consult this document to get a detailed explanation of what can be configured for which component.
Also note that all resources and deployments need to be created in the
garden namespace (not overrideable).
After preparing your values in a separate
controlplane-values.yaml file, you can run the following command against your garden cluster:
helm install charts/gardener/controlplane \ --namespace garden \ --name gardener-controlplane \ -f gardener-values.yaml \ --wait
Deploying Gardener extensions
Gardener is an extensible system that does not contain the logic for provider-specific things like DNS management, cloud infrastructures, network plugins, operating system configs, and many more.
You have to install extension controllers for these parts. Please consult the documentation regarding extensions to get more information.
Deploying the Gardener agent (Gardenlet)
The Gardenlet requires a bootstrap token as well as a bootstrap kubeconfig in order to properly register itself with the Gardener control plane.
Prepare your values in a separate
- Create a bootstrap token secret in the
kube-systemnamespace of the garden cluster (see this and this).
- Create a bootstrap kubeconfig containing this token:
apiVersion: v1 kind: Config current-context: gardenlet-bootstrap@default clusters: - cluster: certificate-authority-data: <ca-of-garden-cluster> server: https://<endpoint-of-garden-cluster> name: default contexts: - context: cluster: default user: gardenlet-bootstrap name: gardenlet-bootstrap@default users: - name: gardenlet-bootstrap user: token: <bootstrap-token>
- Provide this bootstrap kubeconfig together with a desired name and namespace to the Gardenlet Helm chart values here:
gardenClientConnection: bootstrapKubeconfig: name: gardenlet-kubeconfig-bootstrap namespace: garden kubeconfig: | <bootstrap-kubeconfig>
- Define a name and namespace where the Gardenlet shall store the real kubeconfig it creates during the bootstrap process here:
gardenClientConnection: kubeconfigSecret: name: gardenlet-kubeconfig namespace: garden
- Define either
seedConfig(see this document
Now you are ready to deploy the Helm chart:
helm install charts/gardener/gardenlet \ --namespace garden \ --name gardenlet \ -f gardenlet-values.yaml \ --wait
:warning: A current prerequisite of Kubernetes clusters that are used as seeds is to have a pre-deployed
nginx-ingress-controller to make the Gardener work properly.
Moreover, there should exist a DNS record
<SEED-CLUSTER-DOMAIN> is the value of the
.dns.ingressDomain field of a Seed cluster resource (or the respective Gardenlet configuration).