Hack the Garden 2025-06 – Topics 📜

# Hack the Garden 2025-06 – Topics 📜 See also: https://github.com/gardener-community/hackathon ## Participants (19) 🤓 * Stefan M. * Gerrit S. * Valentin K. * Johannes S. * Andreas F. * Konstantinos A. * Axel S. * Luca B. * Marc V. * Oliver G. * Tobias S. * Nikolai D. * Radoslav H. * Mirza K. * Jeremy R. * Viktor K. * Erik S. * Benedikt H. * Niklas K. ## Voting 🗳️ See all proposal with details and links [here](#Proposals-💡). ### Topics 🎬 * 🚧 **[Replace OpenVPN with Wireguard](#Replace-OpenVPN-with-Wireguard) (10 votes)** * *Participants:* Axel S., Stefan M. * 🚧 **[Make `gardener-operator` single-node ready](#Make-gardener-operator-single-node-ready) (10 votes)** * *Participants:* Andreas F., Erik S. * 🚧 **[OTel transport for shoot metrics](#OTel-transport-for-shoot-metrics) (9 votes)** * *Participants:* Nikolai D., Mirza K., Viktor K. * ✅ **[Cluster Network Observability](#Cluster-Network-Observability) (8 votes)** * *Participants:* Jeremy R., Radoslav H., Johannes S. * 💤 **[Signing of `ManagedResource` Secrets](#Signing-of-ManagedResource-Secrets) (9 votes)** * *Participants:* Tobias S., Valentin K. * ✅ **[Migrate control-plane reconciliation of prov-extensions to `ManagedResource`s](#Migrate-control-plane-reconciliation-of-prov-extensions-to-managed-resources) (7 votes)** * *Participants:* Konstantinos A., Gerrit S. * 🚧 **[Dashboard useability improvements](#Dashboard-useability-improvements) (5 votes)** * *Participants:* Benedikt H., Marc V., Niklas K. * ✅ **[Cluster-internal L7 load-balancing endpoints for `kube-apiserver`s](#Cluster-internal-L7-load-balancing-endpoints-for-kube-apiservers) (4 votes)** * *Participants:* Oliver G., Luca B. * 🚧 **[Documentation Revamp](#Documentation-Revamp-📃) (7 votes)** * *Participants*: Mirza K., Niklas K. * ✅ **[Expose EgressCIDRs and/or shoot manifest to shoot-info cm](#Expose-EgressCIDRs-andor-shoot-manifest-to-shoot-info-cm) (5 votes)** 🏎️ * *Participants:* Gerrit S. * 💤 **[Overcome Azure 450 nodes max size.](#Overcome-Azure-450-nodes-max-size.) (3 votes)** * *Participants:* Konstantinos A., Johannes S. * 🚧 **[Multiple Parallel Versions in a Gardener Landscape (fka Canary Deployments)](#Multiple-Parallel-Versions-in-a-Gardener-Landscape-fka-Canary-Deployments) (1 vote)** * *Participants:* Erik S. * 🚧 **[GEP-32 Version Classification Lifecycles](#GEP-32-Version-Classification-Lifecycles) (3 votes)** * *Participants:* Valentin K., Luca B. * 🚧 **[Worker Group Node Roll-out](#Worker-Group-Node-Roll-out) (5 votes)** 🏎️ * *Participants:* Jeremy R., Radoslav H., Gerrit S. * ✅ **[Instance scheduled events watcher](#Instance-scheduled-events-watcher) (5 votes)** * *Participants:* Konstantinos A., Johannes S. ### Pick Up Next 🪝 * ⏳ **[IPv6 or Dual-Stack Support for another Infrastructure](#IPv6-or-Dual-Stack-Support-for-another-Infrastructure) (5 votes)** * ⏳ **[Deploy virtual-kube-apiserver and gardener-apiserver in a single Pod](#Deploy-virtual-kube-apiserver-and-gardener-apiserver-in-a-single-Pod) (4 votes)** * ⏳ **[Deadlink Detection](#Deadlink-Detection-⛓%EF%B8%8F%E2%80%8D💥) (3 votes)** * ⏳ **[Dual-Stack Seed API and Dual-Stack end-to-end Tests](#Dual-Stack-Seed-API-and-Dual-Stack-end-to-end-Tests) (3 votes)** * ⏳ **[Evaluation of NFT mode of `kube-proxy`](#Evaluation-of-NFT-mode-of-kube-proxy) (2 votes)** ### Fast Track 🏎️ * ⏳ **[Colorful Gardener Landscape overview](#Colorful-Gardener-Landscape-overview) (6 votes)** ## Proposals 💡 ### Core ⚙️ #### Multiple Parallel Versions in a Gardener Landscape (fka Canary Deployments) **Author:** Johannes Scheerer **Status** *Work in progress...* 🚧 Gardener currently has very tight versioning constraints. For example, it is not possible to have multiple versions of the same extension type running on the same seed cluster. Therefore, previous ideas around canary deployments ended with the direction to make control plane migration as easy/fast/reliable as possible so that the control planes can be moved between seeds running with different versions of `gardenlet`/extensions. A different approach, favoured by this proposal, would be to make it possible to run multiple version in parallel on a single seed cluster with filters in place so that individual control plane components are still reconciled only by one set of version. This would allow multiple "channel" in the same landscape, e.g. alpha, beta, GA. - `ControllerRegistrations` have a `.spec.deployment.seedSelector` - By having a dedicated `ControllerRegistration/ControllerDeployment` pair per extension different extension image version can be shipped to different seeds - This enables a staged rollout of extension updates - Wouldn't enable use-cases such as the end user choosing the extension versions - One issue is the validation of the `.spec.resources[*].primary` field, which needs adjustment for the steps outlined above to work - Question: why does that field (introduced [here](https://github.com/gardener/gardener/issues/2180)) even exist? It is only used for validation - Relabeling seeds can be done generally. Old extension will be uninstalled + new version installed. - Limitations: - admissions webhook, which run in the runtime cluster - gardenlets with different versions - empty `seedSelector` targets all `Seeds` => making it trivally to have collisions #### Make gardener-operator single-node ready **Authors:** Erik Schubert, Andreas Fritzler **Status:** *Work in progress...* 🚧 Gardener-Operator is great, but unfortunately some HA assumptions are baked into the operator and extension helm charts. That adds some friction when deploying the operator in a single node setup (such as kind or k3s). The friction needs to be removed. Let's also fix the high-availability webhook in single-node setups. **Progress Tracker** - [x] Extension `PodAntiaffinity` - [x] GCP provider extension https://github.com/gardener/gardener-extension-provider-gcp/pull/1052 - [x] OpenStack provider extension https://github.com/gardener/gardener-extension-provider-openstack/pull/1042 - [x] Fluentbit IPv6 support https://github.com/fluent/fluent-operator/pull/1616 - [x] Vali IPv6 support - [x] Cortex fix: https://github.com/afritzler/cortex/commit/4000c188086fe383d314efeb40a663f49aa8b35b and https://github.com/afritzler/cortex/commit/616c0b80d90d036f4275636e1a3be9c5f2aac9e5 - [x] Vali fork: https://github.com/afritzler/vali/commit/35fbce152f783f33fdc2066e09d60ec2ba56b562 and images https://github.com/afritzler?tab=packages&repo_name=vali - [x] Make monitoring setup configurable via Gardener Operator https://github.com/gardener/gardener/pull/12248 #### Worker Group Node Roll-out **Author:** Johannes Scheerer **Status:** *Work in progress...* 🚧 **Fast Track 🏎️** Kubernetes `Deployments` allow simple rollout of pods with `kubectl rollout restart deployment <name>`. There are situations when something similar would be nice to have for worker groups in the Gardener context. For example, the dual-stack migration requires to roll nodes. It would be easier to have a simple way, e.g. by using an annotation on the shoot resource, to trigger node roll-out for a worker group. *Progress Tracker*: POC has been achieved. Now the Shoot resource can be annotated with `gardener.cloud/operation=rollout-workers=<pool1>,<pool2>,...,<poolN>`. This causes a new status to appear on the Shoot that shows the given worker pools as pending for rollout. - [x] Get initial implementation into place --> Branch is here: https://github.com/rrhubenov/gardener/tree/worker-pool-rollout - [ ] Cleanup - [ ] Write tests - [ ] Raise PR (Draft has been opened: https://github.com/gardener/gardener/pull/12271) #### Deploy virtual-kube-apiserver and gardener-apiserver in a single Pod **Author:** Oliver Götz **Status:** *Not yet started* ⏳ As of today there is no horizontal Pod autoscaling for gardener-apiserver. We deactivated it recently (see https://github.com/gardener/gardener/pull/11684). Each virtual-kube-apiserver connects to one single gardener-apiserver via HTTP/2. Thus, when there have been more GAPIs than KAPIs the "excessive" GAPIs did not receive any request. One way to enable horizontal Pod autoscaling for GAPIs again is to bundle KAPI and GAPI in a single Pod and connect them via Pod's localhost. This deployment model ensures, that there are no idle GAPIs. On the other hand the single Pods would be "bigger" and both apiservers would roll together e.g. in case of updates and evictions. The goal of this topic is to adapt the deployment of KAPI and GAPI in gardener-operator that it supports this way of deployment. Additionally, it can be tested if this scenario improves scalability of the virtual-garden. #### Expose EgressCIDRs and/or shoot manifest to shoot-info cm **Author:** Konstantinos **Status:** *Completed* ✅ **Fast Track 🏎️** Helps expose meta-level information about the shoot to workloads of the shoot. This could be useful in case of controllers e.g. crossplane that run on the shoot and need access to some information of the existing infrastructure. **Progress Tracker** - [x] First implementation is [here](https://github.com/gardener/gardener/compare/master...metal-stack:gardener:shoot-info-egress-cidrs) - [x] Pull Request: https://github.com/gardener/gardener/pull/12252 #### GEP-32 Version Classification Lifecycles **Author:** Valentin Knabel **Status:** *Work in progress...* 🚧 Last Gardener Hackathon we implemented Version Classification Lifecycles in the (Namespaced) Cloud Profile, proposed the [GEP-32](https://github.com/gardener/gardener/pull/10982), but we couldn't find enough time to finish the required pull requests for the actual implementation. Our [Draft PR](https://github.com/metal-stack/gardener/pull/9). **Progress Tracker** - [x] Big rebase onto upstream master - [x] Check if it still works - [x] Chop into smaller chunks to create smaller PRs - [x] Issue: https://github.com/gardener/gardener/issues/12256 - [x] First PR: https://github.com/gardener/gardener/issues/12256 --- ### Extensions 🧩 #### Migrate control-plane reconciliation of prov-extensions to managed-resources **Author:** Konstantinos **Status:** *Completed* ✅ Currently we deploy control-plane components using the chart applier instead of managed-resources. This creates some issues where for example if we want to scale a component, we have to do it "manually", e.g. scaling a controller to 0 needs to be done imperatively. I never really received any satisfactory answer as to why we have not proceeded with migrating :sweat_smile: **Progress Tracker** - The branch we work on: [metal-stack/gardener:cp-to-managed-resource](https://github.com/gardener/gardener/compare/master...metal-stack:gardener:cp-to-managed-resource) - Left TODOs: - [x] Fix tests - [x] Test if update path / migration works - [x] ~~Maybe raise a PR already~~ https://github.com/gardener/gardener/pull/12251 - Along the way we thought we might like to offer an alternative to the chart-based `ValuesProvider` interface, which allows extension-provider developers to implement their control plane actuator without using charts but by utilizing the Go Kubernetes API and `client.Object`s: [metal-stack/gardener:controlplane-objects-provider-interface](https://github.com/gardener/gardener/compare/master...metal-stack:gardener:controlplane-objects-provider-interface) - Left TODOs: - [x] Ask if something like this is a good idea or if people already started doing similar things? - [x] Create an issue for disucssion in the Gardener repo: https://github.com/gardener/gardener/issues/12250 #### Overcome Azure 450 nodes max size. **Author:** Konstantinos **Status:** *On hold* 💤 Extensions that do not rely on overlay networking for their in-cluster networking usually rely on other mechanisms such as route tables to establish p2p traffic. Azure being one of them. We currently face scaling difficulties as clusters generally approach the maximum size of route tables set by the provider and we need a new network architecture to overcome this limitation. Potentially can be used as a reference for other providers reaching same limits. - Azure does not allow you to assign private CIDRs to network interfaces. It is possible to assign up to 256 IP addresses per NIC. AKS uses that for it's own implementation. - There is a preview feature that does allow the allocation of subnet's private ranges to NICs that we can potentially use. - The allocation in both cases is restricted from only the subnet's IPs. - Open questions: - The above limitations create a potential crossroad. We opt in to use a single subnet for both Pods+Nodes or keep them separate as we usually do today. - The latter approach fits better to existing cluster and presents potentially a more attractive migration option for them. - The single subnet approach is potentially easier to comprehend and implement. (AKS preferred) TODOs: - [x] Apply the preview feature for ranges on NICs - [ ] Test the preview feature - [ ] Make our preferred option of 2 subnets work. Or document failing reasons - [ ] Currently testing with manual changes. --- ### Networking 🔌 #### Evaluation of NFT mode of `kube-proxy` **Author:** Johannes Scheerer **Status:** *Not yet started* ⏳ The new NFT mode finally seems to be the real successor of the `iptables` mode. Therefore, it may make sense to evaluate it and the interaction with related components, e.g. CNIs. #### Replace OpenVPN with Wireguard **Author:** Johannes Scheerer **Status:** *Work in progress...* 🚧 The Gardener VPN implementation between control and data plane currently uses OpenVPN. 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 https://github.com/apernet/mwgp is required. Related Branches: - https://github.com/metal-stack/gardener/tree/wireguard - https://github.com/metal-stack/vpn2/tree/wireguard - https://github.com/majst01/mwgp #### Cluster-internal L7 load-balancing endpoints for kube-apiservers **Author:** Oliver Götz **Status:** *Completed* ✅ In the last hackathon we created an L7 load-balancing for the external endpoints of Gardener kube-apiservers (Shoots & Virtual Garden). However, cluster internal traffic like from gardener-resource-manager and gardener-controller-manager accesses the Kubernetes internal services directly, skips Istio and so the L7 load-balancing. We noticed at least for gardener-controller-manager that it could generate some load to the gardener-apiserver. Thus, it would be nice to have a cluster internal load-balancing too. We don't want to use the external endpoint since depending on the infrastructure this could create additional external traffic. We could imagine different approaches e.G. manipulate the routing, create cluster internal Istio services or introduce the Istio service mesh to Gardener (😜). For details about the feature please see https://github.com/gardener/gardener/issues/8810. Progress: - [x] Adapted in-cluster L7 loadbalancing of kube-apiserver in Shoot case - [x] Adapted in-cluster L7 loadbalancing of kube-apiserver in Virtual Garden case - [x] Adapt tests, refactor code - [x] Create PR: https://github.com/gardener/gardener/pull/12260 --- ### Networking – IPv6 🧬 #### IPv6 or Dual-Stack Support for another Infrastructure **Author:** Johannes Scheerer **Status:** *Not yet started* ⏳ Gardener currently supports IPv6/Dual-Stack on AWS and GCP. During the last hackathon a proof-of-concept for IronCore was created. Other infrastructures, e.g. metal-stack or Azure, also support IPv6 and could be enabled for Dual-Stack. #### Dual-Stack Seed API and Dual-Stack end-to-end Tests **Author:** Johannes Scheerer **Status:** *Not yet started* ⏳ As one of the last steps missing for full Dual-Stack support, the `Seed` API needs to be extended. Once that is done we could add Dual-Stack end-to-end tests to prevent regressions. --- ### Observability 🔭 #### Cluster Network Observability **Authors:** Johannes Scheerer, Jeremy Rickards **Status:** *Completed* ✅ It might be beneficial to be able to get deeper insights into the traffic of a Kubernetes cluster. For example, traffic across availability zone boundaries may have increased latency or monetary costs. There are tools, e.g. https://github.com/microsoft/retina, which allow to gain more detailed insights into the pod network, but may lack some features like availability zone tracking (see https://github.com/microsoft/retina/issues/1179). Let's fix this and integrate it with Gardener. Feature request: https://github.com/microsoft/retina/issues/1654 Retina PR: https://github.com/microsoft/retina/pull/1657 Metrics with new {source,destination}\_zone labels: ![grafik](https://hackmd.io/_uploads/S1OWj9hGee.png) #### Instance scheduled events watcher **Author:** Konstantinos **Status:** *Completed* ✅ Cloud providers may need to move, stop, retire, reboot etc. The means of communication differ but they are generally available either in the instance objects themselves or more commonly the metadata service. Ref: - https://cloud.google.com/compute/docs/instances/host-maintenance-overview#maintenance_scheduling - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_scheduled_events.html - https://learn.microsoft.com/en-us/azure/virtual-machines/linux/scheduled-events The general goal of this task is to create an agent that can browse and expose via node events and/or dashboard, shoot condition warnings or similar channels available to stakeholders the VM events. This will allow users to take action for their critical workloads inside their maintenance windows and not the arbitrary cloudprovider date. An example implementation could be to use an additional deamonset on the nodes that watches for these events or utilising the existing gardener-node-agent and a communication protocol with a locally injected binary (e.g. like the kubelet and the image credential helpers) - In most hyperscalers IMDS is the unifying interface for which nodes can query these events. Depending on the infrastructure there may be alternatives like querying the API externally. Because some providers don't support external access, we will focus on the IMDS implementation. - [x] Discuss approaches to the task - Daemon set to query IMDS events - DS is responsible to modify node conditions to expose the events. - Potentially use GNA token to ensure it can update only it own node. - Enhance GNA - Approach 1: Have GNA cron a binary (injected via pr-ext.) to get the events and translate them into a provider agnostic format - Approach 2: Have GNA query the IMDS itself and translate only on demand if events are present in jsonpath location - Approach 3: Pure jsonpath parsing in GNA through exposed rules - In all approaches GNA is responsible to update node conditions. - Infrastructure-specific solutions - Enhance `cloud-node-manager` daemon set on Azure (using IMDS) while using non-IMDS APIs on other infrastructures - [x] Implemented enhancement of `cloud-node-manager` for Azure - [ ] Implement solution for other infrastructures based on provider-specific APIs #### OTel transport for shoot metrics **Author:** Niki **Status:** *Work in progress...* 🚧 Today the shoot metrics are collected by the control plane prometheus using the kube-apiserver /proxy endpoint, without any ability to fine tune the collected metrics sets. Since we introduce opentelemetry collector instance on the shoots as a replacement of valitail service and on seeds in the shoot control plane namespace, the goal is to try out collecting and filtering the shoot metrics via opentelemetry collector instances also giving the opportunity for filtering and fune tunning of the metrics sets. This story is part of Observability 2.0 initiative. ![otel-collector-for-shoot-metrics](https://hackmd.io/_uploads/HJyH59nzeg.png) ![otel-ingestes-prmetheus3-metrics](https://hackmd.io/_uploads/S1-wyTAzxg.png) --- ### Security 🛡️ #### Signing of ManagedResource Secrets **Authors:** Tobias Schlicht (originally by Rafael Franzke) **Status:** *On hold* 💤 The secrets of ManagedResources, are currently used as-is by the gardener-resource-manager. This could lead to a bad-actor manipulating these secrets to deploy resources with the permissions of the grm. To counter this, we could cryptographically sign the secrets to circumvent this. **Progress:** - Current draft PR: https://github.com/gardener/gardener/pull/12247 - Secrets for Managed Resources will be signed using ECDSA P521 and verified by the grm. - For that two secrets will be placed in the `garden` namespace (sign and verify key) - Proper RBAC for components still needs to be done - Components which create MRs need read-only permissions on the sign key secret - only the grm may have access to the verification key - Will do testing and other chores after Hackathon --- ### Frontend 🖼️ #### Deadlink Detection ⛓️‍💥 **Author:** Marc Vornetran **Status:** *Not yet started* ⏳ Across Gardener's website, documentation, and dashboard broken links are a common issue. Especially when restructuring content it's easy to miss correcting the various places that reference the content at its old location. It'd be nice to have a solution that runs on PRs for early detection as well as a broad scan that checks all hosted content for broken links. (Example for tooling: https://github.com/tcort/markdown-link-check) *Notes:* * Docforce already implements a best-effort deadlink detection. Its output is used from time to time to open PRs. * It's easy to detect false-positives here in places where it's difficult to resolve a dynamically constructed URL or where a target is behind authentication. * A potential solution should **not** introduce additional friction or noise especially when working on `g/g` PRs (e.g. if we introduce a new PR check we should consider making it an optional requirement). **GitHub Issue:** https://github.com/gardener/docforge/issues/318 #### Documentation Revamp 📃 **Author:** Marc Vornetran **Status:** *Work in progress...* 🚧 Usually, the individual content of our documentation is of high quality and helpful. However, we typically receive complaints about the structure and explorability of our documentation. The pages are tagged with roles (user, operator, developer) to cater to the correct target audience. Yet, when you're on a page it's not clear for whom the content is written for and new visitors will not make a choice (especially when coming from search engines). Additionally, the search box in the top-right corner could be improved. The order of results is unintuitive and the preview text should be more helpful. Finally, switching to the inside perspective, making changes to our documentation is more difficult than it should be. Content is scattered across repositories and the local setup feels error prone and brittle. It should take a few minutes at most to render a local preview. *Notes:* * The current search integration is handled by [Docsy](https://www.docsy.dev/docs/adding-content/search/). Its results can be improved by adding keywords/metadata to certain pages, e.g: https://gardener.cloud/docs/gardener/shoot/ * We could also check whether Algolia or local search with Lunr yields better results. However, there is also the question: How do we measure better results? * For discoverability and explorability we can think about improving/extending the [Glossary](https://gardener.cloud/docs/glossary/) page. * Some provider extensions have dedicated tutorials for using them, e.g. AWS: https://gardener.cloud/docs/extensions/infrastructure-extensions/gardener-extension-provider-aws/tutorials/kubernetes-cluster-on-aws-with-gardener/kubernetes-cluster-on-aws-with-gardener/ * We could double-check whether the tutorials are still working and applicable. Additional, missing tutorials could be contributed. * Additionally, the "Getting Started" sections could be used as a starting point for diving deeper into specific topics. * There is a high-level page describing how to set up a Gardener landscape: https://gardener.cloud/docs/gardener/deployment/setup_gardener/ * This is a good starting point. However, we frequently receive questions from the community on how to set up a Gardener landscape on infrastructure XYZ. Ideally, we should have detailed tutorials for the popular infrastructure providers if not all of them. We could start by writing a detailed guide for setting up a Gardener landscape on OpenStack building on the high-level document. This could serve as an example for other tutorials that can follow. **GitHub Issue:** https://github.com/gardener/documentation/issues/488 **PR Created for improving documentation search:** https://github.com/gardener/documentation/pull/652 **PR Created for updating Glossary** https://github.com/gardener/documentation/pull/653 **Draft PR Create for showcasing Vitepress as a base framework to build the documentation** https://github.com/gardener/documentation/pull/654 - Improves DX, [is up and running locally](https://github.com/klocke-io/documentation/blob/vite-press/README.md) in three steps - (optional) Nice integration with Algolia search ![image](https://hackmd.io/_uploads/r1Lh9KZXgx.png) ![image](https://hackmd.io/_uploads/rkEgiFZQxl.png) #### Colorful Gardener Landscape overview **Author:** Tobias Schlicht **Status:** *Not yet started* ⏳ It would be nice to have a one-sight overview to see a Gardener landscape with its Seeds, Shoots etc. The main focus would be that it looks visually pleasing. I cannot imagine this having any productivity increase in a real-world scenario. The goal would be to look at an overview and think to oneself: "Huh, neat" and then carry on with one's everyday tasks. #### Dashboard useability improvements **Author:** Benedikt Haug **Status:** *Work in progress...* 🚧 The dashboard could profit from some customizability. Items below are sorted by priority/feasibility. **Value Defaulting (landscape scope)** Allow some defaults to be configurable for shoot creation, prominent examples being: * Control Plane High Availability (similar issue: [gardener/dashboard#2227](https://github.com/gardener/dashboard/issues/2227)) * Zones * Autoscaler Min+Max (I don't believe the current minimum of 1 to be reachable in real deployments?) * Volume + size 🔗 *References:* * 🪢 https://github.com/gardener/dashboard/pull/2476 **Overrides (project socpe)** Projects could have optional labels that override the displayed names and owner of the project to get around the current 10 character limit * How to ensure consistency? E.g., one project has a display name while the others do not. What about duplicate names? 🔗 *References:* * 🎟️ https://github.com/gardener/dashboard/issues/2469 * 🪢 https://github.com/gardener/dashboard/pull/2470 **Hide UI Elements (landscape scope)** * Control Plane high availability * Addons * Hibernation **Add new UI Elements (stretch goal)** Adding new elements – would require extensibility concept for the dashboard * https://github.com/gardener/gardener-extension-shoot-cert-service/blob/master/docs/operations/deployment.md#enablement * same for domain * https://docs.wavestack.cloud/kubernetes/nsc/#network-observability * https://docs.wavestack.cloud/kubernetes/nsc/#openstack-server-groups * https://docs.wavestack.cloud/kubernetes/nsc/#registry-cache * https://docs.wavestack.cloud/kubernetes/nsc/#security---disabling-ssh-access * https://docs.wavestack.cloud/kubernetes/nsc/#security---etcd-encryption * https://docs.wavestack.cloud/kubernetes/nsc/#security---seccomp-profile-runtimedefault * https://docs.wavestack.cloud/kubernetes/nsc/#security---podsecurity-admission-plugins

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.