🗳️ Hackathon Topic Voting

[tobschli]

🏆 Hackathon Topic Voting Results

📊 Ranked Topics

Rank	Topic	Votes	Team
1	#68 - gardener-node-agent: improve debugability of failed node joins	9	@jnull, @vknabel
2	#52 - [GEP-13] Complete the ManagedSeedSet implementation	9	@timebertt, @Kostov6, @tobschli
3	#62 - Reduce duplication in extension ControlPlane controllers by extracting reusable CSI components	8	@kon-angelo, @jamand
4	#44 - GardenState Resource for Automated Garden Cluster Disaster Recovery	8	@LucaBernstein, @plkokanov
5	#69 - Separately encrypt etcd backups	7	@RadaBDimitrova, @Gerrit91, @mhoffmann-noris
6	#55 - [GEP-28] Run gardener-operator and Seed in self-hosted shoot cluster on managed infrastructure	7	@oliver-goetz, @maboehm
7	#54 - [GEP-28] Support joining control plane nodes in managed infrastructure scenario	7	@rfranzke, @timebertt
8	#47 - Add support for virtual Garden to ACL Extension	7	@georgibaltiev, @v1dusss, @hown3d
9	#45 - [GEP-28] Experiment with shoot/shoot controller in Self-Hosted Shoot Clusters	7	-
10	#15 - [GEP-28] Implement public CA bundle discovery mechanism	7	@jamand
11	#70 - Replace OpenVPN with Wireguard	6	@majst01, @ScheererJ
12	#61 - Reduce Secret watch pressure on seeds by splitting ManagedResource data	6	-
13	#11 - Dual-Stack Seed API	6	-
14	#64 - Stage confineSpecUpdateRollout changes in annotation instead of writing directly to .spec	5	-
15	#58 - Use go tools instead of tools.go	5	-
16	#43 - Switching CNIs	5	-
17	#8 - [GEP-28] Continue work ongind (gardener-in-docker analogous to kind)	5	-
18	#71 - Allow admins to easily use a viewer kubeconfig by default	4	-
19	#57 - Implementing MachineType Successors in Gardener	4	-
20	#51 - Support Garden in extension-audit	4	-
21	#48 - Persist Logs of e2e Tests	4	-
22	#46 - [GEP-36] SelfHostedShootExposure in Cilium extension	4	-
23	#10 - Reduce number of Istio Ingress Gateways	4	-
24	#66 - VPN Connectivity between Garden Runtime Cluster and Seeds	3	-
25	#63 - ManagedResource Signing	3	-
26	#53 - Make internal domain optional/mutable	3	-
27	#50 - Skip Validation of Resource References during --dry-run=server	3	-
28	#67 - Native Routing in the local Dev Setup	2	-
29	#73 - PoC: Component builder	2	-

[tobschli]

#71 - Allow admins to easily use a viewer kubeconfig by default

How to categorize this topic?

/area security
/area ops-productivity
/kind enhancement

/label teamsize/small

What is the topic about?:
Using gardenctl, a admin always gets a adminkubeconfig when connecting to shoots or seeds. It would be great, if I can configure in my gardenctl something like this:

gardens:
- name: prd
  kubeconfig: /secret/path
  config:
    useViewerKubeconfig: always|shoots|managedseeds|never

And then also introduce a flag like --admin or --viewer to overwrite this for any gardenctl target command.

[tobschli]

#70 - Replace OpenVPN with Wireguard

/area robustness
/kind enhancement

/label teamsize/small

Problem Statement: The Gardener VPN implementation between control and data plane currently uses OpenVPN, which is a well-established but somewhat old solution for VPNs. Wireguard is a relatively new, but well-liked contender in the VPN space. It could be possible to replace OpenVPN with Wireguard. As we do not want to spin up a load balancer per control plane (or use one port per control plane) a reverse proxy like mwgp is required.

See: https://gardener.cloud/community/hackathons/2025-06/#%E2%9A%A1%EF%B8%8F-replace-openvpn-with-wireguard

This was started one year ago and should tried to finished in this hackathon.

[tobschli]

#69 - Separately encrypt etcd backups

How to categorize this topic?

/area backup
/kind enhancement

/label medium

What is the topic about?:
etcd backups created for shoots are stored in the same bucket for all shoots of a seed (GEP-0002). In case of a control plane compromise, a shoot would be able to read at least all backups for a seed. The most critical data, namely the secrets, are encrypted, however, it would be preferable to completely prevent exposure to data belonging to other shoots.

A possible approach for in-depth hardening would be to separately encrypt each backup in etcd-backup-restore using a shoot-specific encryption key. Then the compromise of a single control plane would only allow access to other encrypted backups. (Related to gardener/etcd-backup-restore#83 )

Points to consider:

• It should be possible to rotate the encryption key. This either requires a way to reencrypt all backups or to keep the old encryption keys until all old backups using that key have expired (beware of hibernated shoots!).
• The encryption key must properly be transferred on shoot control plane migration

[tobschli]

#68 - gardener-node-agent: improve debugability of failed node joins

How to categorize this topic?

/area ops-productivity
/area robustness
/kind enhancement

/label teamsize/small

/label fast-track

What is the topic about?:

Users currently have limited visibility into node join issues. The gardener-node-agent bootstrap process uses StandardOutput=journal+console in it's systemd unit file to expose error messages on the node's console log. However, this only covers the gardener-node-agent download and initial configuration file writing.

The connection to the cluster's API server is only initialized later on, at which point the logs are no longer printed on the console. In particular in advanced network setups it is possible that the initial gardener-node-agent bootstrap succeeds, but communication the cluster's API server fails.

To improve debugging of such cases (instead of having to resort to accessing the problematic nodes via ssh to access the logs), one of the following suggestions should be implemented:

• Let the gardener-node-agent perform a connection test already during the bootstrap step
• Or, ensure that fatal errors after bootstrapping are also written to the node's console log, similar to those of the bootstrap process.

[tobschli]

#67 - Native Routing in the local Dev Setup

How to categorize this topic?

/area networking
/area dev-productivity
/kind enhancement

/label teamsize/small

What is the topic about?:

Currently, we use overlay networking in the local development setup. Now, that we soon have a cloud-controller-manager (see gardener/gardener#14415) we could also try to implement a route controller to enable native routing. This could be implemented by simply applying the corresponding routes directly on the nodes, but some care needs to be taken on the nodes of the kind cluster.

It would allow us to test certain scenarios in the local development setup, which we can currently only test in real shoot clusters, e.g. switch between native routing and overlay networking.

[tobschli]

#66 - VPN Connectivity between Garden Runtime Cluster and Seeds

How to categorize this topic?

/area networking
/kind enhancement

/label teamsize/small

What is the topic about?:

Depending on the landscape setup, components running in the Garden runtime cluster may not be able to initiate connections to Seed clusters. However, it might be good to have connectivity from the Garden runtime cluster to the Seed clusters, e.g. for showing content in the Gardener Dashboard.

The VPN connection between shoot control plane and shoot data plane is similar. It is established from the data plane to the control plane and used in the other direction. This is similar to what would be possible between Garden runtime cluster and Seed cluster, i.e. all Seed clusters are able to communicate with the Garden runtime cluster.

[tobschli]

#64 - Stage confineSpecUpdateRollout changes in annotation instead of writing directly to .spec

/area control-plane
/kind enhancement
/label teamsize/medium

What is the topic about?:

Problem

With confineSpecUpdateRollout enabled, spec changes to a Shoot are written directly to .spec but only reconciled during the next maintenance window. This means .spec reflects the desired future state, not the currently applied state. This is confusing for users and tooling — you look at the Shoot and can't tell whether what you see is actually running or just pending.

Proposed Solution

Instead of writing changes directly to .spec, stage them as a patch in an annotation (e.g., shoot.gardener.cloud/staged-spec-patch). The .spec continues to reflect the currently applied state. During the maintenance window, the staged patch is applied to .spec, and reconciliation proceeds as usual.

Key semantics

• .spec always reflects what's actually running — no ambiguity
• Patches accumulate: multiple staged changes before the next maintenance window are merged into one cumulative patch
• Staged changes are inspectable: users/tooling can diff the staged patch against current .spec to see what will change at the next maintenance window
• Staged changes can be cancelled: remove the annotation before the maintenance window
• Urgent changes: remove the staged annotation, make the change directly to .spec, trigger reconciliation via operation annotation as usual

Considerations

• Annotation vs. separate resource: For the hackathon, an annotation is sufficient. However, annotations have size limits (~256KB total on the object). For production, a separate resource (e.g., StagedShootSpec) might be cleaner — evaluate during the PoC whether annotation size becomes a practical concern.
• Admission/validation: The staged patch must be validated at staging time, not just at apply time — otherwise users discover validation errors only during the maintenance window. The admission webhook should apply the staged patch to the current .spec in-memory and run the full Shoot validation against the resulting spec. Additionally, the maintenance reconciler should re-validate before applying, in case the .spec changed between staging and apply (e.g., a different field was updated directly).

Tasks

1. Design the staging mechanism: Define the annotation schema (JSON patch, strategic merge patch, or full spec snapshot), accumulation semantics, and interaction with the existing confineSpecUpdateRollout field.
2. Adapt admission/validation: Implement in-memory patch-and-validate in the admission webhook so staged patches are validated eagerly.
3. Adapt the maintenance reconciler: Apply the staged patch to .spec during the maintenance window, re-validate before applying, and clear the annotation after successful application.
4. Adapt API clients/tooling: Ensure kubectl and dashboard workflows correctly stage changes instead of writing to .spec when confineSpecUpdateRollout is enabled.
5. PoC: Implement the end-to-end flow for a simple spec change (e.g., Kubernetes version update) to validate the approach.

[tobschli]

#63 - ManagedResource Signing

How to categorize this topic?

/area quality
/kind enhancement

/label teamsize/small

What is the topic about?:

gardener/gardener#12402

[tobschli]

#62 - Reduce duplication in extension ControlPlane controllers by extracting reusable CSI components

/area control-plane
/kind enhancement
/label teamsize/medium

What is the topic about?:

Problem

Every provider extension (provider-aws, provider-gcp, provider-azure, provider-openstack, ...) implements its own ControlPlane controller that deploys largely identical components — most notably CSI drivers. Each provider reimplements:

• The full CSI controller Deployment spec (with generic sidecars like csi-provisioner, csi-attacher, csi-resizer, csi-snapshotter, csi-liveness-probe)
• The CSI node DaemonSet spec (with generic sidecars like csi-node-driver-registrar, csi-liveness-probe)
• Associated RBAC, PodDisruptionBudgets, monitoring/alerting configuration
• ManagedResource wiring for all of the above

The only truly provider-specific part is the driver container itself (image, args, volumes/mounts). Everything else is ~90% identical across providers but drifts over time. Bug fixes and CSI sidecar version bumps require N PRs across N providers.

Proposed Solution

Extract reusable CSI components into gardener/gardener core following the pattern established by pkg/component/nodemanagement/machinecontrollermanager/ — specifically its provider.go sidecar interface. The core provides the generic Deployment/DaemonSet structure, and extensions only supply the provider-specific driver container via a well-defined interface.

This means:

• Core manages: generic CSI sidecars, RBAC, PodDisruptionBudgets, monitoring, ManagedResource wiring
• Extensions provide: the driver container image, provider-specific args, volumes, and volume mounts

The same pattern could later extend to cloud-controller-manager (generic Deployment skeleton, provider-specific manager container), but CSI is the primary target.

Tasks

1. Audit current provider extensions: Compare ControlPlane controller implementations across providers (provider-aws, provider-gcp, provider-azure, provider-openstack) to catalog shared vs. provider-specific code. Quantify the duplication.
2. Design the reusable component: Define a core component in pkg/component/ with a provider interface (following the MCM sidecar pattern) for CSI controller and CSI node deployments.
3. PoC for one provider: Implement the new component and migrate one provider extension (e.g., provider-aws or provider-gcp) to validate the interface.
4. Evaluate cloud-controller-manager: Assess whether the same pattern applies to CCM and scope a follow-up if so.

[tobschli]

#61 - Reduce Secret watch pressure on seeds by splitting ManagedResource data

/area control-plane
/area scalability
/area performance
/kind poc
/label teamsize/medium

What is the topic about?:

Problem

gardener-resource-manager stores rendered manifests in Secret objects referenced by ManagedResource.spec.secretRefs. This was deliberate — ManagedResources can contain Kubernetes Secret resources that must be encrypted at rest in etcd.

However, this means all manifest data (Deployments, Services, RBAC, etc.) lives in Secrets, even when it contains nothing sensitive. On a seed cluster, this leads to:

• A large number of Secrets in etcd (roughly 1:1 with ManagedResources)
• Elevated memory and network I/O for every pod that watches Secrets (even if it only cares about a handful)
• Unnecessary etcd pressure from watch events on non-sensitive data

Proposed Solution

Split the ManagedResource data store by sensitivity:

1. Sensitive manifests (i.e., Kubernetes Secret resources) stay in Secret objects — encrypted at rest as today.
2. Non-sensitive manifests (everything else) move to a new dedicated custom resource (e.g., ManagedResourceData or similar) that is not in the Secret watch surface.

gardener-resource-manager would be adapted to read from both sources. During reconciliation, it already knows which resource types it is deploying, so the split can be determined at write time by the deploying controller.

Tasks

1. Audit Secret watchers on seeds: Identify which pods in seed clusters are watching Secret resources (e.g., shoot-dns-service in control plane namespaces, extension controllers, cert-manager, etc.). Measure the memory and network I/O impact of the current Secret volume on these pods. This provides the data to justify the change and quantifies the expected benefit.
2. Design the new resource type: Define a CRD for non-sensitive ManagedResource data. Decide on schema, naming, and namespace scoping.
3. Adapt gardener-resource-manager: Support reading manifests from both Secret refs (sensitive) and the new CRD refs (non-sensitive). Maintain backward compatibility with existing spec.secretRefs.
4. Adapt deploying controllers: Modify the controllers that create ManagedResources (e.g., in pkg/component/) to split manifests by sensitivity at write time.
5. Migration path: Ensure a smooth transition — existing ManagedResources with all data in Secrets must continue to work. Consider a phased rollout.

[tobschli]

#58 - Use go tools instead of tools.go

How to categorize this topic?

/area dev-productivity
/kind enhancement

/label teamsize/small

What is the topic about?:
Topic left unfinished from last hackathon: gardener/gardener#13545

There are still points left for discussion, design and testing. Not all checks run smoothly yet. This is because the go tools directives need to be wired also to other tools making calls not directly controlled by us. An idea would be to add alias functions and export them so the commands are available in the environment.

[tobschli]

#57 - Implementing MachineType Successors in Gardener

How to categorize this topic?

/area ops-productivity
/kind enhancement
/label teamsize/medium

What is the topic about?:
Enhance the CloudProfile schema to align the MachineType definition with the MachineImage lifecycle proposed in GEP32 and extend it with successor and migrationPolicy .

# Current Date: 2026-04-15
apiVersion: core.gardener.cloud/v1beta1
kind: CloudProfile
spec:
  machineTypes:
    - name: m5.large
      cpu: 2
      gpu: 0
      memory: 8Gi
      lifecycle:
        - classification: preview
          # Implicitly starts if no startTime
        - classification: supported
          startTime: "2025-01-01T00:00:00Z"
        - classification: deprecated
          startTime: "2026-05-01T00:00:00Z"
        - classification: expired
          startTime: "2026-07-01T00:00:00Z"
          successor: m6i.large
          migrationPolicy: ForceUpgrade # Options: ForceUpgrade, Manual, BlockScaling

The successor field would define the new MachineType while the migrationPolicy defines how to handle it. Possible options would be ForceUpgrade, Manual or BlockScaling.

ForceUpgrade

Once expired.startTime is reached, Gardener patches the Shoot spec.
This keeps the infrastructure free of technical debt, but is the most disruptive for sensitive StatefulSets.

Manual

This offers the most user control, as it currently is a manual task to update clusters with new MachineTypes once they reach their EOL.

BlockScaling

Existing nodes are allowed to stay, but the MachineControllerManager is blocked from creating new nodes of the expired type. This will prevent the creation of new machines of a MachineType that is no longer available and no new instances will be provisioned.

For backwards compatibility, Manual or BlockScaling should be the default.

It should also be possible to override this in the Shoot spec if needed, e.g.

metadata:
  annotations:
    confirmation.gardener.cloud/skip-machine-type-migration: "true"

For unexpected unavailability by the cloud provider, the unavailable classification can be used.

The user should be warned when the current MachineType is deprecated and the successor should be recommended to them, e.g. via a Shoot constraint MachineTypeDeprecated analogous to existing version constraints.

successor should be a single value, a user would have always the choice to pick any other MachineType, but Gardener should have a definitive successor.

Of course, everything is open to discussion, but here are some open questions:

• What happens to worker pools where the configuration is incompatible with the new MachineType (e.g. zones)
• Will there be a rolling update or only the spec changed and waited for the next reconcile (node pool will be updated in the maintenance window)
• What about hibernated Shoots
• What happens, if the successor is deprecated or expired as well?
• What happens, if the successor chain is circular?
• How to handle NamespacedCloudProfile?
• How does unavailable differ from expired, will it start without a date?
• Should the override annotation confirmation.gardener.cloud/skip-machine-type-migration
  apply only to ForceUpgrade (skipping the patch for one maintenance window),
  or should there be a symmetric mechanism for BlockScaling
  (e.g. gardener.cloud/operation=force-machine-type-migration to allow scaling despite the block)?
• Who is allowed to set the override annotation? Should this be enforced via an admission plugin,
  so that regular project members cannot bypass an explicitly configured CloudProfile policy?

[tobschli]

#55 - [GEP-28] Run gardener-operator and Seed in self-hosted shoot cluster on managed infrastructure

How to categorize this topic?

/area ipcei
/kind enhancement

/label teamsize/small

What is the topic about?:

For unmanaged infrastructure, we already made good progress and made it possible to run gardener-operator within a self-hosted shoot cluster. It should even be possible to make it a seed cluster.

This work should also be done for the managed infrastructure scenario. The full scenario should also be tested by automated tests.

[tobschli]

#54 - [GEP-28] Support joining control plane nodes in managed infrastructure scenario

How to categorize this topic?

/area ipcei
/kind enhancement

/label teamsize/small

What is the topic about?:

gardenadm join was extended to support joining control plane nodes, e.g. generate TLS certificates for etcd and write them directly to the node. This works fine in the unmanaged infrastructure scenario.
For the managed infrastructure scenario, the logic should be called from within gardener-node-agent.

Check gardener/gardener#2906 for existing work in the unmanaged infrastructure case.

[tobschli]

#53 - Make internal domain optional/mutable

How to categorize this topic?

/area networking usability
/kind enhancement

/label teamsize/medium

What is the topic about?:

Every Gardener environment requires a DNS zone used for managing "internal domains" of shoots. The zone can be configured per seed.
The internal domain primarily targets Gardener setups, where shoot owners can configure their own "external domain"/provider/zone for their shoot API servers (i.e., via Shoot.spec.dns). The internal domain is used for all cluster-critical communication (e.g., kubelet/gardener-node-agent to API server) to ensure robustness and prevent disruptions caused by user configurations.
Some Gardener setups don't grant users access to the Shoot API but offer a different ("proxy") API (e.g., STACKIT Kubernetes Engine). Here, the external domain might not be configurable by shoot owners.

We identified the following scenarios that we could investigate/hack:

• In setups without customer-configured external domains, internal domains are potentially irrelevant -> relax the requirement for an internal domain
• For privately exposed API servers (via a dedicated DNS zone "external domain"), it might be undesirable to add API server DNS records in a shared (potenitally public) DNS zone -> remove the internal domain, make it configurable/mutable per shoot would help here
• Migrating all shoot API server domains to another zone/provider might be needed for compliance reasons

[tobschli]

#52 - [GEP-13] Complete the ManagedSeedSet implementation

How to categorize this topic?

/area ops-productivity
/kind enhancement

/label teamsize/medium

What is the topic about?:

The ManagedSeedSet proposal (GEP-13) has never been fully implemented.
E.g., the ManagedSeedSet implementation supports creating Shoots and ManagedSeeds but not updating them.

A fully implemented ManagedSeedSet would simplify operations and lay the groundwork for more automated setups (e.g., the "seed autoscaler").

[tobschli]

#51 - Support Garden in extension-audit

How to categorize this topic?

/area audit-logging
/kind enhancement

/label teamsize/medium

What is the topic about?:

https://github.com/metal-stack/gardener-extension-audit could support the Garden object, so that Gardener operators don't need to configure audit logging for the virtual garden manually, but use an automated setup based on the extension.

[tobschli]

#50 - Skip Validation of Resource References during --dry-run=server

How to categorize this topic?

/area usability
/kind enhancement

/label teamsize/small

/label fast-track

What is the topic about?:

Originally proposed by @maboehm in https://hackmd.io/c-SxOnnDTE-XQbrXnrPprw?both#Skip-Validation-of-Resource-References-during---dry-runserver.

As already discussed in gardener/gardener#12582 (comment) and gardener/gardener#12950, the strict validation of referenced resources makes it impossible for tools like flux to create a Shoot and e.g. a referenced Audit ConfigMap, which is not yet present, at the same time, because flux always performs a server-side dry run first. I would propose to consistently make these validations optional on dry-runs and only emit a warnings if the resources do not exist.

[tobschli]

#48 - Persist Logs of e2e Tests

How to categorize this topic?

/area dev-productivity
/kind enhancement

/label teamsize/medium

What is the topic about?:

Gardener e2e tests export the logs of running pods/machines before exiting – both on success and failure – so that they can be viewed/downloaded in the artifacts browser (gcsweb).
However, logs of terminated pods/machines will not be exported if they are not running at the end of the test execution. I.e., we don't collect logs of pods/machines of successful test cases, because the shoots will be deleted as part of the test execution.
Debugging e2e test failures based on this information is very tedious. The ability to search e2e test logs or to compare logs of successful/tailed tests would improve this experience.
For this, we could add a logging stack to the Prow cluster (similar to the performance prometheus) where e2e test logs are stored and which can be queried in the cluster's Plutono instance.

[tobschli]

#47 - Add support for virtual Garden to ACL Extension

How to categorize this topic?

/area networking
/kind enhancement

/label teamsize/small

What is the topic about?:

With gardener/gardener#14420 it is possible to handle the client IP address for the virtual garden cluster. Hence, it might be interesting to add support for IP allowlisting to the ACL extension for this scenario, i.e. IP allowlisting of the virtual garden cluster.

[tobschli]

#46 - [GEP-36] SelfHostedShootExposure in Cilium extension

How to categorize this topic?

/area networking
/kind enhancement

/label teamsize/medium

What is the topic about?:
With GEP-36 we introduced a way to exposure the API server of Self hosted shoots via a new API SelfHostedShootExposure.

This topic is proposing to implement this API in the Cilium extension. We can leverage Cilium LB IPAM feature to allocate virtual IPs for Load balancers and advertise such IPs either via L2Announcements or BGP Advertisements.

PoC for doing this with Cilium:
https://github.com/hown3d/cilium-loadbalancer-apiserver

[tobschli]

#45 - [GEP-28] Experiment with shoot/shoot controller in Self-Hosted Shoot Clusters

How to categorize this topic?

/area high-availability
/area ipcei
/kind enhancement

/label teamsize/small

What is the topic about?:

A lot of the required tasks for day-2 operations have been completed, i.e. almost all gardenlet controllers are now deployed during gardenadm connect (see gardener/gardener#2906). However, the most important controller shoot/shoot is not included, yet. Therefore, a lot of the required components have not been deployed to self-hosted shoot clusters, yet.

The goal of this item is to ideate and experiment how to make shoot/shoot work in the self-hosted context. Among the available options there are:

• Adding SkipIf conditions to the flow tasks where necessary
• Splitting the Shoot flow in smaller parts, which may be reused in hosted vs. self-hosted scenarios
• Find another solution to the problem of potential duplicate maintenance vs. readability

[tobschli]

#44 - GardenState Resource for Automated Garden Cluster Disaster Recovery

How to categorize this topic?

/area disaster-recovery
/kind enhancement

/label teamsize/small

What is the topic about?:

See gardener/gardener#14474

[tobschli]

#43 - Switching CNIs

How to categorize this topic?

/area networking
/kind enhancement
/label teamsize/medium

What is the topic about?:
Currently it is not possible to switch CNIs in gardener since it is marked as immutable in the shoot spec.
While it makes total sense to have that footgun locked behind closed doors as it is possible to encounter downtime in your cluster, it might be worthwhile to experiment with.

With both CNIs in native routing mode, a router controller from your cloud controller manager running and some migration code in gardener, it should be possible to achieve such a switch without downtime.
For reference:

• Switching your CNI — Simone Sciarrati & Federico Hernandez at Container Days 2023

There are a lot of blogs and docs about doing Cilium migrations with overlay networking, but I think it's the most easiest to focus on native routing as it should be the easiest.

• https://cilium.io/blog/2023/09/07/db-schenker-migration-to-cilium/
• https://cilium.io/blog/2020/10/06/skybet-cilium-migration/
• https://docs.cilium.io/en/stable/installation/k8s-install-migration/

Special notes for your reviewer:
At STACKIT Kubernetes Engine we currently run Calico for all clusters in our environment but want to offer Cilium as well which we would like to run our ManagedSeeds with as well.
Because we cannot change our existing seeds to Cilium, we would need to do Control plane migrations, which causes downtime for our customers.

[tobschli]

#15 - [GEP-28] Implement public CA bundle discovery mechanism

How to categorize this topic?

/area ipcei
/kind enhancement

/label teamsize/small

What is the topic about?:
Currently, when running gardenadm join or gardenadm connect, the CA bundle of the cluster has to be provided via command line arguments. In the GEP, we talked about implementing a discovery process for the CAs with so-called "discovery tokens" – inspired by kubeadm.

Let's investigate this process and consider implementing it for our use-case as well.

[tobschli]

#11 - Dual-Stack Seed API

How to categorize this topic?

/area networking
/kind enhancement

/label teamsize/small

What is the topic about?:

As one of the last steps missing for full Gardener Dual-Stack support, the Seed API needs to be extended.

[tobschli]

#10 - Reduce number of Istio Ingress Gateways

How to categorize this topic?

/area cost
/area networking
/kind enhancement

/label teamsize/small

What is the topic about?:

In a standard multi-zonal seed cluster, there is one multi-zonal istio ingress gateway and one per availability zone. The multi-zonal istio ingress gateway could be replaced by usage of all single-zone istio ingress gateways. This could lead to higher resource usage, reduced costs and a less complicated setup.

[tobschli]

#8 - [GEP-28] Continue work ongind (gardener-in-docker analogous to kind)

How to categorize this topic?

/area dev-productivity
/area quality
/area testing
/kind enhancement
/kind test

/label teamsize/medium

What is the topic about?:

It should be possible by now to create self-hosted shoot clusters using gardenadm. To eat our own dog food we could run our end-to-end tests in a single-node self-hosted shoot cluster. This could increase confidence in self-hosted shoot clusters and put them to a real test.

Previous work was done in the November 2025 hackathon (summary post).

[tobschli]

#73 - PoC: Component builder

How to categorize this topic?

/area quality
/kind poc

/label teamsize/medium

What is the topic about?:

Introduction

Key parts of gardener are components and reconcile graphs. Currently a component is arbitrary code that gets executed by a Deploy function. Most components are just the application of a set of resources - MRs, CRs, secrets from secrets manager. Doing this imperatively is more error prone than doing it declaratively.

Static and Dynamic components

Static components

Static components' resources are fully determinable at the beginning of the reconcile graph. The benefit of this is that we can define a component just by the following:

1. Mapping of resources like Garden, Seed, Shoot, featureGates, k8s versions to component's Values structure
2. Mapping of Values structure to the set of MRs, CRs, secrets from secrets manager.

That component becomes fully declarative which is much less error prone - the only set of developer errors are in the definition of the mappings above. This also allows one component file to contain all the component information (currently it is split between component file, shared component, new<Component> or Default<Component> functions)

Also functions like WithDefaultVPA, WithDefaultPDB could be introduced to the builder to make creation of components more easy.

Finally, because the of the declarative nature, the component builder knows everything about the component and some validations and recommendations from the Component checklist could be automatically applied by the builder

Dynamic components

Dynamic components would be components's resources that can not be fully determined at the beginning of the reconcile graph. For example if a Deployment spec section is based on a ConfigMap's content that is undeterminable at the beginning of the reconcile graph. That case will require the execution of arbitrary code.

In short, Dynamic components have runtime dependencies on other resources.

Dynamic component should be used only if the task can not be achieved in any way using a static component. They create more complexity and are more error prone because you'll need to handle all states of those runtime dependencies (what should happen if a dependency is missing/invalid).

Component registry

Component library is just an object that holds all of the components for an unified way of referencing them in reconcile graphs.

Current state of PoC

The PoC branch has already converted 5 simpler gardener components into static components

gardener/gardener@master...Kostov6:gardener:poc/component-builder-and-registry-demo

Note: When reading please go over commits as they are fully self contained.

Hackathon tasks

1. Convert more components to static ones if there is no justification for them being dynamic. Validate conversion by comparing applied CRs by the component before vs after conversion
2. (optional) Integrate CRD components into component builder
3. (experimental) Integrate OSC components into component builder