Feature support

What Corium models, what it passes through, and what it deliberately does not do.

This page exists so you can tell, before committing to Corium, whether it will get in your way. The short answer: Corium models the settings most clusters need, and everything else in k0s stays reachable through a passthrough patch. There is no feature you can configure in k0s that Corium prevents you from configuring — only features it does not give a shorter name to.

Anything describing k0s behaviour here links to the official k0s documentation. Corium does not fork or patch k0s; when the two disagree, k0s is right and this page is stale.

Three levels of support#

Passthrough is not a lesser tier for things that were forgotten. It is where settings belong when they are rarely needed, cluster-specific, or change faster upstream than a schema should. A modelled field is a promise to support that spelling forever; that promise is expensive, so it is made sparingly.

Modelled#

Cluster shape#

Networking#

Storage#

High availability#

Nodes#

Joining#

Add-ons#

Upgrades#

Disks#

Overlay networking#

This is a host concern, distinct from the pod-traffic encryption a CNI offers: the overlay is what lets hosts on different sites or providers reach each other at all. wireguard-tools ships present but inert until an interface is declared.

Management API#

Off unless asked for. The decision is ADR 4; the commands are cctl.

A node in maintenance mode is not a cluster member: it validates its configuration and waits, rather than joining first and being claimed later. Enrolment carries no configuration — it sends a CA certificate and nothing else, and the node’s role and join token still come from cloud-init.

Where configuration comes from#

Passthrough#

Everything else k0s exposes is set through k0s.patch, applied verbatim to the rendered k0s.yaml after Corium is done. Maps merge key by key; lists are replaced wholesale.

This is verified, not asserted — the example below renders with every field intact alongside the values Corium computed:

corium:
  role: controller+worker
  k0s:
    patch:
      spec:
        network:
          kubeProxy:
            mode: ipvs            # or nftables, userspace, or disabled
          nodeLocalLoadBalancing:
            enabled: true         # Envoy on each worker, no external LB
            type: EnvoyProxy
          dualStack:
            enabled: true
            IPv6podCIDR: fd00::/108
        workerProfiles:
          - name: default
            values:
              maxPods: 150
        images:
          repository: registry.example.com/mirror
        featureGates:
          - name: SomeGate
            enabled: true
        konnectivity:
          agentPort: 8132

Commonly reached this way:

One passthrough field is worth avoiding: spec.extensions.storage is a deprecated no-op from k0s 1.31 onwards. It still parses, so a configuration using it looks accepted and does nothing. Install storage as an add-on instead.

A patch can also override anything Corium computed, including values it treats as load-bearing. That is what makes it an escape hatch rather than a suggestion. Corium checks only that the result is valid YAML.

The second escape hatch is that your document stays an ordinary cloud-config: write_files, runcmd, users and every other module keep working. Corium is a guest in that document, not its owner.

Static configuration, not dynamic#

k0s can run in two modes. By default it reads k0s.yaml from disk on every controller. With --enable-dynamic-config it instead stores a ClusterConfig resource in the cluster, and controllers reconcile against that.

Corium writes a static configuration file. It does not pass --enable-dynamic-config, which means:

• Changing the configuration means reprovisioning the node, in keeping with the rest of the design: a node is rebuilt from an image, not adjusted in place.
• Mixing controllers that use dynamic config with ones that do not is a documented conflict in k0s. If you enable it, enable it everywhere.

If you want dynamic configuration, three parts of the configuration stay file-local and per-controller regardless — spec.api, spec.storage, and spec.network.controlPlaneLoadBalancing — so they must still be identical across controllers. That is precisely what Corium’s rendering already guarantees, since every controller in an HA cluster renders the same file.

See k0s: dynamic configuration.

Out of scope#

These are decisions, not gaps. Each would be straightforward to add; none should be.

Not supported yet#

Honest about the difference: these are absent because nobody has needed them enough, not because they are wrong.

Defaults#

Corium’s defaults match k0s’s wherever k0s has one, so that a Corium node and a hand-configured k0s node agree unless there is a reason to differ.

The one deliberate difference is the cluster name, which only affects generated kubeconfig contexts.

Values k0s sets that Corium does not touch — API port 6443, join API port 9443, konnectivity ports 8132/8133, cluster domain cluster.local, certificate lifetimes — keep their k0s defaults. Run k0s config create on a node to see the full set as your version defines it.