You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/cumulus-linux-517/System-Configuration/Docker-with-Cumulus-Linux.md
+97-53Lines changed: 97 additions & 53 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -444,92 +444,136 @@ log-level json-file
444
444
445
445
## Docker Resource Tiering System
446
446
447
-
Cumulus Linux includes a built-in Docker resource tiering system that acts as an automated governance layer for system resources. In a shared environment where users or automated scripts can launch arbitrary Docker containers, there is a significant risk that high-load compilation, a memory leak, or a stress test can consume 100 percent of the CPU or RAM, causing critical network services or the host OS itself to become unresponsive. The resource tiering system prevents resource exhaustion (Denial of Service) from untrusted workloads while guaranteeing performance for critical system applications.
447
+
Cumulus Linux includes a Docker Resource Tiering Governance system that protects the switch from noisy-neighbor CPU and memory exhaustion by classifying container workloads into governance tiers and placing them into the correct `systemd` slice at container creation time.
448
448
449
-
The built-in Docker resource tiering system is enabled by default and active after installation. The policy agent enforces runtime policy entirely in the background; no configuration is required.
449
+
The Governance system is not a long-running background agent; the packaged docker wrapper applies governance at container birth. The `cumulus-docker-resource-tier-governance.service` systemd service programs the tier slice limits and reconciles existing governance-managed containers when you start, reload, restart, or stop the service.
450
450
451
-
Cumulus Linux uses slices to apply shared resource limits to a group of processes:
452
-
-`docker-restricted.slice` is the default tier for third-party containers that are not whitelisted. This tier uses 10 percent host CPU and 10 percent host memory.
453
-
-`docker-limited.slice` is the intermediate tier for selected workloads that need more headroom than restricted but still need to be capped. This tier uses 50 percent host CPU and 50 percent host memory.
454
-
-`docker.slice` is the trusted tier for trusted NVIDIA containers and other explicitly trusted workloads. There is no host CPU or host memory cap.
451
+
When governance is enabled, containers use one of these tiers:
452
+
-`docker.slice` is the Trusted tier. Containers in this tier are not subject to CPU or memory caps.
453
+
-`docker-limited.slice` is the Limited tier. This tier is for workloads that need more headroom than the default tier but must still remain bounded.
454
+
-`docker-restricted.slice` is the Restricted tier. This is the default tier for images that are not whitelisted.
455
455
456
-
To disable the resource tiering system, stop, then disable the cumulus Docker policy agent:
456
+
By default, the Restricted and Limited tiers use aggregate limits of 10% and 50% of total host CPU and total host memory. These are shared per-tier limits, not per-container reservations. If multiple containers run in the same tier, they share the tier budget.
The packaged docker wrapper classifies supported docker container creation commands and places new containers directly into the correct parent slice with the appropriate `cgroup-parent`.
462
459
463
-
To re-enable the resource tiering system, enable, then start the cumulus Docker policy agent:
460
+
The `cumulus-docker-resource-tier-governance.service` service reads the current policy, programs the Restricted and Limited slice limits, and reconciles existing governance-managed containers when you apply policy. If you install the Docker Compose plugin, Docker compose workloads are also governed at creation time.
Governance does not move running container processes between control groups. If an existing governance-managed container needs to change tiers, the service recreates it in the correct slice. If the container is supervised by `systemd`, the service restarts the owning unit so the container is recreated through its normal service lifecycle.
463
+
464
+
### Governance Configuration
469
465
470
-
<!--
471
-
### Container Resources
466
+
Governance uses these configuration files:
472
467
473
-
You can customize these values by editing the `/etc/cumulus/docker/resources.conf` file.
468
+
-`/etc/cumulus/docker/resource-tier-governance/whitelist.json` controls which images are classified as Trusted or Limited.
469
+
-`/etc/cumulus/docker/resource-tier-governance/quotas.conf` controls the aggregate CPU and memory percentages for the Restricted and Limited tiers.
470
+
471
+
Images that are not listed in either the Trusted or Limited tier default to the Restricted tier.
472
+
473
+
The following example shows an `/etc/cumulus/docker/resource-tier-governance/whitelist.json` file:
The docker image whitelist maintains the list of trusted and limited images and is located in the `/etc/cumulus/docker/whitelist.json` file.
500
+
### Enable and Disable Governance
488
501
489
-
By default, the `/etc/cumulus/docker/whitelist.json` file ships with the following content.
502
+
The Docker Resource Tiering Governance system is installed and enabled by default. To disable governance immediately and prevent it from being enabled again at boot, stop and disable the service:
To show memory resource usage for containers, run the Linux `sudo cat /sys/fs/cgroup/cumulus-docker-trusted/memory.current` command.
525
+
{{%notice note%}}
526
+
- Enable and disable control boot-time activation only. Runtime policy changes occur when you start, reload, restart, or stop the service.
527
+
- If the service is already active, `systemctl start` does not reapply policy. Use `systemctl reload` to apply updated governance policy to a running system.
To move an image between tiers, edit the `/etc/cumulus/docker/resource-tier-governance/whitelist.json` file:
533
+
- To promote an image to Trusted, add it to `trusted_images` and remove it from `limited_images`.
534
+
- To move an image to Limited, add it to `limited_images` and remove it from `trusted_images`.
535
+
- To demote an image back to Restricted, remove it from both `limited_images` and `trusted_images`.
521
536
522
-
To show CPU resource usage for containers, run the Linux `sudo cat sys/fs/cgroup/cumulus-docker-trusted/cpu.stat` command and `sudo cat /sys/fs/cgroup/cumulus-docker-limited/cpu.stat` command.
537
+
After updating the whitelist, apply the change with the `sudo systemctl reload cumulus-docker-resource-tier-governance.service` command.
Use `systemctl reload` instead of `systemctl restart` for normal policy updates.
540
+
-`systemctl reload` re-reads the whitelist and quota files, reprograms the Restricted and Limited slice limits, and reconciles existing governance-managed containers against the updated policy. This avoids the extra churn caused by a full stop-then-start cycle.
541
+
-`systemctl restart` is more disruptive because it executes a full stop followed by start. The stop path disables governance and promotes governance-managed containers to docker.slice. The start path enables governance again and might recreate or restart the containers a second time to place them back into Limited or Restricted.
542
+
543
+
{{%notice note%}}
544
+
-`systemctl restart` might cause unnecessary container churn during normal whitelist updates. Use `systemctl reload` when governance is already active. If the service is currently inactive, run the `sudo systemctl start cumulus-docker-resource-tier-governance.service` command.
545
+
- If you update the `/etc/cumulus/docker/resource-tier-governance/quotas.conf` file, apply the change with the `sudo systemctl reload cumulus-docker-resource-tier-governance.service` command. For quota-only changes, `reload` updates the slice limits live and does not require recreating containers just to program the new slice cap values.
546
+
{{%/notice%}}
526
547
548
+
### Considerations
549
+
550
+
- Existing containers are reconsidered only when you apply governance with a service action such as `start`, `reload`, `restart`, or `stop`.
551
+
- Editing the `/etc/cumulus/docker/resource-tier-governance/whitelist.json` file or the `/etc/cumulus/docker/resource-tier-governance/quotas.conf` file does not retier existing containers until you apply governance again.
552
+
- Containers created before you install the governance wrapper, or other containers without governance metadata, are treated as unmanaged and are left untouched. To bring these containers under governance, stop and remove them, then recreate them.
553
+
- Containers created with an explicit Docker `--cgroup-parent` or `Compose cgroup_parent` remain under user control and are not re-tiered by governance.
554
+
- Retiering an existing container can require a stop, remove, and recreate operation or, for workloads that `systemd` supervises, a restart of the owning unit. Plan policy changes accordingly for stateful or production workloads.
555
+
- Governance enforces aggregate ceilings per tier. It does not provide guaranteed minimum CPU or memory reservations for each container inside a tier.
556
+
557
+
### Verify Container Placement and Tier Limits
558
+
559
+
To check the configuration of a container parent slice:
To show which container processes are trusted and which are limited, run the `sudo cat /sys/fs/cgroup/cumulus-docker-trusted/cgroup.procs` command or the `sudo cat /sys/fs/cgroup/cumulus-docker-limited/cgroup.procs` command:
565
+
To verify that the running process is actually under the expected slice:
To inspect the slice limits programmed by governance:
533
573
534
574
```
535
-
-->
575
+
cumulus@switch:~$ systemctl show docker-restricted.slice -p CPUQuotaPerSecUSec -p MemoryMax
576
+
cumulus@switch:~$ systemctl show docker-limited.slice -p CPUQuotaPerSecUSec -p MemoryMax
577
+
```
578
+
579
+
The authoritative CPU and memory limits are applied to the slice, not to the individual container scope. Verify both container placement and slice properties when checking governance behavior.
0 commit comments