Webhook icon
Commands icon
Docker icon
UploadFiles icon
If icon
Log icon
Fail icon

Find the Kubernetes manifests that will break on your next cluster upgrade

Check Kubernetes manifests before a cluster upgrade in Kestra. kubeconform finds removed APIs on the target version, kube-score flags risky settings.

Categories
CloudInfrastructure

Every Kubernetes minor release removes API versions. A manifest that deploys fine on 1.24 can be refused by a 1.29 cluster: policy/v1beta1 PodDisruptionBudgets went away in 1.25, autoscaling/v2beta2 HorizontalPodAutoscalers in 1.26, batch/v1beta1 CronJobs in 1.25. Teams find out when the upgrade is half done. This flow finds out first:

  • It validates every manifest with kubeconform against the schemas of the current and the target version. A manifest valid today but invalid on the target is an upgrade blocker.
  • It scores every manifest with kube-score and lists the critical best-practice findings, such as missing limits, latest tags or no security context.

It needs no cluster and no secrets. Five demo manifests are inline, three of which use removed APIs.

How it works

  1. check (io.kestra.plugin.scripts.shell.Commands, python:3.12-slim) downloads kubeconform v0.6.7 and kube-score v1.19.0 and verifies their SHA-256 checksums. It runs kubeconform -strict -kubernetes-version twice and kube-score score, then writes readiness.md with a valid-now / valid-on-target table and the critical findings.
  2. publish_report (io.kestra.plugin.core.namespace.UploadFiles) writes k8s/upgrade-readiness-<target>.md.
  3. gate (io.kestra.plugin.core.flow.If) passes when nothing is invalid now, nothing breaks on the target and, with min_score_grade: CRITICAL, there are no critical findings. Otherwise not_ready (io.kestra.plugin.core.execution.Fail) lists the blockers.
  4. on_pull_request (io.kestra.plugin.core.trigger.Webhook) for CI.

Quick start

Run Input Result
1 defaults (1.24 to 1.29) Not ready: api-hpa.yaml, api-pdb.yaml and cron.yaml are valid now but not on 1.29. 26 critical kube-score findings reported
2 demo_migrated: true Ready: the same manifests on autoscaling/v2, policy/v1 and batch/v1
3 demo_migrated: true, min_score_grade: CRITICAL Not ready: no removed API, but 26 critical findings, most on worker (no resources, no security context, latest tag)
4 1.23 to 1.24 Ready: none of these APIs is removed in 1.24

kubeconform reports a removed API as could not find schema for <Kind> on the target version, because the old apiVersion no longer has a schema there.

Inputs

  • current_version (STRING, default 1.24.0) and target_version (STRING, default 1.29.0).
  • min_score_grade (SELECT CRITICAL or NONE, default NONE): start with NONE on an existing repository, then tighten.
  • demo_migrated (BOOL, default false): demo only.

Using it with your manifests

  • Replace the inline files with io.kestra.plugin.git.Clone in a io.kestra.plugin.core.flow.WorkingDirectory. For Helm charts, run helm template first and validate the output.
  • Custom resources need their schemas: pass -schema-location to kubeconform, as in its documentation.
  • kubeconform fetches schemas from GitHub on each run. For air-gapped workers, mirror the schemas and point -schema-location at the mirror.

Expected outputs

  • outputs.check.vars: manifests, upgrade_blockers, blockers, invalid_now, critical_count, critical.
  • Namespace file k8s/upgrade-readiness-<target>.md.

Links

This blueprint was created by zkasuran.

See How

New to Kestra?

Use blueprints to kickstart your first workflows.