A Machine declares one machine: its network interfaces, its disks, and the kernel modules it loads. The machine writes what it observes and what it does into status. Install a cluster writes your first Machine manifests, and the hardware report in that guide proposes one from the hardware it finds. Kernel settings and Resource limits list the values the OS applies before spec.sysctls and spec.rlimits override them.

A Machine is one computer that runs liken. It holds the declared state of the operating system below this cluster, and the observed facts about the hardware that the operating system runs on.

spec

The declared state of this machine. The fields take effect at different times. The liken operator applies sysctls and nodeLabels at boot, and it also reconciles them while the machine runs. The operator stages a change to network, storage, modules, or rlimits, and the change takes effect at the next boot.

Field Type Required Description
network object no The machine’s network configuration. An empty field selects the default: DHCP on the first physical interface. Init applies this configuration at boot. The cluster cannot apply it while the machine runs, because the cluster reaches the machine through the addresses that an edit changes. The operator stages an edit, as it does a storage edit, and the next boot applies it. rebootPolicy sets who starts that boot, and status.boot.network reports the network that the running boot started with.
sysctls map[string]string no Kernel tuning values, from a parameter name to its declared value, for example vm.overcommit_memory: “1”. Init applies these values at boot, and the liken operator applies them again on every pass, so an edit here takes effect without a reboot. liken sets its own values for about twenty parameters before it applies this field, so a name here also overrides liken’s value for that parameter. The manual’s Kernel settings page lists every one of them and why liken sets it. status.sysctls reports both sets together, read back from the kernel.
rlimits map[string]string no Resource limits, from a resource name to its declared limit, for example nofile: “1048576”. These are the per-process ceilings that a systemd distribution sets in each service’s Limit directives. liken has no systemd, so init applies them to itself before it starts k3s, and every process on the machine inherits them: k3s, containerd, and the containers below them. liken sets its own limits before it applies this field, so a name here overrides liken’s limit for that resource. status.rlimits reports what the kernel holds, read back after both passes. Unlike sysctls, an edit here needs a reboot. The kernel fixes a process’s limits when it forks, so nothing can raise the ceiling of a k3s that is already running. rebootPolicy says who starts that reboot.
modules []string no Extra kernel modules that this machine loads at boot, in addition to the fixed list that the operating system needs. These are the drivers for the hardware that this machine’s workloads use. The image carries the kernel build’s whole module tree, so any name that kernel has is loadable here, whatever manifests existed when the image was built. status.modules reports the result for each name, including a name this kernel has no module for. Adding a name takes effect without a reboot, because loading a driver is live-capable. Removing one needs a reboot. Admission checks the shape of the name only, because only the boot, or the load that follows a later edit, can determine whether the name exists.
nodeLabels map[string]string no The labels that this machine’s Node object carries. Workloads select on these labels, for example to find the machine that has the GPU, or the machine on battery-backed power. The system writes these labels into the k3s boot configuration, so the node has them when it registers. The liken operator then reconciles them while the machine runs. This includes the removal of a label that this spec no longer declares, which the kubelet does not do. The system never changes a label applied outside this spec.
nodeTaints []object no The taints that this machine’s Node object carries. A taint repels every pod that does not tolerate it, which is how a machine that is dedicated to one job keeps other work off it. The system writes these taints into the k3s boot configuration, so a node that registers for the first time carries them from its first moment. The kubelet applies those registration taints only when it creates the Node object, on a first boot or after a reinstall. On every later boot the Node object exists already and the boot configuration changes nothing, so the liken operator is the only mechanism from then on: it reconciles this list while the machine runs. This includes the removal of a taint that this spec no longer declares. The system never changes a taint applied outside this spec.
rebootPolicy string no What the operator can do when the spec needs a reboot to take effect. A change to storage, network, or modules is a change of this kind, because the operator measures drift in those three sections and the boot is what applies them. Manual, the default, stages the change to the machineState filesystem and reports RebootPending, and the next boot applies the change. Auto permits the operator to reboot the machine. This field also gates a reboot that a person asked for through the liken.sh/request-reboot annotation, which is the one reboot that applies no change: Manual reports RebootPending until the reboot is approved, and Auto takes the reboot turn on its own. Whichever policy is in force, the machine waits for the cluster to grant the turn, and drains before it goes down. One of: Auto, Manual. Default: Manual.
storage object no Assigns storage roles to disks. Each role is one field, because a machine has one cluster state and one pod-storage pool. Each role names the device it is on and, when it shares a disk, how much of the disk to take. One role per disk can omit its size and take the remainder. Init applies this configuration at boot, before k3s. The system reads the device path only on the boot that claims a blank disk. After that, the system finds the role’s partition by the GPT partition name written on it. The operator stages an edit here, and the edit takes effect at the next boot. If the machine cannot satisfy a staged spec, the system quarantines that spec and the machine boots its last proven spec. Only a machine that has no proven spec stops the boot. The machine’s RAM root backs each role that the spec does not declare.

spec.network

The machine’s network configuration. An empty field selects the default: DHCP on the first physical interface. Init applies this configuration at boot. The cluster cannot apply it while the machine runs, because the cluster reaches the machine through the addresses that an edit changes. The operator stages an edit, as it does a storage edit, and the next boot applies it. rebootPolicy sets who starts that boot, and status.boot.network reports the network that the running boot started with.

Field Type Required Description
interfaces []object no The machine’s interfaces, each named as the kernel names it. A machine in a cluster usually declares two interfaces: a DHCP uplink, and the cluster-facing interface with the static address that its peers use to find it.
hostEntries []object no Static entries for /etc/hosts, each one address and the names that resolve to it. Init writes each entry as a line below the three lines that define localhost and this machine’s own name, so an entry can add a name but never override those two. Init also writes /etc/nsswitch.conf with hosts: files dns on every boot, so every resolver on the machine reads the hosts file before it queries DNS. This gives a program that resolves a name from the host’s own files, such as the NFS mount helper, an answer that does not depend on cluster DNS being up. Init applies these entries at boot, and the liken operator applies them again on every pass, so an edit here takes effect without a reboot. status.hostEntries reports the entries as the hosts file holds them, read back after each pass.

spec.network.interfaces[]

The machine’s interfaces, each named as the kernel names it. A machine in a cluster usually declares two interfaces: a DHCP uplink, and the cluster-facing interface with the static address that its peers use to find it.

Field Type Required Description
name string yes The interface to configure, named as the kernel names it (for example, eth1).
address string no A static address in CIDR form, for example 10.10.0.1/24. The prefix length gives the kernel the subnet. An empty field selects DHCP on this interface. Pattern: ^[0-9a-fA-F:.]+/[0-9]{1,3}$.
gateway string no The gateway address that makes this interface the default route. This field is optional, also for a static address, because a DHCP lease on a different interface can supply the route. Pattern: ^[0-9a-fA-F:.]+$.
nameservers []string no The nameservers for this interface, in preference order. The machine uses them in addition to the nameservers from a DHCP lease. The machine writes at most three nameservers to resolv.conf, in interface order.

spec.network.hostEntries[]

Static entries for /etc/hosts, each one address and the names that resolve to it. Init writes each entry as a line below the three lines that define localhost and this machine’s own name, so an entry can add a name but never override those two. Init also writes /etc/nsswitch.conf with hosts: files dns on every boot, so every resolver on the machine reads the hosts file before it queries DNS. This gives a program that resolves a name from the host’s own files, such as the NFS mount helper, an answer that does not depend on cluster DNS being up. Init applies these entries at boot, and the liken operator applies them again on every pass, so an edit here takes effect without a reboot. status.hostEntries reports the entries as the hosts file holds them, read back after each pass.

Field Type Required Description
address string yes The address this entry resolves to: an IPv4 or IPv6 literal, with no prefix length. This is the exact text that init writes into /etc/hosts. Pattern: ^[0-9a-fA-F:.]+$.
names []string yes The names that resolve to this address, at most twenty, for example [nas, nas.home.arpa]. Each name is lowercase, because DNS compares names without case and one spelling keeps the file readable.

spec.nodeTaints[]

The taints that this machine’s Node object carries. A taint repels every pod that does not tolerate it, which is how a machine that is dedicated to one job keeps other work off it. The system writes these taints into the k3s boot configuration, so a node that registers for the first time carries them from its first moment. The kubelet applies those registration taints only when it creates the Node object, on a first boot or after a reinstall. On every later boot the Node object exists already and the boot configuration changes nothing, so the liken operator is the only mechanism from then on: it reconciles this list while the machine runs. This includes the removal of a taint that this spec no longer declares. The system never changes a taint applied outside this spec.

Field Type Required Description
key string yes The taint’s key: an optional DNS-style prefix, a slash, and a name that contains letters, digits, dashes, underscores, and dots. A pod tolerates this taint by naming the key and the effect. Pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?([.][a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?[A-Za-z0-9]([-A-Za-z0-9_.]*[A-Za-z0-9])?$.
value string no An optional value that goes with the key. A taint often needs none, because the key and the effect alone say to stay off this machine. A toleration that names a value must name the same value. Pattern: ^(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?$.
effect string yes What happens to a pod that does not tolerate this taint. NoSchedule keeps a new pod off the node and leaves the pods already running there alone. PreferNoSchedule asks the scheduler to avoid the node, but the scheduler still places a pod there when no other node fits. NoExecute keeps new pods off and also evicts every running pod without a matching toleration, at the moment the taint lands. That eviction includes DaemonSet pods, because the DaemonSet controller adds tolerations only for the node lifecycle keys. One of: NoSchedule, PreferNoSchedule, NoExecute.

spec.storage

Assigns storage roles to disks. Each role is one field, because a machine has one cluster state and one pod-storage pool. Each role names the device it is on and, when it shares a disk, how much of the disk to take. One role per disk can omit its size and take the remainder. Init applies this configuration at boot, before k3s. The system reads the device path only on the boot that claims a blank disk. After that, the system finds the role’s partition by the GPT partition name written on it. The operator stages an edit here, and the edit takes effect at the next boot. If the machine cannot satisfy a staged spec, the system quarantines that spec and the machine boots its last proven spec. Only a machine that has no proven spec stops the boot. The machine’s RAM root backs each role that the spec does not declare.

Field Type Required Description
biosBoot object no A machine that declares this role, together with bootHome, boots in BIOS mode, through liken’s own GRUB, and not through UEFI firmware. This is a small raw partition, about 1Mi in size, with no filesystem. It holds GRUB’s core image, the code that the 440 boot bytes in the MBR jump into. The size is fixed after the system claims the partition, because the MBR refers to the partition by literal sector numbers.
bootHome object no The second part of the BIOS boot declaration, with biosBoot. This is a small FAT32 partition, about 64Mi in size, that holds GRUB’s configuration and its environment block. The environment block is the file that holds the boot variables that UEFI firmware supplies on a UEFI machine. This partition is on neither system slot, so the system can write to both slots while the boot configuration stays in its own space.
systemA object no The first of the operating system’s two boot slots. Each slot holds one complete liken version. The machine runs from one slot while the system writes an upgrade to the other. The slots are EFI system partitions that carry FAT32, because the firmware reads each slot first. Their size is fixed after the system claims them, because FAT32 cannot grow in place.
systemB object no The second boot slot. The systemA description gives the operation of the two slots.
machineState object no The machine’s own durable data, mainly the staged and proven manifests. These manifests keep a spec edit through a reboot, and the next boot applies the edit. This role is the first of the data roles in the standard partition order, so a later boot can find it before it reads any spec.
machineEphemeral object no The operating system’s own scratch space (/tmp).
clusterState object no k3s’s state: its database, its TLS material, and containerd’s images. The system keeps this data, so a reboot can continue the same cluster and does not start a new one.
podStorage object no Durable storage that pods claim by name: the PersistentVolumeClaim pool. The local-path provisioner supplies volumes from this pool.
podEphemeral object no The kubelet’s working space: emptyDir volumes and per-pod scratch space. Pods meter this pool with ephemeral-storage requests and limits. The system also writes the pod logs here, and they stay visible at /var/log/pods. Make this role large enough for the logs and the volumes. A machine that does not declare this role keeps all of this data in memory.

spec.storage.biosBoot

A machine that declares this role, together with bootHome, boots in BIOS mode, through liken’s own GRUB, and not through UEFI firmware. This is a small raw partition, about 1Mi in size, with no filesystem. It holds GRUB’s core image, the code that the 440 boot bytes in the MBR jump into. The size is fixed after the system claims the partition, because the MBR refers to the partition by literal sector numbers.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.bootHome

The second part of the BIOS boot declaration, with biosBoot. This is a small FAT32 partition, about 64Mi in size, that holds GRUB’s configuration and its environment block. The environment block is the file that holds the boot variables that UEFI firmware supplies on a UEFI machine. This partition is on neither system slot, so the system can write to both slots while the boot configuration stays in its own space.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.systemA

The first of the operating system’s two boot slots. Each slot holds one complete liken version. The machine runs from one slot while the system writes an upgrade to the other. The slots are EFI system partitions that carry FAT32, because the firmware reads each slot first. Their size is fixed after the system claims them, because FAT32 cannot grow in place.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.systemB

The second boot slot. The systemA description gives the operation of the two slots.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.machineState

The machine’s own durable data, mainly the staged and proven manifests. These manifests keep a spec edit through a reboot, and the next boot applies the edit. This role is the first of the data roles in the standard partition order, so a later boot can find it before it reads any spec.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.machineEphemeral

The operating system’s own scratch space (/tmp).

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.clusterState

k3s’s state: its database, its TLS material, and containerd’s images. The system keeps this data, so a reboot can continue the same cluster and does not start a new one.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.podStorage

Durable storage that pods claim by name: the PersistentVolumeClaim pool. The local-path provisioner supplies volumes from this pool.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

spec.storage.podEphemeral

The kubelet’s working space: emptyDir volumes and per-pod scratch space. Pods meter this pool with ephemeral-storage requests and limits. The system also writes the pod logs here, and they stay visible at /var/log/pods. Make this role large enough for the logs and the volumes. A machine that does not declare this role keeps all of this data in memory.

Field Type Required Description
device string yes The disk that this role is on: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/. The system reads this field only on the boot that claims a blank disk. The by-id name belongs to the disk and survives a port move; the by-path name belongs to the port. After the claim, the system finds the role’s partition by the GPT partition name written on it. Pattern: ^/dev/[a-zA-Z0-9/_.:=+#@-]+$.
size string no How much of the disk this role takes, as a binary quantity (2Gi). This is an exact allocation, not a request. An empty value means that the role takes the rest of its disk, and only one role per disk can omit it. Pattern: ^[0-9]+(Ki|Mi|Gi|Ti)?$.

status

What the machine observed about itself. Init writes these facts through the facts tree, and the liken operator publishes them. The system derives every field here again on each reconcile pass and keeps no earlier value. Status reports the current state only.

Field Type Required Description
phase string no The machine’s state in one word. The system derives this value from the conditions on each reconcile pass, so the phase always agrees with them. Ready means that every condition holds. UpdatePending and Updating mean that a staged change waits for a reboot (Manual), waits for this machine’s next boot, or is in progress (Auto). Blocked means that drift exists which liken refuses to stage or cannot stage. This state needs a different edit, and time does not clear it. Degraded covers all other faults. Booting means that init has not yet published this boot. Unknown means that the operator cannot read the machine’s facts at all. Lost is the one value that the machine does not report about itself: a leader writes it when this machine’s heartbeat lease (in liken-system) stops, because a machine that is down cannot report its own failure. One of: Unknown, Booting, Lost, Blocked, Updating, UpdatePending, Degraded, Ready.
observedGeneration integer no The metadata.generation of the spec that this status judged. The operator writes this value on each pass. Each condition carries the same value, but a client that only needs to know whether the operator has seen its edit reads the value here, at the top of status, where Kubernetes controllers usually publish it.
role string no This machine’s part in its cluster: a leader, which runs a control plane, or a follower, which runs workloads. The system derives this value at boot from the leaders list in the Cluster manifest. No one declares this field directly.
version object no The full inventory of what this machine runs: liken’s own version and every third-party component that the operating system carries. The system reads the kernel and xtables versions from the running machine. The other values come from the components record that the image build wrote beside the image, the same pins that the release document publishes. k3s appears here and also on the Node object, because the two values are different: the Node reports the running kubelet, and this field reports what the operating system image carried.
network object no The network result of this boot, for DHCP leases and for static addresses. The top-level fields give the values of the primary interface, which is the cluster-facing interface when the Cluster’s nodeCIDR identifies it. The interfaces field gives the full detail for each interface.
time object no The state of this machine’s clock. This field changes through the machine’s whole life, unlike most of status, because the system corrects the clock continuously and not only at boot.
hardware object no What this machine is made of, as the machine observed itself. The processor count and the memory come from the boot. The disks and the unclaimed devices stay current while the machine runs, because init watches the kernel’s uevents and writes both lists again on every change.
firmware object no The firmware state that the machine keeps: its boot mode and the boot menu from its non-volatile store. In UEFI mode, this field reports the firmware’s variables as text. BIOS covers every environment that has no firmware variables to read, for example a legacy server or a direct-kernel boot under a hypervisor. This field describes the machine, not the boot: every value here stays through a power cycle, and the system writes status.boot again on every boot. Each entry shows the firmware’s variable name and the entry’s own description, for example “Boot0001 (liken slot A)”.
storage object no What backs every storage role on this boot, whether the spec declares the role or not. The spec gives what the machine asked for, and hardware.blockDevices gives what is attached. This field connects the two. A memory-backed role reports no capacity on purpose, because all of these roles share the one RAM root, and a value for each role would count the same capacity more than once.
boot object no The record of this boot. The system writes this record again on every boot, and the operator compares the spec against it. Compare this field with firmware, the state that stays through reboots. The manifest sources give the documents that the boot used: the staged copy that waits for its proving boot, the proven last-known-good copy, or, on the first boot only, the seed in the image. The system records these sources separately for the Machine manifest and the Cluster document, because the two stage and prove independently. The hashes identify the exact bytes, and the storage, network, and modules blocks show the spec as actuated. Together they are the reference for drift between what the cluster asks for and what the machine did. A rejection reports a staged document that failed and that the system quarantined. The rejection stands until a different edit proves out.
sysctls map[string]string no The observed value of every parameter liken sets, read back from the kernel: the values liken sets on every machine, and the values spec.sysctls declares. This puts what was asked for and what the kernel holds side by side in one place. A parameter liken could not write is absent, because a failed write is never read back, so this field lists the parameters that currently hold rather than the parameters somebody wanted.
hostEntries []object no The entries /etc/hosts actually holds, observed on the pass that published them: the live view of spec.network.hostEntries, the same way sysctls above is the live view of spec.sysctls. Init writes the file at boot, and the liken operator reconciles it live afterward, so this field changes within one reconcile pass of an edit, with no reboot.
rlimits map[string]string no The resource limits init holds, read back from the kernel: the limits liken sets on every machine, and the limits spec.rlimits declares. Init is the first process, so these are the limits that every process on the machine inherits, including every container. Reading /proc/1/limits on the machine gives the same answer in the kernel’s own layout. Each value is in the same form spec.rlimits uses, so the two can be compared without translating either. A limit liken could not set is absent, because a failed write is never read back.
modules []object no The result for every module named in spec.modules, as the machine resolved it: at boot, or at the load that followed a later edit. Loaded and Builtin are good states. Missing means that this kernel has no module by that name, which is usually a misspelling, because the image carries the kernel’s whole module tree. Rebuilding the image changes nothing; correct the name, or take a release whose kernel has the module. Failed means that the kernel refused a module it does have. The message field gives the detail and names the correction.
features []object no The state on this machine of every feature that the Cluster’s spec.features enables. The Cluster declares features for the whole fleet, but the state is per machine, because a feature needs support in the booted image, and machines run different releases during a rollout. Active means that this boot applied everything that the feature asks of this machine. Missing means that the booted image does not carry the feature, and the correction is a release whose image carries it. Failed means that the image carries the feature, but that the machine could not apply it. The message field gives the detail.
registries object no What this machine wrote into k3s’s registries.yaml: the registries that it mirrors, the registries that have credentials, and whether the embedded registry is on. This field carries host names and flags only. The credential material never appears in status.
runtime object no The runtime discipline that init imposed on this boot: the Go environment and log level it gave the k3s process, the configuration it wrote for the kubelet inside it, and the level it gave containerd beside it. These are the resolved values, not the strings from the Cluster’s spec.runtime. An operator who changes a setting reads back here what each machine actually runs.
lastCrash object no The most recent kernel crash that this machine still holds records for. When the kernel panics, it writes the end of its log to the firmware’s storage, and the next boot moves that record onto the machine’s own disk. Each boot derives this summary from the records again. The crash is not always the previous boot’s crash. The summary stays until the records leave the machine’s retention window, and the time field gives the age of the crash. An empty field means that the machine holds no crash records.
lastFailStop object no The last boot that this machine refused to run. Init stops a boot for two failures: it cannot tell which configuration is its own, or it cannot satisfy a declared storage role. A machine that runs with the wrong configuration can do damage that a reboot does not undo, so init powers the machine off instead. The refusal writes its reason to the machine’s own disk, and the next boot reports it here. The refusal is not always the previous boot, and the time field gives the age of the news. Nothing clears this field. The next refusal replaces it. An empty field means that this machine has never refused a boot, or that the role it could not satisfy was the one that holds the record.
conditions []object no The typed observations that the operators keep on this machine, in the standard Kubernetes form. Each pass writes every condition again. Ready is the roll-up, and it is True only when every other condition is True. The other conditions each report one check: FactsPublished for the facts that init writes, SysctlsApplied, StorageReady, ModulesLoaded, FeaturesReady, and NodeLabelsApplied for the parts of the spec that the operator applies, NodeHealthy for the Node’s own Ready condition, NodeCurrent for the cleanup after a demotion, and SpecConverged, ClusterConverged, VersionConverged, CredentialsConverged, and ImportsConverged for the documents and the release that this boot ran under. RebootApproved is the one condition that another program writes: the cluster operator adds it to grant this machine a reboot turn, and removes it to take the grant back. Its absence carries the meaning, so it has no False state, and Ready does not count it.
pending []object no What this machine waits to apply: one entry for each staged document that needs a disruption. Each entry names the convergence condition that reported it, the kind of disruption that applies it, the staged document’s hash, and a one-line summary. To grant one change its disruption on a machine whose rebootPolicy is Manual, annotate the machine with liken.sh/approve-disruption set to the entry’s hash (the liken CLI’s approve-reboot command does this). The grant is one-shot: once the change applies, its hash is no longer pending, and the next change hashes differently, so a stale annotation approves nothing. A reboot that a person requested through the liken.sh/request-reboot annotation is an entry here too. It waits on the same policy, the same turn, and the same drain, and the one thing it lacks is a document, so its hash is the running boot’s identity instead.

status.version

The full inventory of what this machine runs: liken’s own version and every third-party component that the operating system carries. The system reads the kernel and xtables versions from the running machine. The other values come from the components record that the image build wrote beside the image, the same pins that the release document publishes. k3s appears here and also on the Node object, because the two values are different: the Node reports the running kubelet, and this field reports what the operating system image carried.

Field Type Required Description
liken string no The liken version that this machine runs. The build stamps this value into the binary: a release build stamps the release name, and a development build stamps the git-described commit. The operator compares this value with the Cluster’s spec.version to decide whether this machine needs an upgrade.
kernel string no The kernel release, as uname reports it on the running machine.
xtables string no The netfilter userspace, as iptables -V reports it: the version and the variant (legacy or nft).
k3s string no The k3s release that this operating system image carries. liken vendors one pinned k3s binary for each release.
trust string no The date of the CA bundle: the day of the Mozilla root certificates that this machine trusts.
e2fsprogs string no The e2fsprogs release that supplied mke2fs, the program that makes the ext4 filesystem on each storage role’s partition.
openIscsi string no The open-iscsi release that supplied iscsiadm and iscsid, the iSCSI initiator that the iscsi feature uses.
nfsUtils string no The nfs-utils release that supplied mount.nfs, the mount helper that the nfs feature uses.
systemdBoot string no The systemd-boot release that supplied the boot menu on liken’s install media.
grub string no The GRUB release that supplied the boot program that liken writes into a BIOS machine’s biosBoot partition.
hwdata string no The PCI database that gives names to vendor and device IDs.
tzdata string no The IANA timezone database release, for example 2026c. This is the database that resolves a CronJob’s spec.timeZone on this machine. Read it when a job fires at an unexpected hour. A machine keeps the release its image carried until it upgrades.
linuxFirmware string no The linux-firmware release that supplied the driver blobs under /lib/firmware.
microcode string no The CPU microcode release that supplied the early cpio on this machine’s boot slot.
microcodeRevision string no The microcode revision that the CPUs report. On physical hardware, this value shows whether the early cpio applied. On a virtual machine, this value comes from the hypervisor.

status.network

The network result of this boot, for DHCP leases and for static addresses. The top-level fields give the values of the primary interface, which is the cluster-facing interface when the Cluster’s nodeCIDR identifies it. The interfaces field gives the full detail for each interface.

Field Type Required Description
interface string no The primary interface, as the kernel names it (for example, eth0).
mac string no The hardware address of the primary interface.
addresses []string no The addresses of the primary interface, each in CIDR form (10.10.0.5/24).
gateway string no The default gateway of the primary interface. This field is empty when the interface has no default route.
nameservers []string no The nameservers of the primary interface, in preference order: the nameservers from its DHCP lease, and the nameservers that the manifest declares for it.
leaseExpires string no The time when the DHCP lease of the primary interface expires. This field is empty when the interface has a static address.
interfaces []object no Every interface that this boot configured, with the detail for each one. The fields above repeat the values of the primary interface, which is the one that the Cluster’s nodeCIDR identifies, or the first interface that came up.

status.network.interfaces[]

Every interface that this boot configured, with the detail for each one. The fields above repeat the values of the primary interface, which is the one that the Cluster’s nodeCIDR identifies, or the first interface that came up.

Field Type Required Description
name string yes This interface, as the kernel names it (for example, eth0). It is the key of this list.
mac string no The hardware address of this interface.
address string no The address of this interface, in CIDR form (10.10.0.5/24).
method string no How the interface got its address: DHCP or Static.
gateway string no The default gateway of this interface. This field is empty when the interface has no default route.
nameservers []string no The nameservers of this interface, in preference order: the nameservers from its DHCP lease, and the nameservers that the manifest declares for it.
leaseExpires string no The time when the DHCP lease of this interface expires. This field is empty when the interface has a static address.

status.time

The state of this machine’s clock. This field changes through the machine’s whole life, unlike most of status, because the system corrects the clock continuously and not only at boot.

Field Type Required Description
state string no Whether the system corrects the clock against a source that is itself synchronized. If it does not, this field shows whether the cause is the configuration or an outage. FreeRunning means that the spec declares no sources, and the machine runs on its hardware clock on purpose. Unsynchronized means that the spec declares sources but that none of them answers. A free-running fleet can agree with itself, but the state stays FreeRunning. Agreement in the fleet is not the same as agreement with real-world time, and certificate validation depends on that difference. One of: Synchronized, FreeRunning, Unsynchronized.
source string no The source that this machine synchronizes with. On a leader, this is the name of an upstream server. On a follower, this is one of the cluster’s leaders.
stratum integer no The distance from a reference clock, in NTP’s vocabulary: a source at stratum n makes this machine n+1. A server that free-runs on purpose reports 10, the local-clock value. A value of 16 means unsynchronized.
offset string no The clock error measured at the last exchange, as a duration (“1.28ms”). The value is positive when this machine is behind its source.
lastSync string no The last time that the clock agreed with its source.

status.hardware

What this machine is made of, as the machine observed itself. The processor count and the memory come from the boot. The disks and the unclaimed devices stay current while the machine runs, because init watches the kernel’s uevents and writes both lists again on every change.

Field Type Required Description
cpus integer no The number of logical processors that the kernel makes available. Hardware that has threads counts each thread as one processor.
memoryBytes integer no The machine’s total usable memory, in bytes, as the kernel reports it. This value is less than the memory that the machine holds, because the firmware and the kernel reserve some of it.
blockDevices []object no The machine’s storage inventory: every physical disk that the kernel found, whether the spec declares it or not. The name is the kernel’s name for this boot. The kernel assigns the name in probe order, so the name identifies the device for this boot only and not permanently. The stable names identify the device across boots. The model and the serial come from the device itself.
unclaimed []object no Devices that the kernel found but that no driver controls, because spec.modules does not declare the module that the device needs. This list shows only those devices. It is not a full inventory, and a machine that has a driver for all of its hardware reports nothing here. Each entry gives the name of the device, the candidate modules whose alias patterns match the device’s identifier, and the correction: declare a candidate module that the image carries, or upgrade to a release that carries one.

status.hardware.blockDevices[]

The machine’s storage inventory: every physical disk that the kernel found, whether the spec declares it or not. The name is the kernel’s name for this boot. The kernel assigns the name in probe order, so the name identifies the device for this boot only and not permanently. The stable names identify the device across boots. The model and the serial come from the device itself.

Field Type Required Description
name string yes This disk, as the kernel names it this boot (vda, nvme0n1). It is the key of this list.
sizeBytes integer no The capacity of this disk, in bytes.
model string no The model name that the device reports. This field is empty when the device reports none.
serial string no The serial number that the device reports. This field is empty when the device reports none.
stableNames []string no Every name that identifies this disk across boots. spec.storage..device accepts any name in this list. The first by-id entry is the one to prefer. A by-id name follows the disk itself, so it survives a swap into a different bay. A by-path name follows the port instead, and stops naming the disk after that swap.

status.hardware.unclaimed[]

Devices that the kernel found but that no driver controls, because spec.modules does not declare the module that the device needs. This list shows only those devices. It is not a full inventory, and a machine that has a driver for all of its hardware reports nothing here. Each entry gives the name of the device, the candidate modules whose alias patterns match the device’s identifier, and the correction: declare a candidate module that the image carries, or upgrade to a release that carries one.

Field Type Required Description
modalias string yes The kernel’s identifier for this device: the string that it announces in a uevent and matches driver alias patterns against. It is the key of this list, and it names the device exactly when the words below do not.
bus string yes The bus that the device is on: pci or usb.
name string no The device in words: the manufacturer and product strings of a USB device, or the names from the pci.ids database for a PCI device. When no better name exists, this field gives the numeric vendor and device IDs.
class string no The coarse kind of the device, decoded from the bus’s class code: for example, mass-storage, display, or network.
candidates []string no The loadable modules whose alias patterns match this device, in the kernel build’s order of preference. More than one candidate is usual: USB storage matches both uas and usb_storage. The choice belongs to the person who edits spec.modules.
message string no The correction, in words: declare one of the candidate modules in spec.modules when the image carries it, or upgrade to a release whose image carries one.

status.firmware

The firmware state that the machine keeps: its boot mode and the boot menu from its non-volatile store. In UEFI mode, this field reports the firmware’s variables as text. BIOS covers every environment that has no firmware variables to read, for example a legacy server or a direct-kernel boot under a hypervisor. This field describes the machine, not the boot: every value here stays through a power cycle, and the system writes status.boot again on every boot. Each entry shows the firmware’s variable name and the entry’s own description, for example “Boot0001 (liken slot A)”.

Field Type Required Description
mode string no The kind of firmware that started this machine. UEFI means that the machine keeps boot variables that liken reads and writes. BIOS covers every environment that keeps no such variables, for example a legacy server or a direct-kernel boot under a hypervisor. One of: UEFI, BIOS.
bootCurrent string no The entry that this boot came from. In UEFI mode, the value is the firmware’s BootCurrent variable. In BIOS mode, it is the liken.slot= parameter on the kernel command line. This field is empty when neither source names an entry, as in a direct-kernel boot.
bootNext string no The one-shot entry that is armed for the next boot: the firmware’s BootNext variable in UEFI mode, or try_slot in GRUB’s environment block in BIOS mode. The boot uses this entry one time and then clears it. A value here means that a proving boot waits and has not yet happened. This field is empty at every other time.
bootOrder []string no The standing list of preferences, with the first choice first: the firmware’s BootOrder variable in UEFI mode, where each entry is a menu entry, or default_slot in GRUB’s environment block in BIOS mode, which gives one entry.

status.storage

What backs every storage role on this boot, whether the spec declares the role or not. The spec gives what the machine asked for, and hardware.blockDevices gives what is attached. This field connects the two. A memory-backed role reports no capacity on purpose, because all of these roles share the one RAM root, and a value for each role would count the same capacity more than once.

Field Type Required Description
biosBoot object no What backs the biosBoot role now. spec.storage.biosBoot describes what the role holds.
bootHome object no What backs the bootHome role now. spec.storage.bootHome describes what the role holds.
systemA object no What backs the systemA role now. spec.storage.systemA describes what the role holds.
systemB object no What backs the systemB role now. spec.storage.systemB describes what the role holds.
machineState object no What backs the machineState role now. spec.storage.machineState describes what the role holds.
machineEphemeral object no What backs the machineEphemeral role now. spec.storage.machineEphemeral describes what the role holds.
clusterState object no What backs the clusterState role now. spec.storage.clusterState describes what the role holds.
podStorage object no What backs the podStorage role now. spec.storage.podStorage describes what the role holds.
podEphemeral object no What backs the podEphemeral role now. spec.storage.podEphemeral describes what the role holds.

status.storage.biosBoot

What backs the biosBoot role now. spec.storage.biosBoot describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.bootHome

What backs the bootHome role now. spec.storage.bootHome describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.systemA

What backs the systemA role now. spec.storage.systemA describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.systemB

What backs the systemB role now. spec.storage.systemB describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.machineState

What backs the machineState role now. spec.storage.machineState describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.machineEphemeral

What backs the machineEphemeral role now. spec.storage.machineEphemeral describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.clusterState

What backs the clusterState role now. spec.storage.clusterState describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.podStorage

What backs the podStorage role now. spec.storage.podStorage describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.storage.podEphemeral

What backs the podEphemeral role now. spec.storage.podEphemeral describes what the role holds.

Field Type Required Description
backing string no What holds this role’s data. Partition means that the machine found the role’s partition. Memory means that the role’s directory stays on the machine’s RAM root. A role that the spec does not declare has this backing.
device string no The device node of this role’s partition, as the machine found it this boot (vda1). The kernel assigns this name in probe order, so the name identifies the partition for this boot only. This field is empty for a memory-backed role.
partition string no The on-disk name of this role’s partition. The name is the liken: prefix and the role’s name. The claim writes this name, and every boot after that finds the partition by it, wherever the kernel enumerates the disk. This field is empty for a memory-backed role.
capacityBytes integer no The size of this role’s partition, in bytes. A memory-backed role reports no capacity, because all memory-backed roles share the one RAM root.
lastStopUnclean boolean no Whether this boot found the role’s filesystem still marked as mounted, which means the machine’s previous stop did not release it. Only the FAT32 roles report this: the system slots and the boot home carry a mark for exactly this purpose, and the ext4 roles replay a journal instead. The field describes the stop before this boot, so it keeps its value until the machine boots again.

status.boot

The record of this boot. The system writes this record again on every boot, and the operator compares the spec against it. Compare this field with firmware, the state that stays through reboots. The manifest sources give the documents that the boot used: the staged copy that waits for its proving boot, the proven last-known-good copy, or, on the first boot only, the seed in the image. The system records these sources separately for the Machine manifest and the Cluster document, because the two stage and prove independently. The hashes identify the exact bytes, and the storage, network, and modules blocks show the spec as actuated. Together they are the reference for drift between what the cluster asks for and what the machine did. A rejection reports a staged document that failed and that the system quarantined. The rejection stands until a different edit proves out.

Field Type Required Description
time string no The time when this machine booted. Init calculates it from the kernel’s uptime counter. It belongs to the boot record because it shares the record’s lifetime: a reboot changes it, and an in-place k3s restart does not. The Uptime printer column shows this timestamp as an elapsed time.
manifestSource string no The copy of the Machine manifest that this boot used. Staged is a copy that waits for its proving boot. Proven is the last-known-good copy. Seed is the manifest in the image, and only a first boot uses it. One of: Staged, Proven, Seed.
manifestHash string no The sha256 hash of the exact bytes of the Machine manifest that this boot used. The operator compares this hash with the hash of the manifest in the cluster to find drift.
clusterManifestSource string no The copy of the Cluster document that this boot used, with the same values as manifestSource. The system records the two documents separately, because each one stages and proves on its own. A machine can be current on one document and drifted on the other. One of: Staged, Proven, Seed.
clusterManifestHash string no The sha256 hash of the exact bytes of the Cluster document that this boot used.
credentialsSource string no The copy of the registry-credentials document that this boot, or the most recent k3s restart, wrote into registries.yaml. This field is absent on a machine that never had credentials. That is a usual state, and the machine pulls images anonymously. One of: Staged, Proven.
credentialsHash string no The sha256 hash of the exact bytes of the registry-credentials document that this boot, or the most recent k3s restart, wrote into registries.yaml. This field is absent on a machine that never had credentials.
importsSource string no The imported-images record that this boot used. Staged means that the tarballs are on trial, and the operator has not yet proven that the container store serves them. Proven is the usual boot, where all of the tarballs match the record. This field is absent when the import lifecycle does not run (an ephemeral machineState or an ephemeral container store). One of: Staged, Proven.
importsHash string no The sha256 hash of the exact bytes of the imported-images record that this boot used. This field is absent when the import lifecycle does not run.
importsDiscarded boolean no True when this boot found an imports trial from an earlier boot that stopped before it proved the trial. This boot then discarded the container store instead of trusting it. The operating system images unpack again from this boot’s tarballs, and workload images pull again.
restarts integer no The number of in-place k3s restarts in this boot. A restart applies a restart-class change, for example a feature toggle or the registry configuration. This field shares the boot record’s lifetime on purpose. A change that a restart applied increases this field and does not change the boot record’s time. A change that a reboot applied changes the time and sets this field to zero.
slot string no The system slot that this boot came from, read from the liken.slot= parameter in the boot entry that started it. This field is absent when the boot did not come from a slot (a direct-kernel boot or install media). A release downloads to the slot that the machine does not run from, which is the purpose of the two slots. One of: A, B.
commandLine string no The kernel command line that this boot ran with, whole and unparsed. The slot above is one parameter out of it. No field sets this line: liken writes each machine’s boot entries itself, naming the console, the machine, and the slot. The line is reported because it is the only input a machine reads before it reads a file, so it is the first thing to check when one machine behaves unlike the others that share its release.
storage object no The storage that the manifest of this boot declared. The system records it as actuated, whatever the result for each role was. A boot with the same manifest claims the same disks, so this field is the drift reference, and status.storage reports what backs each role now. An edit to spec.storage is converged when the two agree.
network object no The network that the manifest of this boot declared. The system records it as actuated, whatever the result for each interface was. A boot with the same manifest asks for the same network, so this field is the drift reference, and status.network reports what each interface received. An edit to spec.network is converged when the two agree. This field is absent, and not empty, on a boot that reported no network at all. An empty field means that the machine declared no interface and used the zero-configuration default.
modules []string no The module list that the manifest of this boot declared. The system records it as actuated, whatever the result of each load was. A boot with the same image asks for the same modules, so this field is the drift reference, and status.modules gives the state of each module.
rlimits map[string]string no The resource limits that the manifest of this boot declared. The system records them as actuated, whatever the result of each one was. A boot under the same manifest asks for the same limits, so this field is the drift reference, and status.rlimits gives what the kernel actually holds. The limits liken sets on every machine are not part of this record, because they ship with the release rather than with the spec.
rejection object no The standing quarantine record for the Machine manifest: the staged manifest that the machine refused, and the reason. Every boot writes this record again until a promotion clears it, so the record stays through a power cycle.
clusterRejection object no The standing quarantine record for the Cluster document. It is the same record as rejection, for the other document.
systemRejection object no The verdict on a system release whose proving boot did not complete: the machine booted the staged slot, did not prove it, and the firmware returned the machine to the proven slot. This verdict stands until the catalog names a different release.
credentialsRejection object no The verdict on a staged registry-credentials document that the machine could not parse. This verdict stands until a different rendering, which an edit to the Secret makes, replaces it.

status.boot.storage

The storage that the manifest of this boot declared. The system records it as actuated, whatever the result for each role was. A boot with the same manifest claims the same disks, so this field is the drift reference, and status.storage reports what backs each role now. An edit to spec.storage is converged when the two agree.

Field Type Required Description
biosBoot object no The biosBoot role, as this boot actuated it. spec.storage.biosBoot describes what the role holds.
bootHome object no The bootHome role, as this boot actuated it. spec.storage.bootHome describes what the role holds.
systemA object no The systemA role, as this boot actuated it. spec.storage.systemA describes what the role holds.
systemB object no The systemB role, as this boot actuated it. spec.storage.systemB describes what the role holds.
machineState object no The machineState role, as this boot actuated it. spec.storage.machineState describes what the role holds.
machineEphemeral object no The machineEphemeral role, as this boot actuated it. spec.storage.machineEphemeral describes what the role holds.
clusterState object no The clusterState role, as this boot actuated it. spec.storage.clusterState describes what the role holds.
podStorage object no The podStorage role, as this boot actuated it. spec.storage.podStorage describes what the role holds.
podEphemeral object no The podEphemeral role, as this boot actuated it. spec.storage.podEphemeral describes what the role holds.

status.boot.storage.biosBoot

The biosBoot role, as this boot actuated it. spec.storage.biosBoot describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.bootHome

The bootHome role, as this boot actuated it. spec.storage.bootHome describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.systemA

The systemA role, as this boot actuated it. spec.storage.systemA describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.systemB

The systemB role, as this boot actuated it. spec.storage.systemB describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.machineState

The machineState role, as this boot actuated it. spec.storage.machineState describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.machineEphemeral

The machineEphemeral role, as this boot actuated it. spec.storage.machineEphemeral describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.clusterState

The clusterState role, as this boot actuated it. spec.storage.clusterState describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.podStorage

The podStorage role, as this boot actuated it. spec.storage.podStorage describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.storage.podEphemeral

The podEphemeral role, as this boot actuated it. spec.storage.podEphemeral describes what the role holds.

Field Type Required Description
device string no The disk that this role is on, exactly as the manifest of this boot declared it: a device path (/dev/vda), or a stable name under /dev/disk/by-id/ or /dev/disk/by-path/.
size string no How much of the disk this role takes, as a binary quantity (2Gi). An empty value means that the role takes the rest of its disk.

status.boot.network

The network that the manifest of this boot declared. The system records it as actuated, whatever the result for each interface was. A boot with the same manifest asks for the same network, so this field is the drift reference, and status.network reports what each interface received. An edit to spec.network is converged when the two agree. This field is absent, and not empty, on a boot that reported no network at all. An empty field means that the machine declared no interface and used the zero-configuration default.

Field Type Required Description
interfaces []object no The interfaces that the manifest of this boot declared. The system records them as actuated, whatever the result for each interface was. status.network.interfaces reports what each interface received.

status.boot.network.interfaces[]

The interfaces that the manifest of this boot declared. The system records them as actuated, whatever the result for each interface was. status.network.interfaces reports what each interface received.

Field Type Required Description
name string no The interface that the manifest named, as the kernel names it (for example, eth1).
address string no The static address in CIDR form that the manifest declared, for example 10.10.0.1/24. An empty field means DHCP on this interface.
gateway string no The gateway address that the manifest declared. An empty field means that the manifest gave this interface no default route.
nameservers []string no The nameservers that the manifest declared for this interface, in preference order. The machine uses them in addition to the nameservers from a DHCP lease.

status.boot.rejection

The standing quarantine record for the Machine manifest: the staged manifest that the machine refused, and the reason. Every boot writes this record again until a promotion clears it, so the record stays through a power cycle.

Field Type Required Description
hash string no The sha256 hash of the exact bytes that the machine refused. The operator refuses to stage the same bytes again, so only a different edit clears the rejection.
reason string yes Why the machine refused the document, in the same words that the boot prints on the console.
rejectedAt string yes The time when the machine refused the document.

status.boot.clusterRejection

The standing quarantine record for the Cluster document. It is the same record as rejection, for the other document.

Field Type Required Description
hash string no The sha256 hash of the exact bytes that the machine refused. The operator refuses to stage the same bytes again, so only a different edit clears the rejection.
reason string yes Why the machine refused the document, in the same words that the boot prints on the console.
rejectedAt string yes The time when the machine refused the document.

status.boot.systemRejection

The verdict on a system release whose proving boot did not complete: the machine booted the staged slot, did not prove it, and the firmware returned the machine to the proven slot. This verdict stands until the catalog names a different release.

Field Type Required Description
hash string no The sha256 hash of the exact bytes of the staged release record that the machine refused. No later boot arms the same trial again.
reason string yes Why the machine refused the release, in the same words that the boot prints on the console.
rejectedAt string yes The time when the machine refused the release.

status.boot.credentialsRejection

The verdict on a staged registry-credentials document that the machine could not parse. This verdict stands until a different rendering, which an edit to the Secret makes, replaces it.

Field Type Required Description
hash string no The sha256 hash of the exact bytes of the credentials document that the machine refused. Only a different rendering, which an edit to the Secret makes, clears the rejection.
reason string yes Why the machine refused the document, in the same words that the boot prints on the console.
rejectedAt string yes The time when the machine refused the document.

status.hostEntries[]

The entries /etc/hosts actually holds, observed on the pass that published them: the live view of spec.network.hostEntries, the same way sysctls above is the live view of spec.sysctls. Init writes the file at boot, and the liken operator reconciles it live afterward, so this field changes within one reconcile pass of an edit, with no reboot.

Field Type Required Description
address string yes The address, as the hosts file holds it.
names []string yes The names that resolve to this address, as the hosts file holds them.

status.modules[]

The result for every module named in spec.modules, as the machine resolved it: at boot, or at the load that followed a later edit. Loaded and Builtin are good states. Missing means that this kernel has no module by that name, which is usually a misspelling, because the image carries the kernel’s whole module tree. Rebuilding the image changes nothing; correct the name, or take a release whose kernel has the module. Failed means that the kernel refused a module it does have. The message field gives the detail and names the correction.

Field Type Required Description
name string yes The module, by the name that spec.modules declares (for example, e1000e). It is the key of this list.
state string yes The result for this module on this boot. Loaded means that the kernel took the module, or already held it. Builtin means that the kernel has the module compiled in, so there was nothing to load. Missing means that the booted image does not carry the module, and a new image corrects it, not a retry. Failed means that the image carries the module and the kernel refused it, which usually points to a fault in the hardware. One of: Loaded, Builtin, Missing, Failed.
message string no The detail for a Missing or a Failed module, in the same words that the boot prints on the console, and named as a correction. This field is empty when the state is Loaded or Builtin.

status.features[]

The state on this machine of every feature that the Cluster’s spec.features enables. The Cluster declares features for the whole fleet, but the state is per machine, because a feature needs support in the booted image, and machines run different releases during a rollout. Active means that this boot applied everything that the feature asks of this machine. Missing means that the booted image does not carry the feature, and the correction is a release whose image carries it. Failed means that the image carries the feature, but that the machine could not apply it. The message field gives the detail.

Field Type Required Description
name string yes The feature, by the name that the Cluster’s spec.features enables (for example, iscsi). It is the key of this list.
state string yes The state of this feature on this machine, on this boot. Active means that the boot applied everything that the feature asks of this machine. Missing means that the booted image carries no payload for the feature, and the correction is a release whose image carries one. Failed means that the image carries the payload and the machine could not apply it, for example a module that the kernel refused, or a boot hook that returned an error. One of: Active, Missing, Failed.
message string no The detail for a Missing or a Failed feature, in the same words that the boot prints on the console, and named as a correction. This field is empty when the state is Active.

status.registries

What this machine wrote into k3s’s registries.yaml: the registries that it mirrors, the registries that have credentials, and whether the embedded registry is on. This field carries host names and flags only. The credential material never appears in status.

Field Type Required Description
mirrors []string no The registry hosts that registries.yaml carries a mirror entry for, sorted by name. The list holds “*” as well when the embedded registry is on, because the wildcard entry is how it shares the images of every registry. This field is empty when the machine mirrors nothing.
credentialedHosts []string no The registry hosts that registries.yaml carries a credential for, sorted by name. This field names the hosts only. The usernames and the passwords stay in the registry-credentials Secret and never reach status. This field is empty when the machine pulls every image anonymously.
embedded boolean no True when this boot turned k3s’s embedded registry mirror (Spegel) on, which the Cluster’s spec.registries.embedded asks for.

status.runtime

The runtime discipline that init imposed on this boot: the Go environment and log level it gave the k3s process, the configuration it wrote for the kubelet inside it, and the level it gave containerd beside it. These are the resolved values, not the strings from the Cluster’s spec.runtime. An operator who changes a setting reads back here what each machine actually runs.

Field Type Required Description
k3s object no The runtime discipline of the k3s process on this machine. containerd and the shims get the same Go environment. This field is absent when init set no variable and rendered no log level, so k3s runs on Go’s own defaults and logs at info.
kubelet object no The kubelet configuration that init wrote on this machine, from the Cluster’s spec.runtime.kubelet. This field is absent when the cluster names no setting, so init wrote no configuration file and the kubelet runs on its own defaults.
containerd object no The containerd configuration that init wrote on this machine, from the Cluster’s spec.runtime.containerd. This field is absent when the cluster names no setting, so init wrote no drop-in and containerd runs on its own defaults.

status.runtime.k3s

The runtime discipline of the k3s process on this machine. containerd and the shims get the same Go environment. This field is absent when init set no variable and rendered no log level, so k3s runs on Go’s own defaults and logs at info.

Field Type Required Description
goMemoryLimit string no The resolved memory ceiling, as an absolute quantity in MiB, for example “256Mi”. It is empty when the cluster does not set the ceiling or turns it off, so an absent value means no ceiling and Go’s own default.
goGC integer no The resolved collector rate (Go’s GOGC). It is absent when the cluster sets no value, so k3s keeps Go’s own rate.
debug boolean no True when init told k3s to log at debug, which reaches every Kubernetes component inside the process. It is absent when the cluster sets no value, so k3s logs at info.

status.runtime.kubelet

The kubelet configuration that init wrote on this machine, from the Cluster’s spec.runtime.kubelet. This field is absent when the cluster names no setting, so init wrote no configuration file and the kubelet runs on its own defaults.

Field Type Required Description
imageGC object no The image collection policy that this machine’s kubelet runs. Each field is present only when the cluster names it, so an absent field means the kubelet’s own default for that field.

status.runtime.kubelet.imageGC

The image collection policy that this machine’s kubelet runs. Each field is present only when the cluster names it, so an absent field means the kubelet’s own default for that field.

Field Type Required Description
highThresholdPercent integer no The disk usage that starts collection, as a percent of the filesystem that holds containerd’s image store. It is absent when the cluster names no value, so the kubelet uses 85.
lowThresholdPercent integer no The disk usage that stops collection, as a percent of the same filesystem. It is absent when the cluster names no value, so the kubelet uses 80.
maximumAge string no How long an unused image may stay in the store before the kubelet removes it, whatever the disk usage is. It is absent when the cluster names no value, so the kubelet does no age check and only the thresholds prune the store.
minimumAge string no How long an unused image is kept before the kubelet may remove it. It is absent when the cluster names no value, so the kubelet uses two minutes.

status.runtime.containerd

The containerd configuration that init wrote on this machine, from the Cluster’s spec.runtime.containerd. This field is absent when the cluster names no setting, so init wrote no drop-in and containerd runs on its own defaults.

Field Type Required Description
logLevel string no The log level that this machine’s containerd runs at. It is absent when the cluster names no level, so containerd uses info.

status.lastCrash

The most recent kernel crash that this machine still holds records for. When the kernel panics, it writes the end of its log to the firmware’s storage, and the next boot moves that record onto the machine’s own disk. Each boot derives this summary from the records again. The crash is not always the previous boot’s crash. The summary stays until the records leave the machine’s retention window, and the time field gives the age of the crash. An empty field means that the machine holds no crash records.

Field Type Required Description
time string no The machine’s own clock at the time of the crash. A crash usually occurs before the boot’s first clock synchronization, so this time comes from the hardware clock.
reason string no The kernel’s word for the crash. The shipped kernel records two words: Panic and Oops. The vocabulary belongs to the kernel, so this field is a free string, not a fixed list.
message string no The kernel’s first description of the failure, in the kernel’s own words: the “Kernel panic - not syncing:” line, or the “BUG:” line of an oops.
records string no The directory on the machine that holds the full end of the kernel log: a directory in the crash store under machineState, or /sys/fs/pstore on a machine whose machineState runs in memory.

status.lastFailStop

The last boot that this machine refused to run. Init stops a boot for two failures: it cannot tell which configuration is its own, or it cannot satisfy a declared storage role. A machine that runs with the wrong configuration can do damage that a reboot does not undo, so init powers the machine off instead. The refusal writes its reason to the machine’s own disk, and the next boot reports it here. The refusal is not always the previous boot, and the time field gives the age of the news. Nothing clears this field. The next refusal replaces it. An empty field means that this machine has never refused a boot, or that the role it could not satisfy was the one that holds the record.

Field Type Required Description
time string no The machine’s own clock at the refusal. A boot stops before its first clock synchronization, so this time comes from the hardware clock.
reason string no Init’s own words for the refusal, the same text that the console printed before the machine powered off.

status.conditions[]

The typed observations that the operators keep on this machine, in the standard Kubernetes form. Each pass writes every condition again. Ready is the roll-up, and it is True only when every other condition is True. The other conditions each report one check: FactsPublished for the facts that init writes, SysctlsApplied, StorageReady, ModulesLoaded, FeaturesReady, and NodeLabelsApplied for the parts of the spec that the operator applies, NodeHealthy for the Node’s own Ready condition, NodeCurrent for the cleanup after a demotion, and SpecConverged, ClusterConverged, VersionConverged, CredentialsConverged, and ImportsConverged for the documents and the release that this boot ran under. RebootApproved is the one condition that another program writes: the cluster operator adds it to grant this machine a reboot turn, and removes it to take the grant back. Its absence carries the meaning, so it has no False state, and Ready does not count it.

Field Type Required Description
type string yes The check that this entry reports, in CamelCase. It is the key of this list, so a machine carries one entry for each type. The description of the conditions field lists the types that liken publishes. Pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$.
status string yes The verdict. Every condition type on a Machine states a healthy fact, so True is the good verdict for all of them. Unknown means that the operator cannot tell yet, for example when the machine’s facts carry no boot record. One of: True, False, Unknown.
observedGeneration integer no The metadata.generation that this condition judged. The generation counts spec edits, so this field lets a client tell a verdict on the current spec from a verdict on an earlier spec. That difference is important here, because an edit can wait for a reboot.
reason string yes Why the condition holds this status, in one CamelCase word. Programs read this field, so it changes less than the message does. Ready reports Reconciled when it is True. When Ready is False, its reason is the phase word that the conditions produce, so the roll-up and the phase agree: a machine that waits on a reboot turn reads UpdatePending, and Degraded appears exactly when the phase says Degraded. NothingDeclared is the reason that a check with nothing to do reports. The convergence conditions share one set of reasons: Converged, FactsIncomplete, MachineStateEphemeral, StagingRejected, RejectedLastBoot, AwaitingTurn, RebootPending, RebootRequested, RestartPending, RestartRequested, and StagedForNextBoot. The last one means that the machine holds the change and applies it at its next boot. Only a boot reads the fields that changed, so no reboot and no restart is scheduled. Pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$.
message string no The detail, for a person to read. A message names the correction where one exists, for example the roles that memory still backs, or the exact difference between the spec and this boot.
lastTransitionTime string yes The time when the status of this condition last changed. A pass that writes the same status again does not move this time, so the field gives the length of time that this verdict has held.

status.pending[]

What this machine waits to apply: one entry for each staged document that needs a disruption. Each entry names the convergence condition that reported it, the kind of disruption that applies it, the staged document’s hash, and a one-line summary. To grant one change its disruption on a machine whose rebootPolicy is Manual, annotate the machine with liken.sh/approve-disruption set to the entry’s hash (the liken CLI’s approve-reboot command does this). The grant is one-shot: once the change applies, its hash is no longer pending, and the next change hashes differently, so a stale annotation approves nothing. A reboot that a person requested through the liken.sh/request-reboot annotation is an entry here too. It waits on the same policy, the same turn, and the same drain, and the one thing it lacks is a document, so its hash is the running boot’s identity instead.

Field Type Required Description
condition string yes The condition that reported this entry, for example CredentialsConverged, or RebootRequestHonored for a reboot that a person requested.
kind string yes What applies the staged document. A reboot applies every staged document at once. A restart applies only the documents that k3s reads when its process starts, and the machine does not reboot. One of: Reboot, Restart.
hash string yes The staged document’s identity: the value that an approve-disruption annotation names to grant this change its disruption. A requested reboot has no document, so its entry carries the running boot’s identity, which spends itself the same way.
summary string yes One line saying what the document changes.