Skip to content

Add HIP: Check Kubernetes feature gates with a new flag in Chart #445

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rysurd wants to merge 1 commit into
base: main
Choose a base branch
from
+58 −0
Open

Add HIP: Check Kubernetes feature gates with a new flag in Chart #445

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions hips/hip-9999.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
hip: 9999
title: "Check Kubernetes feature gates with a new flag in Chart"
authors: [ "Idryss Bourdier <thegogolplex@gmail.com>" ]
created: "2026-08-11"
type: "feature"
status: "draft"
---

## Abstract

This proposal aims to resolve issue [31432](https://github.com/helm/helm/issues/31432), offering a way to check each Kubernetes feature gates within Chart.yaml. This is an extra layer of compatibility between a Chart and a cluster, on top of the `kubeVersion` field. When a Chart is installed or upgraded, it will poll the k8s cluster for its feature gates, either per components and per nodes or per a representative node. If a feature gate required isn't activated on the component as declared in Chart.yaml, the installation/upgrade will fail.

## Motivation

There is currently no existing mecanism in Helm that allow polling to Kubernetes before CRDs installation and during installation/upgrade. Moreover, there is no mecanism in place that checks feature gates.

## Specification

Adding a new field in Chart.yaml similar to this format:
```yaml
kubeFeatureGatesPolling: representative #could also be a choice between representative, per nodes, node-name specific, etc
kubeFeatureGates:
kubelet:
SidecarContainers: true
apiserver:
ConstrainedImpersonation: true
scheduler:
ComponentFlagz: false
```

## Backwards compatibility

Fully backward compatible.

@joejulian joejulian Aug 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the chart declares this in its Chart.yaml but an older version of helm is used on that chart?


## Security implications

Since we allow Helm to poll Kubernetes components, we have to sanitize any input and output plus securize the channel. Also, we need to ensure that the Helm operator that is executing the k8s commands on the cluster have the rights to access required Kubernetes components.

## How to teach this

This new field is opt-in and not used by default. It will be added to the documentation if implemented, with a guide on how to use this new feature.

## Reference implementation

There is a pending PR on Helm repo ; [feat(action): add KubeFeatureGates field in Chart definition to check against k8s feature gates](https://github.com/helm/helm/pull/32497)

## Rejected ideas

-

## Open issues

I suggested that we implement a new feature in Kubernetes directly that would expose an endpoint, through the apiserver, that expose all feature gates information across all components and nodes. Ref ; [[Feature request] Single API endpoint for feature gates values](https://github.com/kubernetes/kubernetes/issues/141162)

## References

-