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

[rysurd]

Summary

This HIP proposes a new Chart.yaml field aimed at enhancing the platform requirements for a chart.

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.

Related

• Issue: Chart.yaml lists required Kubernetes feature gates helm#31432
• Draft Pull Request: helm/pull/32497

Checklist

• HIP follows the template from HIP-0001
• HIP is in draft status

[joejulian]

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

[joejulian]

Thanks for opening this as a HIP. This is the right way to work the question, and framing feature gates as a finer-grained companion to kubeVersion is a reasonable motivation. A few things it needs before it can move, and most of them are the questions that sent it here rather than anything wrong in the current text.

The big ones:

1. Core versus plugin. This is the central question and the HIP does not take a position. Given what the design depends on (below), the strongest version of this either makes the case for why it belongs in core, or proposes it as a plugin. Right now it assumes core without arguing it.

2. The polling mechanism, and its reliability. The spec says "poll the cluster for its feature gates" but not how, and the how is the hard part. Your own Open issues section is the crux, not a footnote: there is no single API for feature-gate state today, which is why you filed [Feature request] Single API endpoint for feature gates values kubernetes/kubernetes#141162. Until that exists, the only way to read this is scraping each component's /metrics, including the kubelet, which is version-dependent and unreachable for many users. The HIP needs to confront that directly and say what the plan is: wait for the upstream API, ship as a plugin in the meantime, accept the limitation, or something else. As written it reads as if the data is readily available, and it is not.

3. Least-privileged users. Helm is designed to work for people who only have namespace access, which is part of why release state lives in a Secret rather than requiring cluster-level access. Polling the apiserver and kubelet needs privileges many installers do not have, so "the operator must have the rights" silently turns the feature off for a large class of users. The HIP should state what happens for them.

4. Chart apiVersion. This adds a field to Chart.yaml, which changes the chart contract, so it should land in charts v3, not v2. An older Helm that does not understand kubeFeatureGates would silently ignore it and install anyway, defeating the purpose. Please specify v3 (the reference PR currently targets v2, which would need to change).

5. Decide the behavior the spec leaves open. The representative versus per-node choice is a correctness question, not just config: if a gate differs across nodes, "representative" can be wrong. The HIP should also decide what happens when the poll fails (fail open or fail closed), how an unknown or absent gate is treated, and whether a subchart's feature-gate requirements are checked or only the top chart's. These all came up on the reference PR and belong here.

Smaller things:

• Add a Rationale section. It goes straight from Motivation to Specification, and Rejected ideas is empty. The plugin-versus-core call, the flat-map-versus-per-component shape, and "wait for the upstream API" are all real alternatives worth recording.
• Typos: "mecanism" should be "mechanism", "securize" should be "secure".
• The authors name and the PR author handle do not match; worth making them consistent.

None of this is a no. It is the right feature to reason about and the right venue. It mainly needs to answer the questions it was opened to answer, especially core-versus-plugin and how it reads the data given there is no stable API for it yet. Happy to keep reviewing as it develops.

Two optional adds if you want them: I can turn point 2 into a concrete suggestion that the HIP's own linked upstream API (k8s#141162) become an explicit dependency or gating condition (i.e. "core support waits on a stable API; until then it is a plugin"), which would give rysurd a clean path rather than an open-ended "confront this." And if you'd rather this be a REQUEST_CHANGES review than a comment, say so and I'll tighten the opener to match.

[rysurd]

Hello @joejulian and thanks a lot for these feedbacks and advices ! I'll rework the HIP according to your comments but I think some parts will be tricky. I'll notice you again when I finish :)