Choosing a Shoot Control Plane in Gardener: Managed vs Self‑Managed Options

Decision Context

When provisioning a Shoot cluster with Gardener, the operator must decide how the control plane will be instantiated. Gardener supports two fundamentally different paths:

• Managed control plane – the API server and etcd are provisioned by a cloud provider’s managed Kubernetes service (EKS on AWS, GKE on GCP, AKS on Azure).
• Self‑managed control plane – Gardener deploys the API server and etcd as pods on dedicated worker nodes within the seed cluster (Kubelet‑on‑Worker).

The choice impacts operational overhead, customization, SLA guarantees, and the footprint of the Gardener installation.

What Is a Shoot Control Plane?

A Shoot control plane is the set of Kubernetes components that provide the cluster’s API surface. In Gardener, the control plane is abstracted as a Shoot.spec.provider.controlPlane block. The block can contain a type field that dictates the provisioning strategy:

spec:
  provider:
    controlPlane:
      type: "managed"   # or "selfManaged"

When type: managed, Gardener hands off API server and etcd creation to the cloud provider’s native service. When type: selfManaged, Gardener runs the components as Kubernetes pods.

Managed vs Self‑Managed Options

Below is a compact comparison of the two strategies, focusing on the most common decision points for operators.

Feature	Managed (EKS/GKE/AKS)	Self‑Managed (Kubelet‑on‑Worker)
Operational Overhead	Low – API server, etcd, networking, upgrades handled by provider	High – Gardener must create, backup, upgrade etcd and API server
Customization	Limited – only provider‑exposed flags	Full – can set any API server flag, etcd image, storage class
SLA & Reliability	Provider SLA (99.95%+), built‑in high availability	Operator‑defined HA (e.g., 3 replicas, etcd cluster)
Vendor Lock‑In	High – tied to provider’s API and networking model	Low – runs on any seed node, independent of cloud provider
Footprint	Minimal – no additional pods in seed cluster	Increases seed cluster size (control‑plane pods + etcd)
Backup & Restore	Managed by provider (snapshot, point‑in‑time)	Operator must implement etcd backups (e.g., Velero, etcd‑snapshot)
Upgrade Path	Provider‑managed – automatic or manual upgrade cycles	Operator must plan etcd & API server upgrades, coordinate with seed upgrades
Cost	Pay‑as‑you‑go for managed service	Only seed node resources; no separate managed service cost

Trade‑Off Analysis

• Operational Simplicity – Managed control planes are ideal when the operator wants to delegate day‑to‑day maintenance. The seed cluster remains lean, and Gardener’s operator code stays smaller.
• Customization Needs – If the cluster requires custom API server flags (e.g., --authorization-mode=RBAC tweaks, admission controller configuration, or a non‑standard etcd image), a self‑managed control plane is necessary.
• Reliability Expectations – Providers offer high‑availability and disaster‑recovery features out of the box. Self‑managed setups need explicit HA design (e.g., 3 API server replicas, etcd quorum) and robust backup scripts.
• Cost & Footprint – Managed services incur additional charges but keep the seed cluster small. Self‑managed control planes are cheaper in terms of cloud usage but add pods to the seed, potentially requiring more worker nodes.
• Vendor Lock‑In – Managed control planes tie the Shoot to a specific cloud provider. Self‑managed control planes can be deployed on any seed that supports the required Kubernetes version.

Concrete Implementation Example

Below is a minimal Shoot YAML that requests a managed control plane on AWS EKS. Replace placeholder values with your environment specifics.

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
metadata:
  name: example-shoot
  namespace: garden
spec:
  region: us-east-1
  seed: my-aws-seed
  networking:
    type: calico
    pods:
      cidr: 10.250.0.0/16
    services:
      cidr: 10.250.100.0/24
  provider:
    type: aws
    controlPlane:
      type: managed
      kubernetesVersion: "1.28"
    workers:
    - name: default
      machine:
        type: m5.large
      maximum: 3
      minimum: 1

When the Gardener operator processes this Shoot, it will create an EKS cluster named example-shoot in the specified region, provision the API server and etcd via EKS, and attach the worker nodes as defined.

Verifying the Control Plane Type

After creation, you can confirm the provisioning path by inspecting the Shoot’s status and provider block.

1. Check the Shoot resource (requires cluster‑admin rights on the garden namespace):

   kubectl -n garden get shoot example-shoot -o yaml | grep -A3 'controlPlane'

2. Look for the type field – it should read managed for EKS or selfManaged for Kubelet‑on‑Worker. Example output snippet:

provider:
  controlPlane:
    type: managed
    kubernetesVersion: "1.28"

Inspect Gardener operator logs for the provisioning step. The log line will contain Provisioning managed control plane or Provisioning self‑managed control plane.

Validation Checklist

• Confirm the type field matches the desired strategy.
• For managed control planes, run aws eks describe-cluster or gcloud container clusters describe to verify the cluster exists.
• For self‑managed control planes, list the control‑plane pods: kubectl -n garden get pods -l gardener.cloud/role=controlplane. You should see API server and etcd pods running on seed nodes.
• Check the API server endpoint: kubectl config view -o jsonpath='{.clusters[?(@.name=="example-shoot")].cluster.server}' should return the correct URL.
• Verify etcd backups if using self‑managed: ensure a backup job (e.g., Velero) is scheduled and a snapshot exists.

Limitations & Practical Notes

• Managed control plane support is limited to cloud providers that Gardener integrates with (AWS, GCP, Azure). If your seed is on a different provider, self‑managed is the only option.
• Self‑managed control planes increase the seed’s resource usage. Plan for at least one dedicated node per control‑plane pod, plus etcd replicas.
• Upgrading a self‑managed control plane requires careful version alignment between the API server, etcd, and Gardener operator. Follow Gardener’s upgrade documentation to avoid version drift.
• Vendor lock‑in is a real concern for managed control planes. If you anticipate moving the Shoot to a different cloud, consider self‑managed to keep the control plane portable.

Conclusion

Choosing between a managed and a self‑managed Shoot control plane boils down to a trade‑off between operational simplicity and configuration freedom. Use the decision matrix above to map your organization’s priorities—SLA, cost, customization, and footprint—against the options. The example YAML and validation steps provide a quick path to test the chosen strategy in a real Gardener environment.