Profiles

Kubernetes Pods do not have access to every system resource. Kubernetes reserves a certain amount of CPU and memory for:

the system (kernel & daemons)
Kubelet & container runtime
an eviction threshold (to be able to react to memory pressure)

MetaKube Node Profiles control the amount of reserved resources.

The resource reservation of a given profile depends on the Machine's cloud flavor. MachineDeployments that don't set a profile explicitly use the default profile.

Profile	CPU formula	Memory formula
`metakube-2025-01`, `metakube-latest` (default)	`20m + MaxPods * 2m/Pod`	`190MiB + MaxPods * 6.5MiB/Pod`
`metakube-legacy` (deprecated)	`200m`	`300MiB`

MetaKube also reserves 200m CPU and 500MiB of memory for the system regardless of flavor.

The eviction threshold is 100MiB.

Flavors

MetaKube scales the Pod limit by the available memory. That in turn determines the amount of reserved resources.

Available memory	Example Flavors	Pod limit	Reserved CPU	Reserved Memory
8GiB	`SCS-2V-8-50n`	50	120m + 200m	515MiB + 500Mi + 100Mi
16GiB	`SCS-4V-16-*`	70	160m + 200m	645MiB + 500Mi + 100Mi
32GiB	`SCS-8V-32-*`	90	200m + 200m	775MiB + 500Mi + 100Mi
> 32GiB	upon request	110	240m + 200m	905MiB + 500Mi + 100Mi

Tuning

The formulas for the metakube-latest profile come from experiments. We aim to balance stability and practicality.

The experiments run with the following assumptions:

Container to Pod ratio of 1.25

This accounts for typical use of sidecar containers. At higher ratios, the container runtime may require more memory.

Full nodes

Reserved resources should cover nodes running Pods up to the limit.

Minimal Pod churn

Kubelet and the container runtime consume more CPU during Pod create and delete events. Since they stay idle for most of the time and may also use spare CPU time, we decided not to reserve more CPU than necessary. Frequent Pod churn may stretch the time Pods take to become running or fully deleted.

These assumptions hold true for most use cases because these thresholds do not cross at once in typical operation.

If your use case differs from these assumptions, adjust the reserved resources to keep your nodes stable.

Change MaxPods

You may improve node resource usage by setting higher or lower Pod limits.

A higher Pod limit means you can pack more Pods on a single node.

Lower Pod limits mean the system reserves fewer resources, leaving more allocatable for Pods.

To change the Pod limit set the following Machine annotation in your MachineDeployment:

kind: MachineDeployment
spec:
  template:
    metadata:
      annotations:
        kubelet-config.machines.metakube.syseleven.de/MaxPods: "30"

Change profiles

Changing profiles

Change the profile to opt in or out when migrating from legacy profiles.

To configure a different profile set the following Machine annotation in your MachineDeployment:

kind: MachineDeployment
spec:
  template:
    metadata:
      annotations:
        kubelet-config.machines.metakube.syseleven.de/KubeReservedProfile: "metakube-latest"

Change reserved resources directly

Manual resource reservations

Change these settings when required. Reserving too few resources may lead to node instability.

To change the reservation for individual resources set the following Machine annotation in your MachineDeployment:

kind: MachineDeployment
spec:
  template:
    metadata:
      annotations:
        kubelet-config.machines.metakube.syseleven.de/KubeReserved: "cpu=500m,memory=1Gi"

References

Allocatable resources