K3s

K3s provides a single-node Kubernetes control plane while host-level Caddy retains public HTTP/HTTPS ingress. The profile uses embedded SQLite, CoreDNS, metrics-server, and the stock Local Path Provisioner. Traefik and ServiceLB are disabled, SELinux support is enabled, and the Kubernetes API is not exposed through the public firewalld zone.

The live host configuration supplies a private node address and places local-path data under /home/k3s-storage, where the host has substantially more capacity than its root filesystem. The canonical kubeconfig under /etc/rancher/k3s/ is read through a dedicated group with mode 0640. K3s refreshes credentials in that file; a copied home-directory kubeconfig would become stale.

The host-generated configuration and live Kubernetes objects are runtime state, not a second desired-state tree kept in this public repository. Fresh bootstrap owns absent resources. Existing workloads move through their maintenance and recovery paths instead.

Local Path Provisioner and SELinux

A persistent SELinux file-context rule labels the storage tree container_file_t. PVC provisioning, binding, mounting, writing, and reading succeeded with SELinux enforcing.

PVC deletion has a known edge case. A volume can remain Released, its cleanup helper pod can enter Error, and the backing directory can remain after an SELinux MCS-category mismatch. A later cleanup helper may not receive categories compatible with the directory created or used by the earlier workload.

SELinux stays enforcing and the stock provisioner and existing storage label remain in place while K3s issue #14508 is monitored. Incident cleanup first resolves the exact PV, helper pod, and directory, then removes only the abandoned object. Maintaining a broad custom provisioner workaround would create a larger local divergence for a deletion-specific failure.

Recovery limits

Embedded SQLite recovery requires the datastore directory and matching server token together, with the live K3s configuration in the same recovery set. A tested backup stopped K3s, copied that state, restarted the service, and confirmed nodes and pods healthy.

A backup on the same physical storage protects against some configuration mistakes and bad upgrades, not device loss. It also excludes application PVC data. K3s upgrades and application maintenance remain separate lifecycles.