GEP-0054: Worker Capabilities for Machine Image Selection by Roncossek · Pull Request #53 · gardener/enhancements

Roncossek · 2026-02-26T14:47:27Z

How to categorize this PR:
/area os usability
/kind enhancement

One-line PR description: Adds new GEP 0054 - Worker Capabilities for Machine Image Selection

Issue link: Worker Capabilities for Machine Image Selection #54

Other comments:

gardener-prow · 2026-02-26T14:47:31Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign vlerenc for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

vpnachev · 2026-02-28T13:48:15Z

+The following example capability names are reserved for Gardener core use. All reserved capabilities use the `gardener-` prefix:
+
+```go
+const (


Following https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#constants, the enums should be in pascal case, e.g. GardenerBootType instead of gardener-bootType.

+1 to have consistent constant values.

I would be fine with both gardener-boot-type and GardenerBootType, but mixing the styles looks strange.

rfranzke · 2026-03-03T09:26:14Z

+
+## Summary
+
+This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.


I struggle with the term "worker properties" or "worker capabilities". Can you find a better name?

rfranzke · 2026-03-03T09:30:16Z

+
+## Summary
+
+This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.


Suggested change

This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.

This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker pool configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.

rfranzke · 2026-03-03T09:31:44Z

+
+## Motivation
+
+Currently, machine image capabilities as defined in GEP-0033 only support selecting images based on hardware properties of the machine type (CPU architecture, hypervisor type, bare-metal vs virtualized). However, users increasingly need the ability to select images based on software or feature requirements that are specified in the worker configuration, such as:


Isn't the real motivation the defaulting? Users (already today) know what their worker pools will need. If they need in-place updates, they can look up a proper machine image/type in the CloudProfile. Same goes for other capability requirements.

What you seem to want to achieve is that they don't have to look this up and manage themselves, right?

rfranzke · 2026-03-03T09:32:04Z

+- **GPU Support**: Select images with specific GPU driver support (nvidia, amd, intel)
+- ...
+
+Without this feature, users must manually ensure that their worker configuration is compatible with the selected machine image, which is error-prone and limits the automation benefits provided by Gardener's maintenance operations.


Aha, yes, here you seem to confirm. I would update this section to highlight this main use-case.

rfranzke · 2026-03-03T09:33:55Z

+- **Machine type capabilities**: Describe what the hardware supports (e.g., ARM64 architecture, virtualized hypervisor)
+- **Worker capabilities**: Describe what features the worker configuration requests (e.g., secure boot enabled, in-place updates required)
+
+Worker capabilities are derived from worker specification properties. To prevent naming conflicts between Gardener-reserved capabilities and custom or provider-defined capabilities, reserved capability names use a `gardener-` prefix.


Can you explain/provide some examples what "Gardener-reserved capabilities" would be, in contrast to custom or provider-defined capabilities?

Is this because of NamespacedCloudProfiles where end-users might define their own images or machine types with their custom capabilities? I have to guess way too much here.

rfranzke · 2026-03-03T09:34:59Z

+### Notes/Constraints/Caveats
+
+- Worker capabilities are **additive** to the existing capability system. Existing CloudProfiles and image selection continue to work without modification.
+- The `gardener-` prefix is reserved for Gardener core capabilities. Provider extensions should use their own prefixes (e.g., `azure-`, `aws-`) for provider-specific capabilities.


How do you ensure that the prefixes used by provider extensions will not be taken by users?

Why not just combine the prefix, e.g. gardener-azure- and gardener-aws-? This was users can use anything, but the prefix gardener-.

rfranzke · 2026-03-03T09:36:45Z

+    capabilities := make(map[string][]string)
+
+    // Boot type mapping
+    if worker.Machine.SecureBoot != nil && *worker.Machine.SecureBoot {


The capabilities API in the CloudProfile is very generic without hard-coded capability names. Why would we now start to hard-code some of them in the worker pool API?

Your comment is so true and addresses a tension within the idea behind this GEP. Allow me to elaborate my thoughts here.

My main concern is that the generic capability field on the worker might be confusing to use for the end users of gardener as they need to know what capabilities (and values) exist in the selected CloudProfile.

GEP-33 is an implementation detail of how Gardener selects the right image flavor automatically. Users specify via a well documented API what they want and capabilities are non of his concern. Only the gardener operator needs to understand the capabilities machanism.

explicit fields are easier to understand for the end user

Second is that some features might want to define additional configuration like the existing In-Place-Update feature here: (AutoInPlaceUpdate vs ManualInPlaceUpdate). This cannot be included in a capability. In these cases this would be kind of double maintenance as gardener can assume, that if these values are set, an image that supports in place updates is required. But this can be handled with some nice defaulting.

If we use the generic capabilities field on the worker API:
How can we provide a good UI and API documentation for the user?

rfranzke · 2026-03-03T09:37:42Z

+        case "nvidia":
+            capabilities[CapabilityNameGpuSupport] = []string{CapabilityValueGpuSupportNvidia}
+        case "amd":
+            capabilities[CapabilityNameGpuSupport] = []string{CapabilityValueGpuSupportAmd}
+        case "intel":
+            capabilities[CapabilityNameGpuSupport] = []string{CapabilityValueGpuSupportIntel}
+        default:
+            capabilities[CapabilityNameGpuSupport] = []string{CapabilityValueGpuSupportNone}


We even go beyond and not only hard-code capability names, but also concrete values (like nvidia, etc.)? Then I don't understand the whole effort that was put in GEP-33 to make the API as generic as possible.

rfranzke · 2026-03-03T09:39:02Z

+
+### Provider-Specific Worker Properties
+
+Provider extensions can define additional worker properties that map to capabilities. This is achieved through the existing `WorkerConfig` extension mechanism:


This sounds wrong, shouldn't we add a dedicated capabilities field to the worker pool API, similar to how it was done for machine images and types? Why would we use the WokerConfig for this?

ScheererJ

Thanks for the proposal.

From my perspective, it should be adapted to be less abstract. I wondered most of the time what this is actually about until I reached the design details. It should be possible to make this more tangible and understandable by adding examples earlier and using a better name as Rafael suggested.

ScheererJ · 2026-03-03T15:50:46Z

+    - [Provider-Specific Worker Properties](#provider-specific-worker-properties)
+    - [Component Changes](#component-changes)
+  - [Drawbacks](#drawbacks)
+


Nit: Let's not have double empty lines.

Suggested change

ScheererJ · 2026-03-03T15:53:49Z

+
+## Summary
+
+This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.


You added examples for GEP-33, i.e. CPU architecture, hypervisor type, etc.. Could you please also add some examples for the new properties? Otherwise this paragraphs stays very abstract.

ScheererJ · 2026-03-03T16:01:20Z

+### Notes/Constraints/Caveats
+
+- Worker capabilities are **additive** to the existing capability system. Existing CloudProfiles and image selection continue to work without modification.
+- The `gardener-` prefix is reserved for Gardener core capabilities. Provider extensions should use their own prefixes (e.g., `azure-`, `aws-`) for provider-specific capabilities.


Why not just combine the prefix, e.g. gardener-azure- and gardener-aws-? This was users can use anything, but the prefix gardener-.

ScheererJ · 2026-03-03T16:05:46Z

+The following example capability names are reserved for Gardener core use. All reserved capabilities use the `gardener-` prefix:
+
+```go
+const (


+1 to have consistent constant values.

I would be fine with both gardener-boot-type and GardenerBootType, but mixing the styles looks strange.

ScheererJ · 2026-03-03T16:12:32Z

+
+## Drawbacks
+
+- **Increased Complexity**: Adds a third dimension to capability matching, which increases the complexity of the image selection algorithm.


I understand that the image selection algorithm will be more complex, but it should get a lot less complex for the users of the service. Right?

Yes I will make that more explicit, as this is one of the main drivers for the GEP:

Shift complexity and validation of worker config away from the user to our implementation.

gardener-ci-robot · 2026-04-11T09:40:25Z

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

After 30d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 14d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as active with /lifecycle active
Mark this PR as fresh with /remove-lifecycle stale
Mark this PR as rotten with /lifecycle rotten
Close this PR with /close

/lifecycle stale

gardener-ci-robot · 2026-05-11T10:32:23Z

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

After 30d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 14d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as active with /lifecycle active
Mark this PR as fresh with /remove-lifecycle rotten
Close this PR with /close

/lifecycle rotten

…tation Update GEP number from 0050 to 0054 Update README.md incorparate initial GEP feedback rewrite based on three party cooperation (gardener,image,infra) simplified version Enhance GEP-0054 README: Add Risks and Mitigations section, refine capability definitions, and update validation details

… machine image selection

Roncossek · 2026-05-22T10:42:27Z

Thanks for the valuable feedback so far! I've reworked the GEP substantially.

I structured the proposal around the two currently known use cases that connect worker pool fields with GEP-33 capabilities:

in-place node updates as a worker update strategy
secure boot support (planned)

This gives the proposal more direction and makes the benefits clearer.

I also narrowed the scope: the GEP now only covers capabilities owned by Gardener under the gardener- prefix. Provider-extension-owned capabilities driven by WorkerConfig were deferred to a future GEP once/if actual use cases exist that would justify such changes.

Would appreciate another look.
cc @ScheererJ @rfranzke @vpnachev

Roncossek · 2026-05-22T12:03:03Z

/lifecycle active

Roncossek mentioned this pull request Feb 26, 2026

Worker Capabilities for Machine Image Selection #54

Open

Roncossek changed the title ~~GEP-0040: Worker Capabilities for Machine Image Selection~~ GEP-0054: Worker Capabilities for Machine Image Selection Feb 26, 2026

vpnachev reviewed Feb 28, 2026

View reviewed changes

rfranzke reviewed Mar 3, 2026

View reviewed changes

ScheererJ reviewed Mar 3, 2026

View reviewed changes

Roncossek self-assigned this Mar 12, 2026

Roncossek mentioned this pull request Mar 31, 2026

[GEP-33] Add machineCapabilities CloudProfile support gardener/gardener-extension-provider-gcp#1067

Merged

gardener-prow Bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 11, 2026

gardener-prow Bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 11, 2026

Roncossek force-pushed the worker-capabilities branch from ca4a401 to cc18739 Compare May 22, 2026 10:24

Fix: update title for GEP-0054 to reflect capability requirements for…

a103e15

… machine image selection

gardener-prow Bot added lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels May 22, 2026


		## Summary

		This GEP extends [GEP-0033 (Machine Image Capabilities)](../0033-machine-image-capabilities/README.md) to support selecting machine images based on worker-defined properties in addition to machine type characteristics. While GEP-0033 enables image selection based on hardware capabilities of machine types (CPU architecture, hypervisor type, etc.), this proposal introduces worker capabilities that describe software/feature requirements requested by the worker configuration. Both machine type capabilities and worker capabilities must be satisfied for image selection to succeed.


		## Motivation

		Currently, machine image capabilities as defined in GEP-0033 only support selecting images based on hardware properties of the machine type (CPU architecture, hypervisor type, bare-metal vs virtualized). However, users increasingly need the ability to select images based on software or feature requirements that are specified in the worker configuration, such as:


		### Provider-Specific Worker Properties

		Provider extensions can define additional worker properties that map to capabilities. This is achieved through the existing `WorkerConfig` extension mechanism:


		## Drawbacks

		- Increased Complexity: Adds a third dimension to capability matching, which increases the complexity of the image selection algorithm.

Conversation

Roncossek commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gardener-prow Bot commented Feb 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ScheererJ left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gardener-ci-robot commented Apr 11, 2026

Uh oh!

gardener-ci-robot commented May 11, 2026

Uh oh!

Roncossek commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Roncossek commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Roncossek commented Feb 26, 2026 •

edited

Loading

Roncossek commented May 22, 2026 •

edited

Loading