K3s Stable Channel And SLES Install Reliability

The k3s repository moved its lightweight Kubernetes distribution to v1.36.3+k3s1 on the stable channel. The surrounding work is small but useful for data platform operators: SLES repository selection is more precise, rootless setup fails earlier, and existing tests now reach the unit coverage job.

The stable channel update changes one value in channel.yaml. The stable entry moves from v1.36.2+k3s1 to v1.36.3+k3s1. Systems that resolve the stable channel will therefore select the newer build once they next perform an install or upgrade through that channel.

That narrow scope matters. This commit contains no Kubernetes code, schema migration, or installer logic. It is a distribution metadata change. Operators should treat it as the rollout trigger, not as a description of the patch contents. Review the release evidence used by the local change process before allowing automatic channel resolution to advance production clusters.

For ETL nodes, the usual checks still apply: storage attachment, CNI readiness, DNS, and restart behavior for stateful workers. Nothing in this activity set supplies performance numbers or claims a change to workload scheduling.

The operational risk is channel based drift. A node rebuilt from the stable channel can now receive a different k3s build than an otherwise identical node provisioned before the pointer moved. Fleets that require deterministic recovery should record the resolved version and pin it in automation. That keeps emergency replacement work from becoming an unplanned patch rollout.

The most direct operator fix is the SLES package selection change in install.sh. During SELinux setup, a host with ID=sles and a major VERSION_ID of 16 or later now selects the slemicro repository path. The script also recognizes the transactional, sle-micro, sl-micro, and sle-micro-rancher identities as SLE Micro variants. OpenSUSE Leap stays on the microos path.

This corrects a packaging boundary, not Kubernetes behavior. The affected path decides where k3s-selinux is resolved during installation. A wrong repository choice can stop node provisioning before kubelet or a data workload starts, which makes it a meaningful fix for automated fleet builds.

The new selinux_test.go exercises seven distribution cases: SLES 16, SLE Micro 5.5, SL Micro 6.0 through 6.2, OpenSUSE Leap 15.6, and AlmaLinux 10. Each case checks the configured base URL and confirms that the package query resolves rancher.k3s.common. A separate case confirms that requesting an SELinux RPM skip leaves no repository file. The install.yaml workflow now runs this Docker suite when the installer or its SELinux tests change.

The matrix tests the fragile part of this logic: distribution identity from os-release is not uniform across related products. It validates both repository construction and package visibility rather than checking only the shell branch. The cost is more external package infrastructure in CI, with failures possible when an image registry or RPM endpoint is unavailable.

Rootless end to end setup previously could reach k3s startup without newuidmap in PATH. The rootless setup fix updates apt metadata before installing uidmap, then verifies the binary with command -v. The change in setup_rootless.sh turns a later UID and GID mapping error into an explicit setup failure.

This is CI maintenance rather than a runtime feature. It adds an apt network operation, so the setup may take longer and remains dependent on repository availability. The benefit is a clearer failure boundary: a stale package index no longer presents as a k3s startup defect.

The unit test selection change is smaller still. Nine existing test functions were renamed to include Unit, matching the coverage workflow filter. No assertion was added. Tests for resolv configuration, Flannel network mode, bootstrap migration, storage encryption, and node password errors were valid Go tests before, but the filtered job did not select them. Files such as encrypt_test.go and setup_test.go now participate in that coverage path.

Test naming is therefore part of the CI execution contract. A future test without Unit may still run under an unrestricted go test, yet remain invisible to this coverage job. The rename repairs nine cases, while the broader convention still depends on reviewers noticing the prefix.

  • Validate v1.36.3+k3s1 in a staging cluster using the same stable channel mechanism as production. The channel commit alone does not explain the release payload.

  • On SLES 16 and SLE Micro images, inspect the selected RPM base URL and package source, especially when an internal mirror rewrites repository definitions.

  • Watch the restored unit coverage and the new SELinux matrix for failures. Both changes expand what CI observes; neither proves every supported image or upgrade path is covered.