skip to content

On a managed Kubernetes control plane, why can't you set kube-apiserver flags or enable alpha feature gates, and what do you use instead?

level: middleimportance: should knowfreq 42%

answer

  1. provider owns the process
  2. fleet-wide config, SLA, upgrade safety
  3. alpha: off by default, may vanish
  4. configure through API objects instead
  5. gate off: field silently dropped

basics

~20 s

The provider owns the kube-apiserver command line and supports only tested, GA or beta behaviour across its fleet. You configure the cluster through API objects instead: admission policies, webhooks, CRDs, API Priority and Fairness objects and RBAC.

solid answer

~40 s

On a managed control plane the `kube-apiserver` process and its flags are the provider's configuration, applied identically across thousands of clusters that it must upgrade, back up and support. So flags such as `--feature-gates`, `--enable-admission-plugins`, `--audit-policy-file`, `--encryption-provider-config` or `--service-node-port-range` are either fixed or exposed only as a few curated options. Alpha feature gates are almost never offered because alpha features are off by default, can change or disappear without deprecation, and could leave data the provider cannot upgrade. What remains is everything configurable **through the API**: `ValidatingAdmissionPolicy` and `MutatingAdmissionPolicy`, admission webhooks, CRDs and operators, `FlowSchema`/`PriorityLevelConfiguration` for request fairness, and RBAC. A feature that needs an alpha gate on the API server, like a container's `lifecycle.stopSignal`, simply waits for beta or runs on a self-managed cluster.

go deeper

for a junior

Remember that on a managed cluster you cannot change API server flags, and that most configuration is done by creating objects through the API.

for a middle

Explain why providers lock flags and alpha gates, and name the API objects that replace them: admission policies, webhooks, CRDs, APF objects and RBAC.

for a senior

Diagnose a gated field that silently disappears, and know which features need the API server gate versus only the kubelet gate.

for a principal

Treat recurring flag requests as a platform signal: decide whether they justify a self-managed cluster tier or an application change.

## Where configuration lives in Kubernetes Kubernetes control-plane behaviour is set in two places: - **Component flags and config files**: command-line options of `kube-apiserver`, `kube-controller-manager` and `kube-scheduler`, plus files they read at start (audit policy, encryption configuration, structured authentication and authorization configuration). - **API objects**: resources you create through the API server, which the control plane reads at runtime. On a self-run cluster you own both. On a **managed control plane** the provider owns the first entirely, because it owns the processes. ## Why the provider locks the flags 1. **Fleet uniformity.** The provider upgrades, patches and backs up a very large number of clusters with the same automation. Every custom flag is a combination it would have to test on every release. 2. **Supportability.** An SLA on the API endpoint is only credible if the provider knows how the server is configured. 3. **Security baseline.** Flags such as `--anonymous-auth` or the admission plugin list decide how exposed the endpoint is; the provider keeps them in a known state. 4. **Alpha features are unsafe to host.** An **alpha** feature gate is off by default, may change its API shape or be removed without a deprecation period, and can write fields into `etcd` that a later release no longer understands. A provider cannot promise to upgrade such a cluster. Beta features that are on by default in the release are normally enabled on managed clusters too, because they are on upstream. Beta features that are off by default, and all alpha features, usually are not. ## What you lose | Flag or file | What it controls | Typical managed-service situation | |---|---|---| | `--feature-gates` | Alpha and off-by-default beta features | Fixed by the provider | | `--enable-admission-plugins` | Built-in admission plugins | Provider's curated set | | `--audit-policy-file` | What the API server records in audit logs | Provider's policy, logs exported if enabled | | `--encryption-provider-config` | Encryption of Secrets at rest in etcd | A provider option, often tied to its key service | | `--authentication-config` | Structured authentication, such as extra OIDC issuers | Exposed only if the provider offers it | | `--service-node-port-range` | The NodePort range | Fixed | ## What you use instead - **Admission policy as objects.** `ValidatingAdmissionPolicy` (GA, `admissionregistration.k8s.io/v1`) expresses CEL rules without a webhook; `MutatingAdmissionPolicy` is GA from 1.36. These replace most reasons to want a custom admission plugin. - **Admission webhooks** for logic CEL cannot express, including policy engines. - **CRDs and operators** to add new object types and reconcile loops. - **API Priority and Fairness** objects (`FlowSchema`, `PriorityLevelConfiguration`, `flowcontrol.apiserver.k8s.io/v1`) to shape how the API server queues requests from noisy clients. - **RBAC** for fine-grained authorization. - **Node-side configuration** on nodes you control: `KubeletConfiguration` has its own `featureGates` map. This only helps when the feature is purely kubelet-side. ## A worked example A team wants its recommendation-model inference server to receive `SIGUSR1` instead of `SIGTERM` when stopped, so it can finish in-flight batches. Kubernetes has a container field for that, `lifecycle.stopSignal`, behind the `ContainerStopSignals` feature gate, which is **alpha since 1.33 and off by default**. The feature needs the gate on the API server as well as on the kubelet. With the gate off, the API server **silently drops** the field when the Pod is created, so the manifest applies without error and the container still gets the runtime's default signal. Turning the gate on for the kubelets of a managed node group does not help, because the field never reaches them. ```yaml apiVersion: v1 kind: Pod metadata: name: recsys-inference spec: os: name: linux containers: - name: server image: registry.example.com/recsys-inference:2.14.1 resources: limits: memory: 2.6Gi lifecycle: stopSignal: SIGUSR1 # dropped by the API server while the gate is off ``` The realistic options are: handle `SIGTERM` in the application (the portable fix), use a `preStop` hook to signal the process, or wait until the feature is enabled by default in a release the provider offers. ## How to judge a flag request When a team asks for an API server flag on a managed cluster, ask whether an **API object** can express it first. Most requests (admission rules, request fairness, extra types) can. Requests that genuinely need a flag, such as an alpha gate or a custom audit backend, are a signal that the workload belongs on a self-managed cluster or should wait.

  • Can you still use an alpha feature that only needs the kubelet gate on a managed cluster?
    Sometimes. The kubelet reads `featureGates` from its own `KubeletConfiguration`, so on self-managed nodes you can set it. Managed node groups may not expose that option. And many features need the gate on the API server too, because the API server drops disabled fields before any kubelet sees them. Check which components a feature touches before assuming node access is enough.
  • Why does a manifest using a disabled field apply without an error?
    For many gated fields the API server strips the field during create when the feature is off, instead of rejecting the request, so the object is stored without it. `kubectl apply` reports success. Reading the object back with `kubectl get -o yaml` shows the field missing, which is the quickest way to confirm the gate is off.
  • When is the lack of API server flags a reason to run your own control plane?
    When the requirement genuinely lives in a flag or file: an alpha feature you depend on, a custom audit backend, an authentication setup the provider does not expose, or a NodePort range your network demands. If an API object, a webhook or an application change can express it, stay managed.

saying these in an interview costs you the question

  • I can pass extra kube-apiserver flags to a managed cluster through a ConfigMap.
  • Enabling a feature gate on the kubelets is enough for any feature.
  • Providers turn on every beta feature gate, including off-by-default ones.
  • Without API server flags there is no way to add admission rules.
  • If the gate is off, kubectl apply fails with a validation error.