Compute Resources

Strategien für das Ressourcen-Management (CPU, Memory, Speicher).

CPU: Requests vs. Limits

Hier herrscht oft Verwirrung. Eine Klärung der technischen Hintergründe:

• CPU Requests: Setzt cpu.shares. Das ist eine relative Gewichtung. Dient dem Scheduler primär zur Platzierung des Pods. Es ist eine "weiche" Garantie.
• CPU Limits: Setzt cpu.cfs_quota_us. Dies ist ein hartes Limit. Wird es überschritten, drosselt der Kernel den Prozess (Throttling).

Verständnis-Tipp: Das Setzen von CPU Limits führt oft zu unnötigem Throttling, selbst wenn der Node freie Kapazitäten hat. Empfehlung: In vielen Fällen ist es performanter, keine CPU Limits zu setzen (oder diese sehr hoch zu wählen) und sich primär auf korrekte Requests zu verlassen.

Node Kapazitäten

Jeder Node reserviert einen Teil seiner Ressourcen für das System (OS, Kubelet).

• Capacity: Physisch vorhandene Ressourcen.
• Allocatable: Für Pods verfügbare Ressourcen.

System Reservierungen

Natron folgt bewährten Standards (ähnlich AKS/OpenShift) für System-Reservierungen:

• cpu: ca. "150m"
• memory: ca. "300Mi"

Storage & Eviction

Dateisysteme

Das Kubelet unterscheidet zwei Speicherbereiche für die Garbage Collection:

• nodefs: /var/lib/kubelet/ (Logs, lokales Volume-Daten).
• imagefs: /var/lib/containerd/ (Container-Images, Writable Layer).

Eviction Schwellwerte

Pods werden gestoppt (evicted), wenn der Platz knapp wird:

• memory.available < 100Mi
• nodefs.available < 10%
• imagefs.available < 15%

Ephemeral Storage

Die lokale Root-Disk des Nodes (meist 10-20GiB, je nach Flavor) wird als "Ephemeral Storage" genutzt.

Achtung: Wenn Ihre Applikation viel temporären Platz benötigt (Scratch Space), füllt sie schnell die Node-Disk und riskiert eine Eviction.

Lösung: Generic Ephemeral Volumes Nutzen Sie statt emptyDir (welches auf der Root-Disk liegt) besser Generic Ephemeral Volumes. Diese binden dynamisch ein PVC als Scratch-Space ein, das vom Lifecycle an den Pod gebunden ist.

volumes:
  - name: scratch-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: "scratch-storage-class"
          resources:
            requests:
              storage: 1Gi

MaxPods

Die Obergrenze liegt standardmässig bei 110 Pods pro Node.