System component resourcingNew

MKE 4 allows you to override the CPU and memory resource requests and limits for several system component Pods through the MkeConfig CRD (mke4.yaml configuration file). Each configurable component exposes a resources block that follows the standard Kubernetes requests and limits shape, with cpu and memory keys. All fields are optional, with those not set falling back to the the built-in default for the component.

Configurable components

The following MKE 4 components accept a resources block:

Component	Spec path in MkeConfig	Applies to
MKE Operator	spec.operator.resources	Management cluster only
k0rdent/kcm controller	spec.k0rdent.resources	Management cluster only
MKE Dashboard	spec.ui.resources	Management and child clusters
Dex	spec.authentication.resources	Management and child clusters
Prometheus	spec.monitoring.prometheus.resources	Management cluster only

The MKE Operator, k0rdent/kcm controller, and Prometheus components are installed on the management cluster only, and thus their resources blocks have no effect on child clusters. Only the MKE Dashboard and Dex components apply to child clusters. For child clusters, you can also set the MKE Dashboard resources block on the MkeChildConfig object.

If you omit a resources block — or any individual key within one — the following defaults apply:

Component	requests.cpu	requests.memory	limits.cpu	limits.memory
MKE Operator	100m	256Mi	500m	512Mi
k0rdent/kcm	100m	256Mi	500m	512Mi
MKE Dashboard	50m	64Mi	(none)	128Mi
Dex	50m	128Mi	(none)	256Mi
Prometheus	250m	1Gi	1000m	6Gi

Note

The MKE Dashboard and Dex components intentionally have no CPU limit by default, only a memory limit. This is deliberate, not an oversight.

Example configuration

The following mke4.yaml configuration file excerpt overrides resources for each configurable component. The k0rdent block sets only requests.cpu; all of its other values remain at their defaults.

apiVersion: mke.mirantis.com/v1alpha1
kind: MkeConfig
metadata:
  name: mke
spec:
  operator:
    resources:
      requests:
        cpu: 200m
        memory: 384Mi
      limits:
        cpu: "1"
        memory: 768Mi
  k0rdent:
    resources:
      requests:
        cpu: 250m       # only this key is overridden; the rest keep defaults
  ui:
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        memory: 256Mi
  authentication:
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        memory: 512Mi
  monitoring:
    prometheus:
      resources:
        requests:
          cpu: 500m
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 8Gi

How overrides are applied

Overrides are merged with the defaults on a per-key, additive basis: each individual resource key is overridden independently, so setting only requests.cpu, for example, leaves requests.memory and all limits at their default values. Omitting a value does not clear it, since you cannot remove a default by leaving a key out; an omitted value falls back to the default rather than unsetting it. To effectively lift a limit, set it to a sufficiently high value instead.

Sizing guidance

Before you adjust the values for a component, profile its actual consumption so that the requests and limits you set reflect real usage:

• Measure steady-state usage. Use kubectl top pod to observe the CPU and memory that the component consumes under representative load.

• Set requests near steady state. Configure the requests size to be close to the steady-state consumption, so that the scheduler reserves an accurate amount of capacity.

• Set limits to absorb spikes. Configure the limits size above the requests — for example, at 1.5 to 2 times the steady-state value — to accommodate transient bursts without throttling or eviction.

Validation and constraints

• Each value must be a valid Kubernetes quantity, for example 250m, 512Mi, or "2". Bare integers, such as 2, are also accepted, but quote it as "2" for clarity and consistency.
• The API server rejects invalid values at apply time. No additional custom validation is performed.
• These fields are net-new, optional, and have sane defaults. No action is required when upgrading from MKE 3 to MKE 4 or between MKE 4 versions; the defaults apply automatically.