SIGHUP Distribution v1.35.0 and the new Immutable provider

SIGHUP Distribution (SD) continues to evolve and today we're releasing version 1.35.0.

This release introduces Kubernetes 1.35, updates every core module and ships a set of changes that make the distribution more complete and easier to operate day to day. These changes range from the provision of a self-contained Ansible installation among its tools, complete with its uv build toolchain, to the introduction of a new observability tool for clusters that use Calico as their Container Network Interface (CNI). A new capability is also available as an alpha feature: the Immutable provider.

Here's what's in it:

• Support for Kubernetes 1.35.
• Introduction of the new Immutable kind.
• An Ansible binary built into the OnPremises kind, removing the need to install Ansible on the host system.
• Migration of the NGINX ingress controller and MinIO container images to the Chainguard fork, maintained under the EmeritOSS Program, which provides CVE patching and gives users time to plan a migration.
• Introduction of Whisker, a network observability tool for clusters that use Tigera Calico as their CNI.
• Support for nftables mode for kube-proxy on OnPremises clusters.
• Introduction of a new customResources field in the distribution schema, which enables the deployment of additional custom resources alongside the distribution phase.

Before jumping in: this release includes breaking changes, so, as usual, give the official release notes a careful read before you upgrade.

Kubernetes v1.35

Each new Kubernetes version introduces a set of considerations that must be evaluated prior to its adoption.

For this version, among other things, please note that support for cgroup v1 was removed in Kubernetes 1.35. This is an important point: if you are still using nodes running Linux distributions that do not support cgroup v2, the kubelet will fail to start. To avoid downtime, you will need to migrate to systems where cgroup v2 is enabled.

The Kubernetes 1.35 release blog covers this change in detail.

The new Immutable provider

This release introduces the new Immutable kind in alpha. Built on Flatcar Container Linux, it allows the distribution to provision Kubernetes clusters starting from the operating system, whether on bare-metal servers, virtual machines, or other environments.

By taking control of the entire stack from the OS to the Kubernetes distribution, the Immutable kind provides greater security, infrastructure immutability, and declarative configuration. Please note that this is the first alpha release, so its implementation and APIs may still change significantly.

kube-proxy grows a third mode

OnPremises clusters can now run kube-proxy in nftables mode in addition to the previously available IPVS mode. Kubernetes 1.35 formally deprecates IPVS mode for kube-proxy (KEP-5495) and upstream now recommends nftables as its replacement, since it outperforms IPVS.

To enable it in SD, the old kubeProxy.enabled field is replaced by a kubeProxy.type enum with three values: ipvs, nftables and none:

apiVersion: kfd.sighup.io/v1alpha2
kind: OnPremises
metadata:
  name: your-cluster
spec:
  kubernetes:
    advanced:
      kubeProxy:
        type: nftables

Under the hood, switching to nftables mode also requires a corresponding change to the CNI's dataplane configuration, something an administrator would otherwise have to do manually. SD takes care of that for you.

According to the upstream Kubernetes documentation, the Linux kernel must be version 5.13 or later, and the nft command-line utility installed on the host must be version 1.0.1 or later. Before enabling nftables mode on an existing OnPremises cluster, administrators should verify the kernel of every node.

A new customResources field, for the cases plugins don't quite cover

Plugins remain the recommended mechanism for deploying supplementary resources alongside the distribution and this release does not change that recommendation. However, certain edge cases exist, such as dependencies between objects (for instance, the StorageClass on which the distribution phase itself depends), in which an SD plugin may encounter cyclic dependencies; that is, the plugin depends on resources that are, in turn, dependent on the completion of the distribution phase, resulting in a circular dependency that cannot be resolved through the ordinary plugin mechanism.

The new customResources field lets you deploy custom resources alongside the distribution phase itself, sidestepping the problem entirely. Introduced as a sibling of the existing customPatches field under spec.distribution, it is an array of strings that mirrors Kustomize's top-level resources list:

spec:
  distribution:
    customResources:
      - ./localstorage
      - github.com/org/repo/storage-class/x?ref=v1

Also fixed in this release

A few issues worth knowing about even if they didn't make the highlights:

• furyctl apply now correctly skips the deletion of default Kyverno policies on clusters where the corresponding Custom Resource Definitions (CRDs) are not installed.
• Worker nodes on OnPremises clusters now correctly retrieve the custom container registry configuration for the pause container image.
• The monitoring module now correctly suppresses PrometheusOperatorRejectedResources alerts for AlertmanagerConfig resources that are deployed without their corresponding webhook URLs configured.
• The policy module's NetworkPolicy configuration has been corrected in order to allow ingress traffic when the appropriate settings are in place.

Upgrading

As usual, the upgrade documentation provides a complete reference of the procedure required to migrate a cluster from one SD version to the next through the use of furyctl.

Our team continuously works to respond to industry shifts and to keep the distribution up to date. If you have feedback or want to get involved, feel free to open a discussion on GitHub. Keep following us!