A comparison · back to the rollout safety checker
These tools are often mentioned in the same breath and answer different questions. This page says which is which, including where the other one is the better choice. It describes kube-score as a category of tool — a general manifest linter, alongside Polaris and kubeaudit — from its published behaviour; it is not affiliated with, endorsed by, or a benchmark against any of them.
Both, for different jobs. kube-score is a broad manifest linter: it scores a manifest across dozens of rules spanning resource limits, security contexts, image tags, network policies and probes, and it is the better choice when you want one gate covering general manifest hygiene. This checker asks a single question — can this rolling update or node drain drop a live request? — and answers it with the causal chain rather than a rule name. Use the broad linter as your standing CI gate, and this one when you are specifically investigating errors that appear during deploys.
| General manifest linter | This checker | |
|---|---|---|
| Question asked | Does this manifest follow recommended practice across many dimensions? | Can this rollout or node drain drop a live request? |
| Output | A score and a list of rule results | Findings at two levels, each with the user-visible consequence and the YAML fix |
| Scope | Most workload kinds, many rule categories | Deployment and PodDisruptionBudget only; other kinds listed as skipped |
| Relational checks | Generally per-field | Grace period vs. preStop duration; maxUnavailable vs. replicas; PDB vs. replicas; liveness vs. readiness |
| Install | Go binary, container image, or Krew plugin | Nothing in the browser; two files on Node 18+ for the CLI |
| Cluster access | Optional, for some checks | None, ever — it reads YAML text and makes no network calls |
They overlap on the readinessProbe rule and diverge everywhere else. The checks here that a general linter does not typically make are the relational ones: whether terminationGracePeriodSeconds is long enough to cover the preStop hook it is paired with, whether maxUnavailable resolves — after Kubernetes' round-down arithmetic — to the full replica count, whether the livenessProbe is a copy of the readinessProbe, and whether a PodDisruptionBudget is satisfiable at the Deployment's replica count. Each of those is a relationship between two fields, sometimes in two different resources, rather than a property of one field.
The grace-period case is the clearest example of why that distinction matters. A manifest with a 30-second preStop hook and the default 30-second grace period passes any per-field check: it has a preStop hook, and it has a grace period. The defect is only visible when the two are read together — SIGKILL lands at the moment preStop returns, so the application never drains at all, and the configuration is worse than having no preStop hook while looking considerably more careful.
Because a score answers "how am I doing?" and the question here is "will this specific thing break?". A score of 7/10 does not tell you whether the three missing points are the ones that drop requests. Findings are reported at two levels only — it can drop requests, or it is worth reviewing — and each one names the resource, the container, what a user experiences when it fires, and the YAML that fixes it.
Yes. The browser page needs no install at all and uploads nothing — paste the manifest and read the result. The CLI is two files of plain JavaScript that run on Node 18 or later with no dependencies, no Go toolchain, no container image and no kubeconfig. kube-score is distributed as a Go binary, container image and Krew plugin, which is a better fit if you already manage tooling that way.
Try it on one manifest. Paste a Deployment and see whether its rollout can drop requests. Nothing is uploaded, no cluster access is needed, and --list-checks shows the complete rule list before you trust any of it.