Introduction

Feature gates in Kubernetes are configuration flags that turn specific features on or off in Kubernetes components. They are commonly used for alpha and beta features, and sometimes for behavior that remains configurable while a feature is rolling through the maturity process.

The important detail is that feature gates are component-specific. You do not enable them once “for the cluster” in the abstract; you enable them on the control-plane or node components that actually read that gate.

The Basic Flag Format

The command-line form is a comma-separated list passed through --feature-gates.

--feature-gates=SomeFeature=true,AnotherFeature=false

The exact gate name and which components honor it depend on the Kubernetes version and the feature itself. Before enabling any gate, check the current Kubernetes documentation for that specific gate and version.

Enable a Gate on Static Pod Control-Plane Components

In many kubeadm-based clusters, control-plane components such as kube-apiserver, kube-controller-manager, and kube-scheduler run as static pods. Their manifests live under /etc/kubernetes/manifests/.

A static pod manifest entry might look like this:

1spec:
2  containers:
3    - command:
4        - kube-apiserver
5        - --feature-gates=SomeFeature=true

After the manifest is updated, the kubelet notices the file change and recreates the static pod automatically.

This same pattern applies to other control-plane components when the feature gate documentation says they must also be configured.

Enable a Gate with kubeadm Configuration

If you manage cluster configuration declaratively with kubeadm, it is often cleaner to put the gate into the kubeadm config rather than editing generated manifests manually.

Example ClusterConfiguration fragment:

1apiVersion: kubeadm.k8s.io/v1beta4
2kind: ClusterConfiguration
3apiServer:
4  extraArgs:
5    feature-gates: SomeFeature=true
6controllerManager:
7  extraArgs:
8    feature-gates: SomeFeature=true
9scheduler:
10  extraArgs:
11    feature-gates: SomeFeature=true

Then apply the updated kubeadm workflow that matches your upgrade or configuration process.

For kubelet-specific gates, use KubeletConfiguration instead of assuming the API server setting is enough.

Kubelet Feature Gates

Many node-level features require the kubelet to be configured explicitly. For kubelet config, the pattern is typically:

1apiVersion: kubelet.config.k8s.io/v1beta1
2kind: KubeletConfiguration
3featureGates:
4  SomeFeature: true

This matters because feature gates are not universally consumed by every component. A gate may need to be enabled on the API server, controller manager, scheduler, kubelet, or several of them together.

Always read the gate description carefully to see where it must be set.

Managed Kubernetes Considerations

On managed Kubernetes platforms, you may not be allowed to change control-plane flags directly. In those environments, feature gate support depends on what the provider exposes.

That means the operational question becomes:

• does the provider support this feature gate at all
• if yes, where is it configured
• if not, do you need a different cluster version or a different deployment model

For managed clusters, the provider documentation is often as important as the upstream Kubernetes docs.

Verifying That the Gate Is Enabled

After changing configuration, verify rather than assume. Useful checks include:

• inspect the running static pod manifest or component arguments
• examine the kubelet config in use on the node
• check component logs for startup arguments
• validate the feature behavior directly with a targeted test

For example, you can inspect a static pod manifest on a control-plane node:

grep feature-gates /etc/kubernetes/manifests/kube-apiserver.yaml

You can also check the process arguments through Kubernetes-managed manifests or through the node process listing, depending on how the cluster is deployed.

Be Careful with Version-Specific Gates

Feature gates move over time. Some gates disappear when a feature graduates to stable. Others are renamed, become locked to true, or stop being configurable.

That is why copying old cluster examples blindly is risky. The gate name and expected behavior may have changed in a newer Kubernetes release.

Common Pitfalls

One common mistake is enabling the gate only on the API server when the feature also requires kubelet or another control-plane component to be configured.

Another issue is editing a generated manifest by hand in an environment where automation will later overwrite it. If kubeadm or another provisioning system owns the configuration, update the source of truth instead of only the generated file.

It is also easy to copy a gate name from an article that targets a different Kubernetes version. Feature gates are among the more version-sensitive parts of Kubernetes configuration.

Finally, do not enable alpha features casually in production. Gates exist partly because those features may still change behavior or carry operational risk.

Summary

• Feature gates are enabled per Kubernetes component, not as a single abstract cluster toggle.
• The common command-line form is --feature-gates=FeatureName=true.
• In kubeadm-based clusters, control-plane gates are often configured through static pod manifests or kubeadm extraArgs.
• Kubelet gates are usually configured through KubeletConfiguration under featureGates.
• Always verify the exact gate name and supported configuration path for your Kubernetes version before changing anything.