In Kubernetes API versioning, what do alpha, beta and GA versions promise, and how long must a deprecated version stay served?
answer
- stability lives in the version name
- two switches: API and behaviour
- betas off by default lately
- nine months or three releases
- never deprecate toward less stable
basics
~20 sAlpha versions are off by default and may vanish in any release; beta versions stay served at least 9 months or 3 releases after deprecation; GA versions are never removed within Kubernetes v1. New betas are off by default since v1.24.
solid answer
~50 sThe version name states the stability of one API group's schema. An **alpha** version such as `v1alpha1` is not served unless enabled and may change or disappear in any release. A **beta** version such as `v1beta1` is well tested, but a later version may change the schema; since v1.24 newly introduced betas are off by default and need kube-apiserver `--runtime-config`. A **GA** version such as `v1` may be marked deprecated but is not removed within major version 1. Under the deprecation policy a deprecated beta stays served for at least 9 months or 3 minor releases, whichever is longer, and a version is never deprecated in favour of a less stable one. Clients using a deprecated version get a `Warning` header naming the removal release and the replacement. Feature gates are a separate switch for behaviour, and alpha features often need both.
go deeper
Recall the three levels, which ones are served by default, and that a deprecated beta gets roughly three releases of notice.
Explain the deprecation rules, the runtime-config versus feature-gate split, and why storage survives a removed served version.
Show how you track removal releases from warnings and release notes, and plan migrations inside the deprecation window rather than at upgrade time.
Decide the platform's policy on enabling beta APIs: which teams may depend on them, and what that commitment costs at every upgrade.
## What a version string promises Kubernetes versions each **API group** independently, and the version name states how stable the schema is. A name has the form `v<N>`, `v<N>beta<M>` or `v<N>alpha<M>`. | Level | Example | Default | Promise | |---|---|---|---| | **Alpha** | `v1alpha1` | Not served | May change incompatibly or disappear in any release; not for production | | **Beta** | `v1beta1` | Not served for betas introduced since v1.24 | Well tested, schema may still change in a later version, with a deprecation period | | **Stable (GA)** | `v1`, `v2` | Served | Not removed within Kubernetes major version 1 | The version belongs to the **API**, not to the feature. A GA group can have a newer beta version beside it, and the same object can be read through several served versions, because the API server converts between them. ## Enabling versions and features Two separate switches exist, and alpha functionality usually needs both: - **API versions** are switched with the kube-apiserver `--runtime-config` flag, for example `--runtime-config=resource.k8s.io/v1beta2=true`, or `api/beta=true` for all beta versions. Without it, a disabled version is simply not in discovery. - **Feature gates**, set with `--feature-gates` on each component, switch behaviour. Alpha gates are off by default, beta gates are usually on (some ship off by default), and a GA gate is **locked on** and later removed from the code, as happened to `SidecarContainers`. Before v1.24 new beta APIs were served by default, so clusters picked up betas nobody chose, and upgrades later removed them from under running pipelines. Since v1.24, newly introduced beta API versions are off by default; kube-apiserver keeps an explicit list of them, including `resource.k8s.io/v1beta2` and `storage.k8s.io/v1beta1` in v1.37. ## The deprecation policy The Kubernetes deprecation policy fixes how long a version stays served after it is marked deprecated: - **GA**: may be marked deprecated, but must not be removed within the major version. - **Beta**: served for at least **9 months or 3 minor releases** after deprecation, whichever is longer. - **Alpha**: may be removed in any release, with no notice period. Further rules shape which versions can be removed: 1. Fields and objects may only be removed by introducing a new version of the group; within a version the schema only grows compatibly. 2. Objects must round-trip between the versions served in one release without losing information. 3. A version may not be deprecated in favour of a **less stable** one: a GA version is never replaced by a beta. 4. Beta versions are not meant to live forever: the generated lifecycle metadata deprecates a beta three minor releases after it was introduced and removes it three releases after that, unless its authors set other values. A worked example from the v1.37 source: `flowcontrol.apiserver.k8s.io/v1beta3` was introduced in v1.26, deprecated in v1.29 and stopped being served in v1.32, with `flowcontrol.apiserver.k8s.io/v1` named as the replacement. ## How deprecation reaches users When a client uses a deprecated version, kube-apiserver returns a **Warning** response header, which `kubectl` prints, in the form `<group/version> <Kind> is deprecated in v1.X+, unavailable in v1.Y+; use <group/version> <Kind>`. The server also records the request in the `apiserver_requested_deprecated_apis` metric and adds the `k8s.io/deprecated` and `k8s.io/removed-release` annotations to the audit event. The published release notes and the deprecated API migration guide list each removal ahead of time. ## Storage is separate from serving For each resource the API server writes one **storage version** to etcd and converts to whatever served version a client asks for. Dropping a served version therefore does not delete objects: they stay readable through the remaining versions. What breaks is every client and manifest that still **sends or requests** the removed version, such as Git repositories, CI jobs and controllers built on old client libraries. ## Why interviewers ask A team whose loyalty-points accrual service was scaled by an `autoscaling/v2beta2` HorizontalPodAutoscaler met this in v1.26, when that version stopped being served: the live HPA kept working, but the next pipeline run failed to apply the manifest. Knowing the policy lets you predict the release in which that happens and migrate during the deprecation window, not after it. Interviewers usually probe three points: - whether you know which level a version is at from its name alone; - whether you can say how much notice a beta removal gets, and where that notice appears; - whether you separate the served versions from the one storage version, and therefore know that removal breaks clients, not data.
- What is the difference between enabling an API version and enabling a feature gate?`--runtime-config` on kube-apiserver decides whether a `group/version` is served at all, such as `resource.k8s.io/v1beta2=true`. `--feature-gates`, set per component, switches behaviour, including new fields inside a GA type. Alpha gates are off by default, beta gates usually on, and GA gates are locked on and later removed from the code. Alpha functionality often needs both switches.
- Why did Kubernetes stop serving new beta APIs by default in v1.24?Default-on betas ended up in production without anyone choosing them. Tools and manifests came to depend on them, and when the beta was removed after its deprecation window, upgrades broke pipelines. Making new betas opt-in means a cluster only serves a beta its operator enabled on purpose, so the removal surprises fewer people.
- Does removing a served version delete the objects created through it?No. The API server writes each resource at one storage version and converts on read, so existing objects stay available through the versions that remain. What fails is any client or manifest that still sends or requests the removed version, such as a CI job that runs `kubectl apply` on an old file.
An API version is like a product's support tier: a preview build can be pulled any day, a release candidate gets a fixed notice period before it is withdrawn, and the long-term release is supported for the whole product line.
saying these in an interview costs you the question
- Believes every beta API is served by default in current clusters
- Thinks a GA v1 API can be removed after three releases
- Assumes removing a version deletes objects stored through it
- Treats feature gates and served API versions as the same switch
- Thinks alpha versions get a deprecation period before removal