🗳️ Hackathon Topic Voting

[marc1404]

🏆 Hackathon Topic Voting Results

📊 Ranked Topics

Rank	Topic	Votes	Team
1	#31 - Dev: Define AGENTS/SKILLS.md files/templates suitable for the Gardener org	11	@LucaBernstein, @Kostov6, @vitanovs
2	#18 - PoC: repo tools integration with extension repositories	11	@RadaBDimitrova, @marc1404, @dimitar-kostadinov
3	#22 - [GEP-28] Self-Hosted Shoot control plane Node restoration	10	@ialidzhikov, @ScheererJ, @tobschli, @rfranzke, @plkokanov, @LucaBernstein, @Kostov6
4	#28 - Functional local setup with Workload Identity	9	@MartinWeindel, @vpnachev, @dimityrmirchev
5	#16 - [GEP-28] Ensure all system pods run on control plane nodes	9	@oliver-goetz, @plkokanov
6	#21 - Extensions: Leaking resources in (virtual-)garden cluster	8	@dnaeon, @theoddora
7	#8 - [GEP-28] Continue work ongind (gardener-in-docker analogous to kind)	8	@rfranzke, @ialidzhikov
8	#36 - Common Observability API	7	-
9	#35 - gardener-apiserver: Enable kube-api-linter	7	-
10	#24 - Diki as a Service	7	@AleksandarSavchev, @tobschli, @georgibaltiev
11	#20 - Extensions: Use controller-runtime abstraction for validating/mutating webhooks	7	-
12	#19 - Extension: CloudNativePG	7	-
13	#12 - Resolve the Istio Metrics Leak	7	@Bobi-Wan, @ScheererJ, @rrhubenov
14	#10 - Reduce number of Istio Ingress Gateways	7	-
15	#29 - Lakom: Extension controller class=seed	5	-
16	#15 - [GEP-28] Implement public CA bundle discovery mechanism	5	-
17	#34 - PVC Autoscaler: PoC to automatically recovery from PersistentVolumeClaims expansion failures	4	-
18	#27 - Local Setup: Secure the registry with HTTPS cert	4	-
19	#25 - Diki: Add support for Merge of rule Options	4	-
20	#30 - Extension Controllers: Custom histogram metric for reconciliation times with better bucket allocations	3	-
21	#17 - OTEL data plane collector metric persistence	3	-
22	#14 - [GEP-28] Eliminate static admin token from control plane components after gardenadm connect	3	-
23	#9 - More real loadbalancers for provider-local	3	-
24	#26 - Diki: Implement a Pod Security Standards ruleset	2	-
25	#23 - Diki: Pod worker pool	2	-
26	#33 - PVC Autoscaler: PoC to automate downscaling of PersistentVolumeClaims	1	-
27	#13 - Extensions: Helm v4 and handling of crds	1	-
28	#11 - Dual-Stack Seed API	1	-
29	#32 - Rsyslog-relp: Support Garden and Seed extensions	0	-

[marc1404]

#36 - Common Observability API

There is an ongoing experiment of extracting Gardener Observability out of core and into an extension (no document or plan exists yet). There are 2 main issues that need to be tackled for this to happen:

• Common Observability API
  • All Gardener components and extensions have an assumption that there exists a Prometheus Operator and a Fluent operator. This creates a tight coupling that makes extraction hard. Components should not care or know how and what scrapes their signals where they are stored.
• Mulitple Reconciliation Phases
  • Current deployment of the observability stack happens in multiple phases. There is no extension mechanism that cleanly separates this into an extension.

This topic covers the first part - Common Observability API.
The goal is to reach to some solution that satisfies this separation in a clean way. The perfect completion of this topic would be with a POC, but a design document would be ideal as well. Further implementations can happen in another hackathon or outside a hackathon.

[marc1404]

#35 - gardener-apiserver: Enable kube-api-linter

The topic is described in gardener/gardener#12756.

[marc1404]

#34 - PVC Autoscaler: PoC to automatically recovery from PersistentVolumeClaims expansion failures

GEP-0038: Autoscaling PersistentVolumeClaims proposes changes to the pvc-autoscaler controller and how it will be used in Gardener runtime and Seed clusters to scale observability components.

The resize of PVCs could fail for various reasons - not enough storage capacity or errors in the component responsible to do the resize, e.g. csi-resizer.

Kubernetes describes two ways to handle such cases: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes. One of them is by manually recreating the PVC with a smaller size, the other one is by requesting expansion to a smaller size. The latter requires the RecoverVolumeExpansionFailure feature, which is enabled by default since Kubernetes 1.32, and GA since Kubernetes 1.34

Another potential way to handle this and circumvent the csi-resizer is by scaling down the workload, creating a VolumeSnapshot of the PVC, re-creating the PVC with a larger size by using the VolumeSnapshot as source, and scaling up the workload. This would potentially also allow to resize PVCs which specify a StorageClass that has allowVolumeExpansion set to false.

The steps described in #33 are also an option for this, however they are rather complex.

As the pvc-autoscaler repo is under development, the implementation could be done by introducing a new controller and CRD that handles the recovery operation.

[marc1404]

#33 - PVC Autoscaler: PoC to automate downscaling of PersistentVolumeClaims

GEP-0038: Autoscaling PersistentVolumeClaims proposes changes to the pvc-autoscaler controller and how it will be used in Gardener runtime and Seed clusters to scale up observability components. Downscaling is listed as a non-goal because it is a complex and risky operation and its research and implementation would delay the immediate value of scaling up PVCs from a smaller starting size for new clusters.

However, support for downscaling is a potential future enhancement that can be added after the implementation of GEP-0038 is complete.

The goal of this task would be dig deeper into how PVCs can be downscaled and how the operation can be automated reliably - risk of data loss removed and downtime reduced as much as possible.

As there is no native way to downscale volumes in k8s, one way to achieve it is with the following steps:

1. The workload is scaled down.
2. A temporary PVC with a smaller size is created.
3. Data is copied over from the larger PVC to the smaller one, potentially with rsync.
4. The smaller PersistentVolume's persistentVolumeReclaimPolicy is changed to Retain.
5. Both the larger (original) and smaller (temporary) PVCs are deleted - this results in the larger volume being deleted, but the smaller one remaining.
6. The original PVC is re-created, now with the smaller size and volumeName pointing to the smaller PersistentVolume.
7. The claimRef in the PersistentVolume is edited to point to the PVC from the previous step.
8. The workload is scaled-up

Note that VolumeSnapshots cannot be used, because PVCs cannot be created with a smaller size than the one which was used to create the VolumeSnapshot.

The implementation to downscale PVCs could be done in a new controller introduced to the pvc-autoscaler.

[marc1404]

#32 - Rsyslog-relp: Support Garden and Seed extensions

gardener/gardener-extension-shoot-rsyslog-relp#255

For shoots, the extension currently mutates OperatingSystemConfigs and injects shell scripts that are used to start and configure the rsyslog and auditd daemons running on each node.

For unmanaged Seeds and the Gardener runtime cluster we cannot rely on the same approach. However, a similar effect could be achieved by deploying a DaemonSet that configures the auditd daemon on nodes and another DaemonSet that runs rsyslog-relp such that it mounts and reads audit logs from the /var/log/audit folder on the node. One potential drawback is that for shoots, rsyslog-relp directly reads logs from the journald syslog socket, which might not be possible when it is run in a DaemonSet.

Note that configuring auditd is not possible on nodes running in kind on mac, so working on this task requires a setup with provider-extensions.

[marc1404]

#31 - Dev: Define AGENTS/SKILLS.md files/templates suitable for the Gardener org

The AI tools/helpers adoption is growing, it would be nice repos in gardener org to be prepared with configuration files instructing the models how to behave better.

[marc1404]

#30 - Extension Controllers: Custom histogram metric for reconciliation times with better bucket allocations

Controller runtime already provides such a metric, however its bucket allocation does not fit Gardener needs as the slowest bucket is for the range [50;60) seconds, all reconciliations taking longer are tracked in the +Inf bucket which makes it impossible to monitor controllers taking a bit longer, e.g. infrastructure and worker controllers.

This metric has already enabled Prometheus native histogram which provides dynamic bucket allocation and it would have been sufficient to monitor "slow" controllers, however the Prometheus instances are not configured to scrape native metrics. Even if they are, this leads to issues with the Plutono that lacks support for native histograms.

Similar to gardener/gardener#10971, a custom metric with better bucket allocation can be introduced for the purpose of monitoring the reconciliation times of the extension controllers.

[marc1404]

#29 - Lakom: Extension controller class=seed

Lakom admission controller is taking care to not allow untrusted workload and it has been adopted in all kubernetes cluster in a Gardener installation: shoots, seeds, soils, garden runtime and virtual.

The shoot-lakom-service CM has a seed controller that artificially reconciles the kube-system namespace, with the seed class extensions the controller can be changed to reconcile extensions.gardener.cloud/v1alpha1.Extension of class seed instead.

ref: gardener/gardener-extension-shoot-lakom-service#150

[marc1404]

#28 - Functional local setup with Workload Identity

It would be nice to have a functional local setup that is making use of the Workload Identity as credentials. It should be possible the seed cluster(s) to be configured via structured authentication to trust the Workload Identity tokens, the permissions bound to the Workload Identity token can be configured via RBAC.

Controllers like MCM-provider-local should be able to use the Workload Identity token to create the machine (pod in the seed). Other controllers, like infrastructure, backup bucket|entry, DNS if applicable, should also make use of the Workload Identity token.

Later, this should allow implementation of e2e tests with shoots using Workload Identity.

[marc1404]

#27 - Local Setup: Secure the registry with HTTPS cert

With gardener/gardener#13751 Gardener is adding support for registries using custom CA, this would allow registry.local.gardener.cloud to be served over HTTPS instead of HTTP, respectively all configurations configuring the registry as insecure can be removed. Other components, like lakom, will be able to remove the insecure option allowing registries served in plain text.

ref: https://github.com/gardener/gardener-extension-shoot-lakom-service/blob/6105f5edaad1dcaedb5ceb503964032355dc7ddd/pkg/lakom/verifysignature/verifier.go#L30

[marc1404]

#26 - Diki: Implement a Pod Security Standards ruleset

The Pod Security Standards (PSS for short) define three policies to classify the security postures of Kubernetes Pods. Each of these policies is defined by an exhaustive list of guidelines and requirements, as shown in the official Kubernetes documentation. Diki could benefit from the implementation of a ruleset that checks if the Pods are adhering to those policies.

Some additional tips/suggestions for the implementation:

• The ruleset could be implemented to work for the managedk8s provider as a PoC.
• Each PSS policy is defined as a list of controls. Those controls, each of them specifying a set of fields and their allowed values in the Pod spec, could be implemented as separate rules.
• There are already some diki rules, which check Pod spec fields, for example Rule 2001 of the Security Hardened Kubernetes ruleset. A way to re-use some of the existing rules could be brainstormed as well.
• A minimal SecurityProfile could be configured in the ruleset's arguments. Pods which contain more privileges than those in the said SecurityProfile could be marked as findings.

ruleset:
  rulesetID: "pod-security-standards"
  rulesetName: "Pod Security Standards ruleset"
  rulesetVersion: "alpha"
  args:
    minimalSecurityProfile: ("privileged"|"restricted"|"baseline") # the minimal allowed security profile 

• Additionally, for each of the controls, additional options that exempt certain pods could be configured in the ruleOptions spec. Here is an example configuration of a diki-style ruleOption for further reference.

[marc1404]

#25 - Diki: Add support for Merge of rule Options

Currently there is an open issue in diki for this feature.

There should be a way to merge diki rule configurations so that users can easily add on top of existing ones. This would also help with the development of the diki-operator, as we could place default configurations that are always used and users would not have to worry about them.

[marc1404]

#24 - Diki as a Service

Currently, we recommend Gardener users to use the Diki CLI for running compliance scans in their Shoot clusters. This leads to users having to manage the execution of Diki runs themselves, including scheduling, configuration, report collection and storage. The current initiative is to provide a Diki service within Gardener that will improve the user experience and streamline compliance management.
A draft proposal for Diki as a service can be found here.

Development has been initiated with the diki-operator, which is a new Kubernetes operator that will be responsible for managing diki runs based on custom resource definitions (CRDs).
For the hackathon, we can continue the development of the diki-operator, depending on the current state of the operator, here are some topics that can be worked on:

• Implement exports of compliance run reports to an external storage (e.g. OpenSearch, PostgreSQL, ODG, S3, etc.)
• Implement a ScheduleComplianceRun CRD that allows users to schedule compliance runs based on a cron expression.
• Unfinished tasks from the Initial Implementation of diki-operator issue

There is also a need for a new Shoot extension that will deploy the diki-operator to Shoot clusters and manage its lifecycle.

[marc1404]

#23 - Diki: Pod worker pool

Currently, diki rules run independently of other diki rules. This means that rules that require the creation of a pod to run their checks, e.g. checking the file permissions on a node, have to create a new pod for each rule. This can lead to many pods being created and deleted, which is inefficient and can lead to rule failures due to resource constraints.

To address this issue, there can be a pod worker pool that can be used by multiple rules. This worker pool should:

• Be created lazily, only when a rule that requires it is executed for the first time.
• Be shared among all rules that require the creation of a pod to run their checks.
• Use a mechanism to ensure parallel execution of rules that require the pod worker pool, e.g. mutex.
• Be cleaned up after all rules of the ruleset have been executed.

Note

Currently, rules that create pods have the options to not create pods on all nodes via the nodeGroupByLabels rule options, e.g. https://github.com/gardener/diki/blob/35e63cd2a5520030a2c91d83de2c7d982019fe0f/example/guides/disa-k8s-stig-shoot.yaml#L25-L28
This rule options should be taken into account when implementing the pod worker pool, we would want to create the least amount of pods possible for a given diki run.
It might be required a global nodeGroupByLabels option to be made for the rulesets, instead of per rule, to achieve this goal.

[marc1404]

#22 - [GEP-28] Self-Hosted Shoot control plane Node restoration

The Gardener Core Sofia team has already clarified several scenarios for disaster recovery of a self-hosted Shoot cluster. The main prominent scenario is a control plane restoration.

@Kostov6 has a PoC on how to restore a control plane in a new Node in a local setup.

We would like to discuss and brainstorm about several questions:

• How to restore the etcd from a backup?
• How to store / restore the secrets needed for the control-plane components?
• How to store / restore the etcd encryption key?

We would love to have a brainstorming together.

[marc1404]

#21 - Extensions: Leaking resources in (virtual-)garden cluster

Another thing we can improve is related to validatingwebhookconfigurations resources for admission webhooks deployed by the gardener-operator leaking in the (virtual-)garden cluster when the extension is being uninstalled.

[marc1404]

#20 - Extensions: Use controller-runtime abstraction for validating/mutating webhooks

Currently we use a custom abstraction for validating/mutating webhooks in the Extensions API, which we can probably replace with the upstream custom validators and mutators provided by controller-runtime. Full details in this issue:

• Revisit the extensions webhook abstraction gardener#13952

[marc1404]

#19 - Extension: CloudNativePG

What is this extension about?

This extension integrates CloudNativePG into Gardener-managed Kubernetes clusters, providing automated deployment and lifecycle management of production-grade PostgreSQL databases.

CloudNativePG Overview

CloudNativePG is a Kubernetes operator that manages PostgreSQL database clusters natively within Kubernetes. It provides:

• Automated Operations: Handles deployment, failover, and lifecycle management of PostgreSQL clusters using primary/standby architecture with streaming replication
• Native Kubernetes Integration: Works directly with the Kubernetes API server to maintain cluster state (no external dependencies)
• High Availability: Self-healing capabilities with automatic failover
• Data Management: Custom persistent volume claim handling for PostgreSQL data storage
• Security: TLS encryption for in-transit data, certificate integration with cert-manager
• Disaster Recovery: Continuous backups to object stores and Point-In-Time-Recovery (PITR)
• Observability: Built-in Prometheus exporters and JSON-formatted logging

Why?

The Problem: Relational Data in Cloud-Native Ecosystems

The NeoNephos ecosystem hosts multiple projects that produce or consume data fundamentally unsuitable for etcd. While etcd excels as a distributed key-value store for Kubernetes state, it is explicitly not designed for:

• Large datasets (etcd has a 1.5MB value size limit and recommends keeping total database size under 8GB)
• Complex queries (no SQL, joins, or aggregations)
• High write throughput (optimized for consistency over write performance)
• Historical/audit data (no built-in retention policies or time-series support)
• Relational data models (compliance reports, security findings, identity mappings)

Projects that can make use of PostgreSQL (non-exhaustive list)

The following projects have data requirements that can make use of a proper relational database:

Project	Database Need	Data Characteristics
inventory	Resource & relationship storage	Collects resources from multiple cloud providers (AWS, Azure, GCP), persists them, and maps relationships between resources. Functions as a CMDB for infrastructure tracking and dependency analysis - inherently relational data requiring complex graph-like queries. Already uses PostgreSQL.
diki	Compliance scan storage	Historical scan results, JSON reports, trend analysis across clusters. Diki generates compliance reports comparing security posture over time - this requires queryable historical storage, not key-value lookups.
SPIRE (Zero-Trust Identity)	Identity datastore	SPIRE explicitly supports PostgreSQL as its datastore backend. A Gardener-based zero-trust service would need PostgreSQL for storing SVID registrations, attestation policies, and identity mappings across federated trust domains.
Open Delivery Gear	Delivery/compliance metadata	Software bill of materials (SBOM), vulnerability scan results, compliance attestations, artifact metadata. These are inherently relational (components → vulnerabilities → remediations).
gardener-falco-extension	Security event storage	Runtime security events, threat detections, audit trails. High-volume time-series data requiring retention policies and complex queries for incident investigation.

Why Not Use Managed Cloud Databases?

While cloud providers offer managed PostgreSQL (AWS RDS, Azure Database, GCP Cloud SQL), there are compelling reasons to run self-managed PostgreSQL via CloudNativePG:

Concern	Managed Service Limitation	CloudNativePG Advantage
Digital Sovereignty	Data residency concerns; provider lock-in; limited control over encryption keys	Full control over data location, encryption, and access; no vendor dependency
Cost at Scale	Managed databases are expensive, especially for multi-region HA (often 3-5x self-managed costs)	Runs on existing Kubernetes infrastructure; pay only for compute/storage
Air-Gapped Environments	Not available in disconnected or restricted networks	Fully self-contained; works in air-gapped deployments
Compliance Requirements	May not meet specific regulatory frameworks (e.g., BSI C5, GDPR data processing agreements)	Complete audit trail; customizable security policies
Latency	Cross-network calls to managed service	Co-located with workloads in the same cluster
Consistent Operations	Different APIs/tools per cloud provider	Unified Kubernetes-native operations across all environments

The Gardener Extension Value Proposition

By providing CloudNativePG as a Gardener extension, we enable:

1. Unified Database Infrastructure - Same PostgreSQL deployment pattern across AWS, Azure, GCP, OpenStack, and bare-metal shoots
2. Operator Deployment Only - The extension deploys and manages the CloudNativePG operator itself, not individual database instances. Teams retain full responsibility for provisioning, scaling, backup, and lifecycle operations of their PostgreSQL clusters using the operator's CRDs (Cluster, Backup, ScheduledBackup). This separation ensures teams have flexibility while benefiting from a standardized operator deployment.
3. Platform Team Enablement - Central teams define secure defaults; application teams consume databases declaratively
4. Ecosystem Synergy - Other extensions can depend on this extension for their storage needs

[marc1404]

#18 - PoC: repo tools integration with extension repositories

Repository owners should focus on writing go code that gets shipped as production ready images. Any maintenance work that is not around go code is a burden. More precisely that kind of maintenance is based around make targets and hack scripts. This is documented in an issue, but the problem has been discussed long before that.

I currently have a POC, based on a subtree approach with the following story:

Extraction of dependencies into a separate subtree and generalizing usage - this will help with setup of new repositories in the future. The idea came from the effort it took for the pvc-autoscaler to be setup like a Gardener repo for ease-of-use by similarity to others. From what I've noticed, most extension repositories (for example) tend to have ~10 almost identical make targets. This highlights the significant amount of shared logic across repositories.

Re-vendoring Gardener versions that include changes to the hack helper scripts or make targets in gardener/gardener will no longer be as disruptive. Currently, some repositories maintain custom workarounds for certain problems - when a problem occurs, the resolution sometime follows an “every repository for itself” approach, because there isn't much exposure to the problem and fix. Fixes are applied locally, leading to duplicated maintainer effort and inconsistencies among repositories.

By separating the shared scripts and common make targets from gardener/gardener, we can centralize this logic and establish a single place for improvements and fixes. This allows the entire community to benefit from shared maintenance and contributions, instead of requiring each repository maintainer to independently patch the same issue.
Without such centralization and given that the developer sees the need to adapt the change everywhere, even small changes can result in a copy-paste effort across all repositories and potentially ~20 pull requests for a single fix, if the logic is shared.

Actual goal:
Since this is a bigger change that could be adopted by different types of repositories, it would be really helpful to adapt a few different repositories with the POC approach. This way, problems will get caught earlier and more feature requests can be adapted, based on newfound use cases. Current POC adaptations are gardener-extension-shoot-rsyslog-relp and pvc-autoscaler.

[marc1404]

#17 - OTEL data plane collector metric persistence

Currently, an OTEL collector is being developed for shoot data planes, which will serve 2 purposes.

1. metric filtering in the data plane for network traffic reduction
2. metric retention when network connectivity between control and data planes is failing.

This tasks is to create a POC for the second point. A general idea is to use the already existing OTEL collector pipelines and add a processor/extractor that has the option for metric retention. The goal is a moving target, but initially, being able to retain metrics for 10-15 minutes would be a win, as network connectivity issues don't usually persist for too long and this would be useful for stakeholders.

[marc1404]

#16 - [GEP-28] Ensure all system pods run on control plane nodes

Currently, it is not ensured (via node selector or similar placement strategies) that system components in a self-hosted shoot (pods in garden namespace, extensions, and system pods in kube-system) really run on control plane nodes only. Over time, they might get rescheduled to worker nodes as well.
We should avoid this and ensure that system pods are enforced to exclusively run on control plone nodes.

[marc1404]

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

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.

[marc1404]

#14 - [GEP-28] Eliminate static admin token from control plane components after gardenadm connect

When running gardenadm init, the control plane components of the self-hosted shoot cluster use a static token with cluster-admin privileges. This is required to bootstrap the cluster.
When running gardenadm connect (i.e., when the cluster is fully bootstrapped), we should issue short-lived tokens from the gardener-resource-manager (just like for hosted shoots), populate them to the respective components, and eliminate the static token.

Additional thoughts: This might influence disaster recovery scenarios (e.g., when we lost an entire cluster and have to restore it from backup, how do we issue valid tokens such that the control plane components can start up again)?

[marc1404]

#13 - Extensions: Helm v4 and handling of crds

Some extensions (e.g. provider extensions like Azure) deploy CRDs as part of the Helm charts. These CRDs are part of the templates/ directory of the Helm chart, which is what legacy Helm charts used to do.

With Helm 4.x the standard location and best practice for CRDs is to use the crds/ directory, because they can be handled before any resources are created/updated by Helm.

• https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

However, in Gardener we don't take into account the crds/ directory, and this is something that can be fixed.

• https://github.com/gardener/gardener/blob/4be0bb330bc16222acd47ec7bdeb7c0cdfc864c1/pkg/chartrenderer/default.go#L176-L191

[marc1404]

#12 - Resolve the Istio Metrics Leak

Currently, istio metrics are disabled because metrics for no longer existing kube-apiserver instances are served until istio finally restarts. This leads to a huge increase in metrics size, which can lead to congestion, cost explosion and metrics retention reduction. We should figure out how to report only the relevant istio metrics.

[marc1404]

#11 - Dual-Stack Seed API

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

[marc1404]

#10 - Reduce number of Istio Ingress Gateways

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.

[marc1404]

#9 - More real loadbalancers for provider-local

The current loadbalancer implementation in the provider-local setup is rather hacky in various way causing issues along the way. We could utilise cloud-provider-kind and create additional docker containers with reverse proxies to have "real" IPs, which are accessible from within the kind cluster as well as from the host system.

There has been previous work done during the November 2025 hackathon.

[marc1404]

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

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.