Why Kubenix?

Stub.

Kubernetes runs whatever spec you hand it; the question this chapter answers is what kind of artefact the spec should be. The short answer is: not a pile of Helm charts.

Helm charts are the Kubernetes ecosystem’s standard way to ship a service. Each chart, in isolation, works fine. But a real cluster is not one service; it’s many services, often inter-dependent, often sharing config — DNS names, certificates, secrets, network policies, RBAC bindings — that no individual chart owns.

The standard answer is to wrap charts in shell scripts, Make recipes, or umbrella charts that re-template their dependencies. This approach gets you running, but it leaves the relationships between services implicit and unchecked. Every change is a guess; every refactor is a leap of faith.

Not to mention, Helm charts are whitespace-sensitive and untyped.

Kubenix gives us a typed primitive for the cluster as a whole, where the inter-service relationships are first-class. The single strongest argument for Kubenix is that tying service Helm charts together with stronger primitives makes horizontal property testing feasible. You can write properties that span services — “no service exposes a secret in plain text via env vars”, “every ingress is behind the same network policy”, “every cron job has a deadline”, “every PersistentVolume has a backup schedule that matches its PVC’s labels” — and check them across the entire cluster, not one chart at a time.

Subsequent chapters cover what we test in practice and how to add your own properties.