Linux Cgroups v2 & Kernel-Limits für Multi-Tenant Bot-Hosting

Wenn mehrere Kunden-Bots auf einem gemeinsamen Linux-Server betrieben werden, kann ein fehlerhafter Bot mit einer Endlosschleife (while(true)) oder einem Speicherleck die gesamte Maschine lahmlegen. Ohne Kernel-Einschränkungen beansprucht dieser Prozess 100 % aller CPU-Kerne, verdrängt andere Prozesse in die Swap-Partition und führt zum Absturz benachbarter Anwendungen (das klassische "Noisy Neighbor"-Problem).

Auf KiroCloud setzen wir auf Linux Control Groups (Cgroups v2) und systemd Resource Accounting, um jedem Bot-Container exakte Hard- und Soft-Limits für CPU, RAM und I/O zuzuweisen.

1. Was sind Cgroups v2?

Cgroups (Control Groups) sind eine Kernel-Funktion von Linux, die es erlaubt, Prozesse in hierarchischen Gruppen zu organisieren und deren Ressourcenverbrauch präzise zu drosseln:

• CPU Controller (cpu.max): Bestimmt, wie viel CPU-Zeit ein Prozess pro Zeitfenster nutzen darf.
• Memory Controller (memory.max, memory.high): Begrenzt den physikalischen RAM-Verbrauch und steuert den Out-Of-Memory (OOM) Killer.
• IO Controller (io.max): Begrenzt Lese- und Schreiboperationen auf Enterprise-NVMe-SSDs, um I/O-Staus zu verhindern.

                  ┌───────────────────────────────┐
                  │    Linux Kernel Cgroups v2    │
                  └───────────────┬───────────────┘
         ┌────────────────────────┼────────────────────────┐
         ▼                        ▼                        ▼
  /sys/fs/cgroup/         /sys/fs/cgroup/          /sys/fs/cgroup/
  bot-1234/               bot-5678/                bot-9999/
  ├── cpu.max: 50000      ├── cpu.max: 100000      ├── cpu.max: 200000
  ├── memory.max: 512M    ├── memory.max: 1024M    ├── memory.max: 2048M
  └── io.max: 50M/s       └── io.max: 50M/s        └── io.max: 100M/s

2. CPU-Quotas konfigurieren: Keine 100%-Last durch Endlosschleifen

Das CPU-Limit wird in cpu.max als Bruchteil eines Quota-Fensters (Standard: 100.000 Mikrosekunden = 100 ms) definiert:

# 50% eines CPU-Kerns: 50.000 Mikrosekunden pro 100.000 Mikrosekunden-Fenster
echo "50000 100000" > /sys/fs/cgroup/kiro-bots/bot-alpha/cpu.max

# 1,5 CPU-Kerne:
echo "150000 100000" > /sys/fs/cgroup/kiro-bots/bot-beta/cpu.max

Wenn ein Bot mehr CPU-Zeit anfordert, als ihm zusteht, drosselt der Linux Completely Fair Scheduler (CFS) den Prozess automatisch, ohne dass andere Bots auf dem Host davon beeinträchtigt werden.

3. Memory Caps & Sanfte Drosselung (memory.high vs. memory.max)

In Cgroups v2 unterscheidet der Kernel zwischen einer sanften Warnschwelle (memory.high) und einer harten OOM-Grenze (memory.max):

# Sanftes Limit: Ab 450 MB wird der Bot gedrosselt und aggressiv bereinigt
echo "471859200" > /sys/fs/cgroup/kiro-bots/bot-alpha/memory.high

# Hartes Limit (512 MB): Bei Überschreitung greift der OOM-Killer
echo "536870912" > /sys/fs/cgroup/kiro-bots/bot-alpha/memory.max

Mit memory.high zwingt der Linux-Kernel den Prozess dazu, Page-Caches freizugeben und verlangsamt Speicherallokationen, bevor ein harter Crash eintritt.

4. Automatisches Management via systemd-run in Node.js

Anstatt Cgroups manuell im Pseudo-Dateisystem zu beschreiben, nutzt die KiroCloud Bot Engine systemd-run:

import { execSync } from 'node:child_process';

export function startBotWithCgroups(botId: string, scriptPath: string) {
  const serviceName = `kiro-bot-${botId}`;

  const cmd = [
    'systemd-run',
    `--unit=${serviceName}`,
    '--slice=kiro-bots.slice',
    '--property=CPUQuota=75%',
    '--property=MemoryMax=512M',
    '--property=MemoryHigh=450M',
    '--property=TasksMax=100', // Schutz vor Fork-Bomben
    '--property=Restart=on-failure',
    'node', scriptPath,
  ].join(' ');

  execSync(cmd, { stdio: 'inherit' });
  console.log(`[Cgroups] Bot ${botId} erfolgreich isoliert als ${serviceName} gestartet.`);
}

Mit dieser Architektur garantieren wir auf KiroCloud maximale Ausfallsicherheit und absolute Fair-Share-Verteilung aller Host-Ressourcen.