Kubenix: stronger primitives for cluster definitions on Jōkamachi Systems

Why Kubernetes?

Mon, 01 Jan 0001 00:00:00 +0000

Stub.

Jōkamachi Systems has roots in functional programming and classic Linux systems administration. The natural gravitational pull of that combination is towards prescriptive tools — Terraform, NixOS, terranix. You declare how the world ought to be, run the apply, and the tool drives reality towards your specification. Apply once. Done.

This works beautifully when reality cooperates by holding its shape.

The polite fiction of a snapshot

In What functional programmers get wrong about systems (2026), Ian Duncan observes that

Why Kubenix?

Mon, 01 Jan 0001 00:00:00 +0000

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.

Property testing Kubenix

Mon, 01 Jan 0001 00:00:00 +0000

Stub.

The chapter covers the property-testing techniques we apply to Kubenix-defined clusters: invariants that span services, the test runner setup, examples of properties we ship by default, and how to add tenant-specific properties.

A property test for a cluster looks much like a property test for any other piece of typed code: state an invariant in the type system or in code, run a generator that produces representative cluster states, and check that the invariant holds for every generated state. The difference is the substrate — the “code” being tested is the desired state of a cluster, not a function — and the value of the technique scales with how much your cluster’s correctness depends on relationships you can’t see by reading any one chart.