Choosing Dedicated vs Shared Seeds in Gardener: A Decision Guide

The Decision You Face

When you run CNCF Gardener to manage many Kubernetes clusters (called shoots), each shoot's control plane is hosted on a seed cluster. A key architectural choice is whether a seed serves a single tenant (a dedicated seed) or multiple tenants (a shared seed). Important caveat up front: Gardener does not model this as a field on the Seed resource. There is no spec.type: dedicated|shared. "Dedicated vs shared" is an operational pattern you implement through how many shoots you schedule onto a seed, which cloud accounts and credentials those shoots use, and how you scope networks. This guide helps you make that choice and verify what you actually deployed.

Constraints That Drive the Choice

• Multi-tenancy requirements – Do different teams or customers need strict separation of blast radius?
• Regulatory or audit mandates – Some standards require demonstrable network and IAM boundaries per tenant.
• Budget and resource efficiency – Shared seeds amortize seed-cluster infrastructure and operational effort.
• Risk tolerance for noisy-neighbor effects – Shoot control planes on the same seed share that seed's etcd capacity, API-server load from controllers, and node resources.

Side-by-Side Comparison

Dimension	Dedicated Seed (one tenant per seed)	Shared Seed (many tenants per seed)
Isolation	Control-plane blast radius limited to one tenant; easier to tie to a dedicated cloud account	Namespace-level separation on the seed; all tenants share seed etcd, network, and nodes
Cloud resources	Can map one seed to one cloud account/project with its own credentials	One seed infrastructure; per-shoot isolation depends on separate SecretBindings and network configuration
Operational overhead	Higher – every seed needs upgrades, monitoring, etcd backup/restore, certificate rotation	Lower – one seed lifecycle covers many shoots
Cost	Higher – duplicated seed control-plane and infrastructure components per tenant	Lower – shared seed costs amortized across shoots
Compliance friendliness	Easier to evidence: one tenant per seed, per-account credentials	Requires compensating controls (network policies, quotas, separate credentials per shoot)
Noisy-neighbor risk	Minimal	Present – one tenant's control-plane load can degrade others on the seed
Scaling ceiling	Limited by one tenant's needs	Seed etcd and API-server load grow with shoot count; requires capacity planning

Trade-off Discussion

When to Prefer Dedicated Seeds

• You must prove strict per-customer separation of control-plane infrastructure and cloud credentials.
• Tenants have wildly different resource profiles (e.g., a heavy CI/CD fleet next to latency-sensitive production).
• You have the operational capacity to run multiple seed lifecycles (upgrades, etcd backups, monitoring).

When Shared Seeds Make Sense

• You operate a modest number of shoots with similar SLAs and trust boundaries.
• Cost and operational simplicity are primary drivers, and you enforce per-shoot credentials via separate SecretBinding resources rather than sharing one cloud account.
• You have observability that can attribute seed-level load (etcd latency, API-server pressure) back to individual shoot control planes, which run in per-shoot namespaces on the seed.

Verifying What You Actually Deployed

Because the pattern is not a single API field, verification means checking how shoots map to seeds and how credentials and networks are scoped. Run these from a workstation with kubectl access to the Gardener garden cluster (the cluster hosting the Gardener control plane). You need at least read permission on shoots, seeds, and secretbindings in the relevant project namespaces. These are read-only commands; the risk is low, but wide get rights on secrets-adjacent resources should be restricted to operators.

1. Map Shoots to Seeds

A dedicated-seed pattern means exactly one tenant's shoots land on a given seed. List the mapping:

kubectl get shoots -A -o custom-columns=NAMESPACE:.metadata.namespace,SHOOT:.metadata.name,SEED:.spec.seedName

Group the output by SEED. If a seed appears with shoots from many projects or tenants, it is functioning as a shared seed. Note that spec.seedName may be unset until the shoot is scheduled; check status.seedName as well for running shoots.

2. Check Credential Scoping

Shoots reference cloud credentials through a SecretBinding (or CredentialsBinding in newer Gardener versions), not through the CloudProfile. Verify each shoot uses its own binding rather than a shared one:

kubectl get shoots -A -o custom-columns=SHOOT:.metadata.name,BINDING:.spec.secretBindingName

If every shoot on a "dedicated" seed points at the same binding used by other tenants, your isolation boundary is weaker than intended. Inspect the binding to see which secret (and thus which cloud account) it references:

kubectl -n <project-namespace> get secretbinding <binding-name> -o yaml

Placeholder notes: <project-namespace> is the Gardener project namespace (often garden-<project>), and <binding-name> comes from the previous command. Do not print the referenced secret's contents unless you are authorized to handle cloud credentials.

3. Review Seed Network and Provider Configuration

The Seed spec describes the seed's provider, region, DNS, and networks. Confirm it matches the intended cloud account and region for the tenant:

kubectl get seed <seed-name> -o yaml

Check spec.provider, spec.dns, and spec.networks. For a dedicated pattern, these should align with the tenant's account and address ranges; overlapping pod/service CIDRs across shoots on a shared seed are a common misconfiguration that Gardener's scheduling normally guards against, but manual changes can bypass it.

4. Watch for Contention on Shared Seeds

On a shared seed, each shoot's control plane runs in its own namespace (typically shoot--<project>--<shoot>). Attribute resource pressure per namespace rather than relying on a single global metric:

kubectl --kubeconfig <seed-kubeconfig> top pod -n shoot--<project>--<shoot>

Requires metrics-server on the seed and read access to the seed cluster. Sustained high CPU/memory in one shoot namespace alongside elevated etcd latency is the classic noisy-neighbor signature; the mitigation is quota/limits on control-plane components or moving the shoot to another seed via control-plane migration.

Limitations and Gotchas

• No declarative "dedicated" flag – the pattern is enforced by your scheduling and credential conventions, not by the API. Document it in an ADR and audit periodically with the commands above.
• External mutations – changing VPC peering, IAM policies, or routes outside Gardener's reconciliation can break shoots or leak resources. Make cloud changes through the extension resources Gardener manages.
• Hidden exhaustion on shared seeds – a runaway controller in one shoot's control plane can degrade the seed's etcd and API server for all tenants. Per-namespace monitoring is essential.
• API evolution – SecretBinding is being superseded by CredentialsBinding in recent Gardener releases; check which your version supports with kubectl api-resources | grep -i binding before relying on either field name.

Decision Checklist

1. List regulatory or contractual isolation requirements per tenant.
2. Estimate shoot count and control-plane load heterogeneity for the next 12–18 months.
3. Compare the cost of duplicated seed infrastructure against the cost of compensating controls on a shared seed.
4. Run the mapping and credential checks above on a staging landscape.
5. Record the chosen pattern, the observed shoot-to-seed mapping, and the credential bindings in an architecture decision record.

The dedicated-vs-shared choice in Gardener is a convention you enforce, not a switch you flip. Making the mapping, credentials, and networks explicitly auditable is what turns the convention into a defensible boundary.