Skip to content

Latest commit

 

History

History
233 lines (184 loc) · 10.7 KB

external-runtime-deps.md

File metadata and controls

233 lines (184 loc) · 10.7 KB
Raw

External runtime dependencies

k0s is packaged as a single binary, which includes all the needed components. All the binaries are statically linked which means that in typical use cases there's an absolute minimum of external runtime dependencies.

However, depending on the node role and cluster configuration, some of the underlying components may have specific dependencies, like OS level tools, packages and libraries. This page aims to provide a comprehensive overview.

The following command checks for known requirements on a host (currently only available on Linux):

k0s sysinfo

A unique machine ID for multi-node setups

Whenever k0s is run in a multi-node setup (i.e. the --single command line flag isn't used), k0s requires a machine ID: a unique host identifier that is somewhat stable across reboots. For Linux, this ID is read from the files /var/lib/dbus/machine-id or /etc/machine-id. For Windows, it's taken from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid. If neither of the OS specific sources yield a result, k0s will fallback to use a machine ID based on the hostname.

When running k0s on top of virtualized or containerized environments, you need to ensure that hosts get their own unique IDs, even if they have been created from the same image.

Linux specific

Linux kernel configuration

Needless to say, as k0s operates Kubernetes worker nodes, there's a certain number of needed Linux kernel modules and configurations that we need in the system. This basically stems from the need to run both containers and also be able to set up networking for the containers.

The needed kernel configuration items are listed below. All of them are available in Kernel versions 4.3 and above. If running on older kernels, check if the distro in use has backported some features; nevertheless, it might meet the requirements. k0s will check the Linux kernel release as part of its pre-flight checks and issue a warning if it's below 3.10.

The list covers ONLY the k0s/kubernetes components’ needs on worker nodes. Your own workloads may require more.

Note: As part of its pre-flight checks, k0s will try to inspect and validate the kernel configuration. In order for that to succeed, the configuration needs to be accessible at runtime. There are some typical places that k0s will check. A bullet-proof way to ensure the accessibility is to enable CONFIG_IKCONFIG_PROC, and, if enabled as a module, to load the configs module: modprobe configs.

Control Groups (cgroups)

Both cgroup v1 and cgroup v2 are supported.

Required cgroup controllers:

  • cpu
  • cpuacct
  • cpuset
  • memory
  • devices
  • freezer
  • pids

Optional cgroup controllers:

No integration with Name Service Switch (NSS) APIs

The k0s Linux binaries are by default statically linked against musl libc. This includes the binaries distributed on the GitHub releases pages. Static linking ensures that k0s can run seamlessly across a wide range of Linux environments by not requiring a specific standard C library to be installed on the host system. However, this design choice means that k0s cannot use glibc's NSS APIs, which require dynamic linking.

This limitation is particularly relevant when a system uses NSS plugins, such as nss-myhostname, for resolving network names like localhost. Systems lacking a dedicated stub resolver capable of handling localhost DNS queries specifically will encounter issues running k0s. To mitigate this, users are advised to either activate a stub DNS resolver, such as systemd-resolved, or to manually add localhost entries to the /etc/hosts file as shown below:

127.0.0.1 localhost
::1 localhost

External hard dependencies

There are very few external tools that are needed or used.

mount/umount

When setting up pods, kubelet will call mount binary on the host. Similarly when destroying pods it will call umount. mount and umount are only needed on worker nodes where kubelet runs.

External soft dependencies

There are a few external tools that may be needed or used under specific circumstances:

containerd and AppArmor

In order to use containerd in conjunction with AppArmor, it must be enabled in the kernel and the /sbin/apparmor_parser executable must be installed on the host, otherwise containerd will disable AppArmor support.

iptables

iptables may be executed to detect if there are any existing iptables rules and if those are in legacy of nft mode. If iptables is not found, k0s will assume that there are no pre-existing iptables rules.

useradd / adduser

During k0s install the external tool useradd will be used on the controllers to create system user accounts for k0s. If this does exist it will fall-back to busybox's adduser.

userdel / deluser

k0s reset will execute either userdel or deluser to clean up system user accounts.

modprobe

On k0s worker modprobe will be executed to load missing kernel modules if they are not detected.

id

External /usr/bin/id will be executed as a fallback if local user lookup fails, in case NSS is used.

Windows specific

TBD.