Upgrade readiness

Upgrade readiness

Before you upgrade Kubernetes, Cluster → Upgrade readiness tells you what would break: API versions your manifests, Helm charts and GitOps sources still use that the target version no longer serves, deprecated API versions the cluster still serves, and version skew between the control plane and the nodes. It works like Pluto or kube-no-trouble, inside Sextant and through your own connection. Nothing is changed in the cluster.

Contents: Using the page · API versions in use · Where a use comes from · Served deprecated versions · Version skew · The deprecation table · Limits

Using the page

1. Open Cluster → Upgrade readiness (or type upgrade in the command palette). The cluster is scanned when you open the page for the first time; Scan again repeats it.
2. Choose the Target version. The default is the next minor version after the cluster's (for example 1.33 → 1.34). Changing the target or the filters re-evaluates the last scan without asking the cluster again.
3. Read the counts at the top (removed, deprecated, served deprecated versions, skew problems) and the three parts below.
4. Copy as Markdown or Copy as CSV copies the report, for a ticket or an upgrade plan.

API versions in use

Each row is one object that uses an API version deprecated or removed in the target: Status (Removed or Deprecated), kind, namespace, name, the API version used, when it was deprecated and removed, what to Use instead, and the Source. A version with no replacement says what to do instead (for example PodSecurityPolicy: use Pod Security Admission or an admission webhook).

Filters: Live objects, Helm, Argo CD, Flux, and Show traces of old writes. A trace of an old write is a version a live object names only in its last-applied annotation or its field managers while the cluster already stopped serving it: the object was written in that version once, which breaks nothing now, so these rows are hidden by default.

Where a use comes from

The API server always returns an object in the version you ask for, so "which version does this come from" is read from what clients left behind:

Source	What Sextant reads
Last applied by kubectl	The kubectl.kubernetes.io/last-applied-configuration annotation of live objects
Written by field manager …	The API version each field manager last wrote (managedFields), so a CI job or an operator that still writes an old version is named
Helm release	The manifest of the latest revision of every release, as Helm stored it in the cluster
Argo CD application	The resources the Application reports in its status (no access to Git)
Flux Kustomization	The inventory of the Kustomization (no access to Git)

Only names, kinds and API versions are taken from Helm manifests; their contents and values never leave Sextant's backend. A source you may not read, or a tool that is not installed, is reported above the table and does not stop the scan.

Served deprecated versions

Deprecated API versions the cluster serves lists the versions of the table that the cluster still answers to: clients can use them now and may fail after the upgrade. This catches scripts and tools that are not visible in stored objects.

Version skew

Checked against the Kubernetes version skew policy, now and at the target:

• the control plane is upgraded one minor version at a time: a target further away lists every version to go through;
• kube-apiserver instances are at most one minor version apart;
• a kubelet (and kube-proxy) is never newer than kube-apiserver and at most three minor versions older (two before 1.25); nodes that would be too old at the target are named, so you upgrade them first;
• kube-proxy is within the same distance of the kubelet on its node;
• kube-controller-manager, kube-scheduler and cloud-controller-manager are never newer than kube-apiserver and at most one minor version older.

Control-plane components are visible only when they run as kubeadm-style static pods in kube-system. On a managed control plane (EKS, GKE, AKS…) only the node rules are checked, and the page says so.

The deprecation table

Sextant carries its own table of deprecated and removed API versions, copied from the Kubernetes deprecation guide. It is part of each release and never downloaded; the page says up to which Kubernetes version it covers. It is reviewed for every Kubernetes minor release; if your target is newer than the table, removals of that release are not known yet.

Limits

• The page sees stored objects and manifests, not clients that call deprecated APIs at run time. Before upgrading, also check the API server's apiserver_requested_deprecated_apis metric.
• On very large clusters the scan reads at most 2000 objects per kind, 300 Helm releases and 1000 Argo CD applications or Flux Kustomizations; a source that hit its limit says so.
• Only APIs a cluster serves by default are in the table; CRD versions are not checked.
• Upgrade readiness is not available to AI agents or extensions.

Next: Using Sextant, Security posture.