Skip to main content

Embedded Kubernetes Cluster Requirements

Chef 360 Platform has the following system requirements.

Hardware requirements

Chef 360 Platform has the following minimum hardware requirements:

  • 16 GB of RAM
  • 4 vCPUs
  • 80 GB of disk space

Note

If the root directory has space restrictions, mount the following directories before installing:

  • /var/lib/k0s/
  • /run/k0s/
  • /var/lib/embedded-cluster
  • /etc/k0s/

Ports

Open the following ports if you are using default ports.

Ports for inbound connections:

PortDescription
30000Chef 360 Platform Console
31000API Gateway
31050RabbitMQ
31100Mailhog (Optional)
22SSH
5985–5986WinRM

Ports for outbound connections:

PortDescription
443For non-air gapped installations

FQDN

Chef 360 Platform requires an FQDN that’s registered with a DNS and that all nodes can reach.

Kubernetes requirements

The Chef 360 Platform embedded Kubernetes cluster uses k0s as the underlying cluster runtime. All of the same limitations that exist for k0s exist for a Chef 360 Platform embedded cluster. However, in the case of a conflicting requirement, follow the Chef 360 Platform documentation. For example, k0s has experimental support for Windows, but Chef 360 Platform doesn’t support Windows-based clusters.

Preflight checks during the installation and configuration verifies the system requirements before proceeding. To ensure a smooth operation, please review the requirements detailed of this document.

Firewall openings required for online installations

Chef 360 Platform requires access to the following domains and IP addresses to download artifacts during the installation process:

  • registry.chef360.chef.io

  • download.chef360.chef.io

  • proxy.chef360.chef.io

  • appservice.chef360.chef.io

  • Docker Hub hosts public images of some KOTS dependencies. The required domains for Docker Hub are:

    • index.docker.io
    • cdn.auth0.com
    • *docker.io
    • *docker.com

External runtime dependencies

Chef 360 Platform’s k0s distribution 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.

Machine ID

Whenever k0s runs in a multi-node setup, k0s requires a unique machine ID, which is a unique host identifier that’s somewhat stable across reboots. For Linux, k0s reads this ID from the /var/lib/dbus/machine-id or /etc/machine-id files. If not found, k0s falls back to use a machine ID based on the hostname.

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

Linux requirements

Linux kernel configuration

K0s and Kubernetes require specific Linux kernel features to run Chef 360 Platform worker nodes. Linux kernel versions 4.3 and greater have all of the required configurations.

During a pre-flight check, k0s checks the Linux kernel and issues a warning if it’s below version 3.10.

If you are running on an older Linux kernel, see the following list of required Kernel features as it might still meet the requirements:

Note

The Kernel configuration must be accessible at runtime for k0s to run its pre-flight check.

Enable CONFIG_IKCONFIG_PROC, and, if enabled as a module, load the modprobe configs module to ensure accessibility.

Control Groups (cgroups)

Both cgroup v1 and cgroup v2 are supported.

Required cgroup controllers:

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

Optional cgroup controllers:

containerd and cri-o use blkio to track disk I/O and throttling in both cgroup v1 and v2.

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 can’t 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, either activate a stub DNS resolver, such as systemd-resolved, or manually add localhost entries to the /etc/hosts file as shown below:

127.0.0.1 localhost
::1 localhost

External software dependencies

The following external tools are required.

mount/umount

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

The following external tools 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 disables 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 isn’t 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 aren’t detected.

id

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

Thank you for your feedback!

×











Search Results