Yes, if your product has more than one component that customers upgrade separately, such as a server, agents and a command line tool. A version skew policy states which versions may run together and in what order to upgrade. Without it, customers guess, and a rushed security patch becomes an outage.
Definition
Version skew is the difference in version between components that talk to each other. A skew policy is a published rule for how much difference is supported. It also tells customers the safe upgrade order.
A public example to copy the shape from
The Kubernetes version skew policy is a clear model. It states, for example, that a kubelet must not be newer than the API server, and may be up to three minor versions older (two for kubelet versions before 1.25). It says the command line client is supported within one minor version, older or newer, of the API server. It also gives an upgrade order: the API server first, then the controller components, then optionally kubelet and kube-proxy. The project recommends being on the latest patch of your current minor version before moving to the next.
You do not need to copy the numbers. Copy the structure.
| Component pair | Rule to state | Why |
|---|---|---|
| Agent and server | Agent may be N minor versions behind, never ahead | Server must understand agents |
| CLI and server | Within one minor version either way | Tooling tends to drift |
| Server instances in a cluster | Within one minor version | Rolling upgrades need two versions at once |
| Database schema and server | Server states the schema range it accepts | Migrations run once |
Why it matters for security
A security fix usually ships for the newest patch of each supported minor line. If customers cannot tell whether it is safe to upgrade the server without the agents, they delay. A policy that says agents may lag lets customers patch the server now and the fleet later. It also sets a limit: the Kubernetes page warns that a cluster with kubelets persistently three minor versions behind must upgrade them before the control plane can move. State your equivalent limit.
Steps to write yours
- List every component and who upgrades it.
- Test the oldest combination you intend to allow, in CI, every release.
- Write the table and the upgrade order, newest component last or first as your design requires.
- Say that skipping minor versions is or is not supported. The Kubernetes policy requires the API server not to skip minor versions.
- Link the policy from every release note and security advisory.
What to avoid
Do not promise skew you have not tested. A promise you cannot keep is worse than a short one. See also Kubernetes upgrade order.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
How much skew should I support?
As much as you test in CI. The public Kubernetes policy uses small numbers, such as one minor version for the client tool.
Does a skew policy replace upgrade docs?
No. It sits beside them. It states the limits, and the docs give the steps.
Sources
Last reviewed: 19 October 2026.
