add requests.memory to rancher pods (!7092) · Merge requests · Sylva-projects / sylva-core

Related to &102

To have proper scheduling of pods without risking having memory pressure on nodes, we need to have pods with requests.memory set to a value that reflects something close to their actual use.

This is easier said than done since the actual use depends on many factors, in particular the deployment scale. This whole topic is tracked in &102.

At short term, to solve problems seen in CI runs, at the very least we need to cover large pods, let's say the ones using 1GiB or more, and ensure that they have a requests.memory that reflect the fact that they can be large.

This MR does this for Rancher:

the "dev or CI" of 1.5Gi value reflects what I observed in CI and dev environments (one mgmt cluster, one workload cluster) -- see for instance https://gitlab.com/sylva-projects/sylva-core/-/jobs/13309434923/artifacts/external_file/management-cluster-dump/prometheus-extracts/mem-per-workload-above-500-MiB.txt and https://gitlab.com/sylva-projects/sylva-core/-/jobs/13324395164/artifacts/external_file/management-cluster-dump/prometheus-extracts/mem-per-workload-above-500-MiB.txt for cattle-system
the production value, which is based on observations made on real deployments gathered by @tiberiu.mihai.22.97 (see !6377)

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	`light-deploy`, `dev-sources`, `ha`, `misc`, `maxsurge-0`, `logging`, `no-logging`, `cilium`
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment (i.e `real-bmh` for capm3 )

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Mar 03, 2026 by Thomas Morin

add requests.memory to rancher pods

CI configuration

Global config for deployment pipelines

Merge request reports