Feature support

This page lists what Corium models, what it passes through, and what it does not do on purpose.

Read this page before you commit to Corium, to find out if Corium will get in your way. The short answer: Corium models the settings that most clusters need, and everything else in k0s stays reachable through a passthrough patch. Corium does not prevent you from configuring any k0s feature. It only gives a shorter name to some of them and not to others.

Each description of k0s behavior on this page links to the official k0s documentation. Corium does not fork or patch k0s. If the two disagree, k0s is right and this page is out of date.

Three levels of support#

Passthrough is not a lower tier for forgotten settings. See why a setting ends up there.

Modelled#

Cluster shape#

Networking#

Storage#

High availability#

Nodes#

Joining#

Add-ons#

Bundled manifests#

Upgrades#

Backups#

Kubernetes version#

Disks#

Overlay networking#

Not the same as a CNI’s encryption#

This is a host concern. It is different from the pod-traffic encryption that a CNI gives. The overlay lets hosts on different sites or providers reach each other at all. wireguard-tools is in the image but does nothing until you declare an interface.

Management API#

Off unless you ask for it. The decision is ADR 4. The commands are in cctl.

Schema fields#

api.insecure is for test benches and controlled provisioning networks. The node shows this on its console, and records that its claim was not authenticated.

A node in maintenance mode is not a cluster member. It validates its configuration and waits. It does not join first and then wait for a claim. Enrolment carries no configuration. It sends a CA certificate and nothing else. The role and the join token of the node still come from cloud-init.

How the daemon works#

What it can be asked to do#

These are commands, not schema fields. The syntax, flags, and output are in cctl.

Why cctl drain is controllers only. A worker holds kubelet credentials, and these cannot evict pods. To drain a worker, use kubectl drain with the kubeconfig that cctl kubeconfig gets.

Where configuration comes from#

Passthrough#

You set everything else that k0s exposes through k0s.patch. Corium applies the patch verbatim to the rendered k0s.yaml after it is done. It merges maps key by key and replaces lists in full.

A setting goes here when few clusters need it, when it is specific to one cluster, or when upstream changes it faster than a schema can follow. A modelled field is a promise to support that spelling forever. That promise is expensive, so Corium makes it only for a small number of settings.

This was tested. The example below renders with every field intact, next to the values that 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:

What a patch can and cannot do#

Avoid spec.extensions.storage. From k0s 1.31, it is deprecated and does nothing. It still parses, so a configuration that uses it looks accepted but has no effect. Install storage as an add-on instead.

A patch can override anything Corium computed, including values that Corium needs to work. This makes the patch an escape hatch and not only a suggestion. Corium checks only that the result is valid YAML.

Your document stays an ordinary cloud-config. write_files, runcmd, users and every other module continue to work. 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 stores a ClusterConfig resource in the cluster instead, and controllers reconcile against that resource.

Corium writes a static configuration file. It does not pass --enable-dynamic-config. This has two results:

• To change the configuration, you reprovision the node. This agrees with the rest of the design: you rebuild a node from an image, you do not adjust it in place.
• k0s documents a conflict when some controllers use dynamic configuration and others do not. If you enable it, enable it on all controllers.

If you use dynamic configuration, three parts of the configuration always stay in a local file on each controller: spec.api, spec.storage, and spec.network.controlPlaneLoadBalancing. Thus they must be identical on all controllers. Corium already makes sure of this, because every controller in an HA cluster renders the same file.

See k0s: dynamic configuration.

Out of scope#

These are decisions, not gaps. Each one is easy to add, but Corium must not add any of them.

On fleet management. The management API does not change that answer. It is one daemon per node that answers for that node. It has no registry, no inventory, and no desired state. A rolling upgrade is a cctl loop over the addresses that you supply.

On removing add-ons. If you delete a chart from the configuration, the release stays in place. Thus cctl apply refuses a day-two document that removes a chart. It does not report a removal that did not happen.

Not supported yet#

These features are absent because nobody needed them enough, not because they are wrong.

Defaults#

Where k0s has a default, Corium uses the same default. Thus a Corium node and a k0s node configured by hand agree, unless there is a reason to differ.

The only intentional difference is the cluster name. It affects only the generated kubeconfig contexts.

Some values that k0s sets keep their k0s defaults, because Corium does not change them. These are the API port 6443, the join API port 9443, the konnectivity ports 8132/8133, the cluster domain cluster.local, and the certificate lifetimes. To see the full set for your version, run k0s config create on a node.