Kapazitätsplanung¶

Kapazitätsplanung stellt sicher, dass die ayedo Software Delivery Plattform ausreichend Ressourcen für laufende Workloads bereitstellt und gleichzeitig Resilienz gegen Ausfälle und Kapazität für Rolling Updates gewährleistet.

Relevante Vorschriften¶

GDPR Art. 32¶

GDPR Artikel 32 fordert:

Die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen. [Hervorhebung hinzugefügt]

BSI IT-Grundschutz¶

APP.4.4.A18: Überwachung der Cluster-Ressourcen

Die Ressourcen des Clusters SOLLTEN kontinuierlich überwacht werden. Die Kapazitätsplanung SOLLTE sowohl für den Betrieb der Steuerungsebene als auch für die in den Pods betriebenen Anwendungen durchgeführt werden.

NIS2 Art. 21(2)¶

Anforderung an "Resilience of critical infrastructure" und "Business continuity".

Mapping zu Norm-Controls¶

ISO 27001 Annex A 8.6 Kapazitätsplanung¶

Die Nutzung von Ressourcen MUSS überwacht und abgestimmt werden, und Prognosen über den künftigen Kapazitätsbedarf MÜSSEN erstellt werden, um die erforderliche Systemleistung zur Erfüllung der Geschäftsziele sicherzustellen.

Implementierung in der ayedo SDP:

• ✅ Kontinuierliche Überwachung von CPU, Memory, Storage
• ✅ Automatisches Alerting bei Kapazitätsengpässen
• ✅ Grafana-Dashboards für Capacity Planning
• ✅ VictoriaMetrics für langfristige Trend-Analyse

Kubernetes Status Dashboard¶

Die ayedo SDP stellt ein Kubernetes Status Dashboard in Grafana bereit, das einen schnellen Überblick über den Cluster-Status bietet:

Dashboard-Inhalte:

• Unhealthy Pods: Pods, die nicht im Running-Status sind
• Unhealthy Nodes: Nodes mit Problemen
• Resource Requests vs. Allocatable: Verhältnis von angeforderten zu verfügbaren Ressourcen
• Pods ohne Resource Requests: Identifikation von Best-Practice-Verletzungen
• CPU & Memory Usage: Aktuelle Auslastung pro Node und Node Group
• Storage Usage: PersistentVolumes und Storage-Backend-Auslastung

Zugriff auf das Dashboard:

Das Dashboard ist über Grafana verfügbar und wird automatisch für alle Cluster der ayedo SDP bereitgestellt.

Resilienz-Modelle¶

Die ayedo SDP unterstützt zwei Resilienz-Modelle:

Node-Resilient¶

• Cluster ist ausgelegt, um einen Node-Ausfall pro Node Group zu verkraften
• Geeignet für On-Premises-Deployments ohne Multi-AZ
• Mindestens 3 Worker Nodes empfohlen

Zone-Resilient¶

• Cluster ist über drei Availability Zones verteilt
• Kann einen kompletten Zone-Ausfall verkraften
• Empfohlen für Public Cloud-Deployments (Loopback)
• Alle HA-Komponenten (Control Plane, Storage, etc.) sind über Zones verteilt

Upscaling¶

Wann skalieren?¶

Die ayedo SDP triggert automatisch Alerts in folgenden Situationen:

P1 Alert (Sofortiges Handeln erforderlich)¶

• CPU-Auslastung: Durchschnitt über 1 Stunde > 95%
• Memory-Auslastung: Durchschnitt über 1 Stunde > 85%

Aktion: Workload umverteilen oder Node Group upscalen

P2 Alert (Handlung innerhalb eines Arbeitstages)¶

• CPU oder Memory: Durchschnitt über 24 Stunden > 75%

Aktion: Kapazitätsplanung und proaktives Upscaling

Überwachte Metriken¶

Primäre Metriken:

• CPU Usage: Tatsächliche CPU-Nutzung der Nodes
• Memory Usage: Tatsächliche Memory-Nutzung der Nodes

Sekundäre Metriken (für weitere Analyse):

• CPU Requests zu CPU Allocatable Ratio
• Memory Requests zu Memory Allocatable Ratio
• Load Average
• Host Disk Usage
• PersistentVolumeClaim Usage
• Storage Backend Usage (Longhorn, Ceph)

Wie upscalen?¶

Option 1: Node hinzufügen

Fügen Sie einen neuen Node des gleichen Typs hinzu, wie die anderen Nodes in der Node Group.

Option 2: Konsolidierung zu größeren Nodes

Bei 6+ Nodes: Erwägen Sie Konsolidierung auf 3 Nodes mit doppelter Größe:

• Vorteile:
• Reduzierte Infrastruktur-Kosten
• Geringerer administrativer Aufwand

• Weniger Risk von Provider-Limits (z.B. max. 5 VMs per Anti-Affinity-Group)

• Wichtig: Koordination mit Anwendungsentwickler bzgl. Scheduling Constraints

Downscaling¶

Wann downscalen?¶

Kapazität sollte regelmäßig überprüft werden, z.B. nach Maintenance Windows.

Wie downscalen?¶

1. Node drainieren und cordon: kubectl drain <node> --ignore-daemonsets
2. Node aus Cluster entfernen
3. Infrastruktur dekommissionieren

Wichtig: Downscaling sollte nur periodisch erfolgen, während Upscaling sofort bei Bedarf durchgeführt werden sollte, um Oszillationen zu vermeiden.

Node Groups¶

Node Groups repräsentieren logische Gruppierungen von Nodes (z.B. worker, control-plane).

Labeling für Monitoring:

kubectl label node <node-name> ayedo.de/node-group=<node-group>

Diese Labels sind erforderlich, damit Monitoring und Alerting korrekt funktionieren.

Standard Node Groups:

• control-plane: Kubernetes Control Plane Nodes
• worker: Standard Worker Nodes
• worker-gpu: Worker Nodes mit GPU (optional)
• storage: Dedizierte Storage Nodes (optional)

Grafana Dashboards¶

Die ayedo SDP stellt mehrere Grafana-Dashboards bereit:

Kubernetes Status Dashboard¶

• Cluster-Übersicht
• Node Health
• Pod Health
• Resource Allocation

Node Capacity Dashboard¶

• CPU/Memory Usage pro Node
• CPU/Memory Usage pro Node Group
• Trend-Analyse über 7/30 Tage
• Capacity Planning Projections

Storage Capacity Dashboard¶

• PersistentVolume Usage
• Storage Backend Usage (Longhorn/Ceph)
• Storage Performance Metrics

Alerting¶

Automatische Benachrichtigungen via VictoriaMetrics Alerts:

Critical Alerts (P1)¶

• NodeCPUUsageHigh: CPU > 95% über 1h
• NodeMemoryUsageHigh: Memory > 85% über 1h
• NodeGroupCPUUsageHigh: Node Group CPU > 95% über 1h
• NodeGroupMemoryUsageHigh: Node Group Memory > 85% über 1h

Warning Alerts (P2)¶

• NodeGroupCPUUsageMedium: Node Group CPU > 75% über 24h
• NodeGroupMemoryUsageMedium: Node Group Memory > 75% über 24h
• PersistentVolumeUsageHigh: PV > 85%

Best Practices¶

Für Plattform Administratoren¶

1. Proaktiv skalieren: Upscaling bei P2 Alerts, nicht erst bei P1
2. Monitoring: Täglich Grafana-Dashboards überprüfen
3. Kapazitätsplanung: Monatliche Review-Meetings
4. Dokumentation: Upscaling/Downscaling-Entscheidungen dokumentieren

Für Anwendungsentwickler¶

1. Resource Requests definieren: Alle Pods müssen CPU/Memory Requests haben
2. Resource Limits setzen: Limits verhindern Resource Exhaustion
3. HPA nutzen: Horizontal Pod Autoscaler für variable Workloads
4. Rightsizing: Periodisch Requests/Limits anpassen

Compliance-Checkliste¶

• ✅ Kontinuierliche Ressourcen-Überwachung via VictoriaMetrics
• ✅ Grafana-Dashboards für Kapazitätsplanung
• ✅ Automatisches Alerting bei Kapazitätsengpässen
• ✅ Dokumentierte Prozesse für Up-/Downscaling
• ✅ Regelmäßige Kapazitätsplanung (monatlich)
• ✅ Resilienz gegen Node-/Zone-Ausfälle
• ✅ Node Groups mit korrekten Labels
• ✅ Resource Requests Enforcement via Kyverno Policies

Weitere Informationen¶

• VictoriaMetrics
• Grafana
• Kyverno Policies
• Platform Best Practices

Support¶

Bei Fragen zu Kapazitätsplanung:

• E-Mail: support@ayedo.de
• Website: ayedo.de