Best practices

Best practices

Sextant checks your workloads for everyday mistakes that make them fragile or wasteful: no probes, an image without a pinned version, a single replica, no PodDisruptionBudget or one that blocks every eviction, all replicas on one node, no requests or memory limit, limits far above real usage. Each finding names the field, says why it matters and gives a fix to copy as YAML. Nothing is changed in the cluster.

Contents: The Best practices page · The checks · Findings and fixes · Details of a workload · Settings · Best-practice findings on the Problems page · Limits

The Best practices page

1. Open Cluster → Best practices (right after Security).
2. Choose one or more namespaces in the namespace filter. With All namespaces the page asks you to choose: it watches the chosen namespaces (at most the first 20) while it is open.
3. Each Deployment, Stateful Set, Daemon Set, Cron Job and Job is listed with its counts of high-, medium- and low-severity findings. A Cron Job's Jobs are judged through the Cron Job. Expand a row to see its findings.

Area narrows the list to Reliability or Efficiency; Severity to High or Medium and above.

Besides the pod template, the checks look at what surrounds a workload: its HorizontalPodAutoscaler, the PodDisruptionBudgets and LimitRanges of its namespace, and where its pods run. A list Sextant cannot read (no permission, or too large) is named at the top, and the checks that need it are skipped rather than guessed.

The checks

Check	Area	Severity	When it is reported
No readiness probe	Reliability	Medium	A container of a Deployment, Stateful Set or Daemon Set declares a port but no container of the pod has a readiness probe.
No liveness probe	Reliability	Low	No container of a Deployment or Stateful Set has a liveness probe.
Image without a pinned version	Reliability	Medium	An image is tagged latest or has no tag. An image pinned by digest is fine.
Image pinned by digest is pulled on every start	Reliability	Low	imagePullPolicy: Always on an image pinned by digest.
Single replica	Reliability	Medium for a Deployment, Low otherwise; Low when an HPA allows it	One replica, or an HPA whose minReplicas is 1. Zero replicas and the Recreate strategy are not reported.
No PodDisruptionBudget	Reliability	Medium	Several replicas and no PodDisruptionBudget selects the pods.
PodDisruptionBudget allows no disruption	Reliability	High	The budget, rounded the way the disruption controller rounds it, lets no pod be evicted, so node drains and cluster upgrades stop.
All replicas on one node	Reliability	Medium	Every running replica is on one node, without topology spread or anti-affinity, while at least two nodes could take the pods (not cordoned, matching the template's nodeSelector and required node affinity, every NoSchedule/NoExecute taint tolerated).
No resource requests	Efficiency	Medium	A container has no CPU or memory request. A limit set alone, or a LimitRange default, counts as a request.
No memory limit	Efficiency	Low	A container has no memory limit. A CPU limit is never asked for: it throttles even when the node has CPU to spare.
Limit far above the right-sizing recommendation	Efficiency	Low	A limit is more than twice what Right-sizing recommends from Prometheus or VictoriaMetrics history. Without history this check is skipped.
HorizontalPodAutoscaler cannot scale	Efficiency	Low	The HPA's minimum equals its maximum.

Init containers are skipped by the probe checks, and one probe of a kind anywhere in the pod is enough.

Findings and fixes

A finding names the container, the exact field (on the HPA or the PodDisruptionBudget when that object holds it), the value found or Not set, and why it matters. Copy the fix copies a suggested change as YAML: a strategic merge patch in which containers are matched by name, or a whole PodDisruptionBudget under Object to create. Put it into your manifests, Helm values or GitOps repository, or paste it into the editor, where Safe apply can preview it.

The checks are deliberately conservative: when Sextant is not sure, it says nothing.

Details of a workload

Deployments, Stateful Sets, Daemon Sets, Cron Jobs and Jobs have a Best practices section in their details with the same findings and fixes, or "No findings: every check that applies here passes."

Settings

Settings… on the page opens Best-practice checks:

• one switch per check, grouped by area (all on by default);
• Namespaces never checked: one name per line, or separated by spaces or commas. By default kube-system, kube-public and kube-node-lease.

The settings apply to the page, the details and the Problems page, and are kept in settings.json under practices (see Settings).

Best-practice findings on the Problems page

Findings can also appear on the Problems page under the category Best practices: one problem per workload and check. Only High and Medium findings send desktop notifications. This category is off by default: turn it on with Best-practice findings on the Problems page or under Notify about in Settings → General → Notifications (one setting for both). While it is off, Sextant watches nothing for it. The right-sizing check never becomes a problem, because it needs history.

Limits

• The page reads workloads of at most 20 namespaces at once and lists at most 500 workloads.
• The checks read objects only; they do not look at what the application does (a readiness probe that always succeeds still counts as a probe).
• AI agents get these findings only through get_problems and only while the category is on (see MCP server).

Next: Security posture, Right-sizing, Problems and notifications.