Wazuh auf Kubernetes (EKS): Speicherwachstum bei Worker-Pods und periodische CPU-Spikes richtig einordnen und beheben

von

Einleitung
Der Betrieb von Wazuh in Kubernetes-Umgebungen wie AWS EKS bringt klare Vorteile bei Skalierung und Hochverfügbarkeit, legt aber auch Verhaltensweisen offen, die in klassischen VM-Deployments weniger auffallen. Zwei besonders kritische Symptome treten dabei immer wieder auf: stetig wachsender Speicherverbrauch von wazuh-manager-worker-Pods und exakt periodische CPU-Spikes, die ganze Nodes destabilisieren können. Dieser Artikel ordnet beide Effekte technisch ein und zeigt bewährte Gegenmaßnahmen für produktive Kubernetes-Setups.

Ausgangslage / Problemstellung
In einer EKS-Installation mit Wazuh 4.10 zeigen sich zwei Probleme:

  1. Ungebremstes Speicherwachstum
    • wazuh-manager-worker-Pods verbrauchen kontinuierlich mehr RAM
    • Es sind keine expliziten Memory-Limits gesetzt
    • Sobald der physische Node-Speicher erreicht ist, „kippt“ der Pod, verarbeitet keine Events mehr und die Last wandert zu einem anderen Worker
  2. Exakte CPU-Spikes alle drei Stunden
    • Ein einzelner Worker erreicht regelmäßig 100 % CPU
    • Das Muster wiederholt sich exakt alle 3 Stunden (z. B. 12:30, 15:30, 18:30)
    • Die Spikes führen zu spürbarer Instabilität im Cluster

Die zentrale Frage: Handelt es sich um einen Bug, ein Memory Leak oder um erwartbares Verhalten bestimmter Wazuh-Module?

Technische Analyse

1. Speicherwachstum in Kubernetes: Warum es hier stärker auffällt

In Wazuh-Clustern sind insbesondere folgende Komponenten speicherrelevant:

  • wazuh-clusterd
  • wazuh-db

Diese Prozesse halten Caches und interne Zustände, die unter Last anwachsen können. In klassischen Systemen fällt das oft nicht auf, da:

  • der Host ausreichend RAM hat
  • der Prozess nicht hart begrenzt wird

In Kubernetes dagegen bedeutet „kein Memory-Limit“:

  • Der Pod darf wachsen, bis der Node erschöpft ist
  • Es gibt keinen natürlichen „Deckel“, der den Prozess zur Speicherfreigabe zwingt
  • Erst sehr spät greift der OOM-Killer – oft zu spät für stabile Verarbeitung

Gerade bei älteren Versionen (z. B. 4.10) sind zudem bekannte Speicherprobleme in Teilen des Clusters und der DB-Kommunikation dokumentiert worden, die in späteren 4.14-Patches entschärft wurden.

2. Der 3-Stunden-CPU-Spike ist kein Zufall

Der exakt wiederkehrende 3-Stunden-Rhythmus ist ein starkes Indiz für periodische Wazuh-Module. Standardmäßig laufen mehrere rechenintensive Komponenten mit einem Intervall von 10.800 Sekunden (3 Stunden):

  • Syscheck (FIM)
    Führt Dateisystem-Scans durch, abhängig von:
    • Anzahl überwachten Dateien
    • gemounteten Volumes
    • Excludes / Realtime-Einstellungen
  • Rootcheck
    Prüft Systemkonfigurationen, Rootkits, verdächtige Dateien und Prozesse

In Kubernetes-Umgebungen mit:

  • großen Persistent Volumes
  • vielen Mounts
  • identischen Konfigurationen auf allen Workern

kann genau ein Worker diese Last „abbekommen“, was die beobachteten 100 %-Spikes erklärt.

Lösung / Best Practices

1. Ressourcen-Limits sind Pflicht, kein Optional

In Kubernetes-Deployments sollten Wazuh-Manager-Pods immer mit klaren Limits laufen:

  • Memory limits verhindern unkontrolliertes Wachstum und erzwingen frühzeitiges Recycling
  • CPU limits/requests stabilisieren die Scheduler-Entscheidungen

Best Practice:

  • konservative Limits definieren
  • bei Bedarf horizontal skalieren, statt einzelnen Pods unbegrenzten Speicher zu geben

2. Upgrade auf aktuelle 4.14-Releases

Mehrere Speicher- und Stabilitätsprobleme aus der 4.10-Serie wurden in neueren 4.14-Patches adressiert. Ein Upgrade reduziert:

  • langfristiges Memory-Creeping
  • DB-bedingte Speicherakkumulation
  • Cluster-Rebalancing-Effekte unter Last

3. Syscheck und Rootcheck gezielt tunen

Die 3-Stunden-Spikes lassen sich fast immer entschärfen:

  • Scan-Intervalle anpassen (nicht überall Default)
  • scan_time, scan_day oder ähnliche Optionen nutzen, um Last zu verteilen
  • Excludes für große oder irrelevante Verzeichnisse definieren
  • Realtime-FIM nur dort aktivieren, wo es fachlich notwendig ist

Ziel ist nicht, Syscheck/Rootcheck abzuschalten, sondern die Last gleichmäßig zu verteilen und unnötige Scans zu vermeiden.

4. Worker-Verteilung bewusst steuern

In Clustern mit mehreren Workern kann es sinnvoll sein:

  • nicht alle Worker identisch zu konfigurieren
  • bestimmte Module gezielt zu entlasten
  • CPU-Spikes zeitlich zu entzerren

Kubernetes macht Lastverschiebungen sichtbar – aber sie passieren nicht automatisch optimal.

Lessons Learned / Best Practices

  • Wazuh auf Kubernetes braucht explizite Ressourcensteuerung
  • „Kein Limit“ ist im Clusterbetrieb fast immer eine schlechte Idee
  • Exakt periodische Lastspitzen deuten fast immer auf geplante Module hin
  • Syscheck und Rootcheck sind mächtig – aber ohne Tuning teuer
  • Upgrades sind kein „Nice to have“, sondern Teil der Stabilitätsstrategie

Fazit
Die beobachteten Speicherprobleme und 3-Stunden-CPU-Spikes in Wazuh-Worker-Pods sind in Kubernetes-Umgebungen erklärbar und in vielen Fällen erwartbares Verhalten. Unbegrenzte Pods verstärken Speicherprobleme, während Standard-Scanintervalle von Syscheck und Rootcheck periodische Lastspitzen erzeugen. Die Kombination aus klaren Resource-Limits, Modul-Tuning und einem Upgrade auf aktuelle 4.14-Releases ist der nachhaltigste Weg zu einem stabilen Wazuh-Betrieb auf EKS – ohne Sicherheitsfunktionen zu opfern.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C07CCCCGHHP/p1767091030411829