Leitfaden zur Dimensionierung der Infrastruktur
Dieses Handbuch enthält Anleitungen zur Dimensionierung für die Bereitstellung von Codebeamer AI in AKS, einschließlich:
• Workload der primären Anwendung, cb-ai-service
• vollständige Observability-Stacks, OpenTelemetry Collector sowie Observability‑ und Monitoring-Tools. z. B. Prometheus, Grafana usw.
• AKS-Systemkomponenten
• Bereitstellungskapazität für Azure OpenAI-Modelle
 |
Tool-Namen wie Prometheus, Alertmanager, Grafana werden hier nur als Beispiele verwendet. Es kann jeder äquivalente Observability-Stack verwendet werden, ob verwaltet oder selbst gehostet. Dimensionierungen setzen einen repräsentativen Stack für die Kapazitätsplanung voraus. Passen Sie Werte basierend auf der ausgewählten Plattform an, z.B. Azure Monitor oder Datadog.
|
Bereich und Annahmen
Enthaltene Workloadtypen
|
Workload
|
Typ
|
Pool
|
|---|---|---|
|
cb-ai-service
|
Anwendung (Python)
|
Benutzer-Pool
|
|
Observability‑ und Monitoring-Tools
|
Observability (Traces und Telemetrie-Pipeline)
Monitoring (Metrikerfassung und Warnungen)
|
Benutzer-Pool
|
|
OpenTelemetry Collector
|
Benutzer-Pool
|
|
|
CoreDNS, kube-proxy, metrics-server
|
Kubernetes-Systemkomponenten
|
System-Pool
|
|
Azure Policy, OMS Agent, Defender, CSI-Treiber
|
Azure‑Sicherheits‑ und Compliance‑Agents
|
System-Pool
|
Checkliste für Dimensionierungs-Eingaben
Vor der Auswahl eines Dimensionierungs-Profils müssen folgende Informationen erfasst werden.
Datenverkehr und Parallelität
◦ Erwartete maximale Anzahl gleichzeitiger Benutzer
◦ Verhältnis Spitzenlast zu Durchschnittslast (typischerweise: 2–3‑mal so hoch)
Verfügbarkeit
◦ Ziel‑Uptime‑SLA (99,9 % empfohlen)
◦ Einstellungen für Wartungs‑ und Upgrade‑Zeitfenster
AKS-Architektur-Baseline
Knotenpools
|
Pool
|
Zweck
|
VM-Familie
|
Automatische Skalierung
|
|---|---|---|---|
|
System-Pool
|
Kubernetes-interne Komponenten und Azure-Agents
|
Dasv5-Serie (AMD, kostenoptimiert)
|
Ja (2–3 Knoten)
|
|
Benutzer-Pool
|
Anwendungs- und Observability-Workloads
|
Ja (3–12 Knoten)
|
Warum zwei Pools?
◦ Der System‑Pool führt von AKS verwaltete Pods aus (CoreDNS, Defender usw.) und ist von der Anwendungslast isoliert.
◦ Der Benutzerpool skaliert mit der Anwendungsnachfrage. Autoscaler fügt Knoten hinzu oder entfernt Knoten, wenn sich der Datenverkehr ändert.
◦ Der CriticalAddonsOnly-Taint verhindert, dass Anwendungs-Pods auf Systemknoten ausgeführt werden.
Dimensionierung von Profilen
|
Profil
|
Gleichzeitige Benutzer
|
|---|---|
|
Klein (S)
|
Bis zu 100
|
|
Mittel (M)
|
100–300
|
|
Groß (L)
|
300–700
|
Profilzusammenfassung
|
Parameter
|
Klein
|
Mittel
|
Groß
|
|---|---|---|---|
|
Benutzer-Pool-VM
|
Standard_D8as_v5 (8 vCPU / 32 GiB)
|
Standard_D8as_v5 (8 vCPU / 32 GiB)
|
Standard_D8as_v5 (8 vCPU / 32 GiB)
|
|
Min./Max. Knoten im Benutzer-Pool
|
3 / 6
|
3 / 10
|
3 / 12
|
|
System-Pool-VM
|
Standard_D2as_v5 (2 vCPU / 8 GiB)
|
Standard_D2as_v5 (2 vCPU / 8 GiB)
|
Standard_D2as_v5 (2 vCPU / 8 GiB)
|
|
Min./Max. Knoten für System-Pool
|
2 / 3
|
2 / 3
|
2 / 3
|
|
Gesamtzahl der App-Pod-Replikate
|
2-10
|
2-10
|
2-10
|
|
Prometheus‑/(oder vergleichbares Tool)‑Replikate
|
1
|
2 (HA)
|
2 (HA)
|
|
Grafana‑/(oder vergleichbares Tool)‑Replikate
|
1
|
1
|
2 (HA)
|
|
OpenTelemetry Collector‑Replikate
|
1
|
2
|
3
|
Workload‑Ressourcendimensionierung
cb-ai-service (Anwendung)
|
Klein
|
Mittel
|
Groß
|
|
|---|---|---|---|
|
CPU-Anforderung
|
500m (0,5 vCPU)
|
1000m (1 vCPU)
|
1500m (1,5 vCPU)
|
|
Speicheranforderung
|
1 GiB
|
1,5 GiB
|
3 GiB
|
|
HPA-Ziel-CPU
|
70 %
|
70 %
|
70 %
|
|
HPA-Min./Max.-Replikate
|
2 / 10
|
2 / 10
|
2 / 10
|
Prometheus-Server
|
|
Prometheus wird hier als Beispiel für eine Metriklösung herangezogen. Es kann jede äquivalente Metrik- und Warnungslösung verwendet werden (verwaltet oder selbst gehostet). Dimensionieren Sie CPU, Arbeitsspeicher und PVC basierend auf der Aufbewahrung und der Serienanzahl.
|
|
Klein
|
Mittel
|
Groß
|
|
|---|---|---|---|
|
Replikate
|
1
|
2 (HA)
|
2 (HA)
|
|
CPU-Anforderung
|
500m (0,5 vCPU)
|
1000m (1 vCPU)
|
2000m (2 vCPU)
|
|
Speicheranforderung
|
1 GiB
|
2 GiB
|
4 GiB
|
Speicher (PVC) und Aufbewahrung
Die PVC‑Größe und der Aufbewahrungszeitraum hängen vom Metrikvolumen und den Compliance‑Anforderungen der Bereitstellung ab.
Leitfaden zur Schätzung
|
Gleichzeitige Benutzer
|
Aktive Serien
|
Aufnahmerate
|
7 Tage PVC
|
15 Tage PVC
|
30 Tage PVC
|
|---|---|---|---|---|---|
|
~100 (Klein)
|
20–50k
|
~500 Samples/Sek.
|
~20 GiB
|
~40 GiB
|
~80 GiB
|
|
~300 (Mittel)
|
50–100k
|
~1.500 Samples/Sek.
|
~50 GiB
|
~100 GiB
|
~200 GiB
|
|
~700 (Groß)
|
100–200k
|
~3.000 Samples/Sek.
|
~100 GiB
|
~200 GiB
|
~400 GiB
|
Empfehlungen:
◦ Legen Sie die Aufbewahrung basierend auf Ihrer SLA für die Reaktion auf Vorfälle fest. 7 Tage sind für die meisten Entwicklungs- und Testumgebungen ausreichend. Die Produktionsumgebung benötigt in der Regel 15 bis 30 Tage.
◦ Stellen Sie das PVC stets 20 % größer bereit als die berechnete Schätzung, um Spitzen bei der Label‑Kardinalität abzufangen.
◦ Verwenden Sie für eine Aufbewahrung von mehr als 30 Tagen Remotespeicherlösungen wie von Azure Monitor verwaltete Prometheus-, Thanos- oder Cortex-Lösungen.
◦ Überwachen Sie die Prometheus‑Speichernutzung mit prometheus_tsdb_storage_size_bytes und konfigurieren Sie Warnungen bei 80 % PVC‑Auslastung.
Grafana
|
Klein
|
Mittel
|
Groß
|
|
|---|---|---|---|
|
Replikate
|
1
|
1
|
2 (HA)
|
|
CPU-Anforderung
|
100m (0,1 vCPU)
|
250m (0,25 vCPU)
|
500m (0,5 vCPU)
|
|
Speicheranforderung
|
128 Mi
|
256 Mi
|
512 Mi
|
|
PVC
|
5 GiB
|
10 GiB
|
10 GiB
|
Grafana ist im Leerlauf leicht, es kann jedoch während des gleichzeitigen Dashboard-Renderings zu CPU-Spitzen kommen. Verwenden Sie für eine hohe Verfügbarkeit in großem Umfang eine externe PostgreSQL-Datenbank anstelle von SQLite-gestützten persistenten Volumes.
OpenTelemetry-Sammler
|
Klein
|
Mittel
|
Groß
|
|
|---|---|---|---|
|
Modus
|
Bereitstellung (Gateway)
|
Bereitstellung (Gateway)
|
Bereitstellung (Gateway)
|
|
Replikate
|
1
|
2
|
3
|
|
CPU-Anforderung
|
250m (0,25 vCPU)
|
500m (0,5 vCPU)
|
1000m (1 vCPU)
|
|
Speicheranforderung
|
512 Mi
|
1 GiB
|
2 GiB
|
|
PVC
|
5 GiB
|
5 GiB
|
10 GiB
|
Add-ons für Monitoring
|
Komponente
|
CPU-Anforderung
|
Speicheranforderung
|
Typ
|
|---|---|---|---|
|
Node Exporter
|
50–100m pro Knoten
|
30–64 Mi pro Knoten
|
DaemonSet (wird auf jedem Benutzer-Pool-Knoten ausgeführt)
|
|
kube-state-metrics
|
50–200m
|
64–256 Mi
|
Einzelne Bereitstellung
|
AKS-Systemkomponenten
AKS‑Systemkomponenten werden im System-Pool ausgeführt und von Azure verwaltet. Der Systempool-Headroom für Standard_D2as_v5 = 2 vCPU/8 GiB ist wie folgt:
• Kubelet/OS-Reservierung: ~0,3 vCPU / 1 GiB
• System-Pods: ~1,2 vCPU / 2,5 GiB
• Verbleibend: ~0,5 vCPU / 4,5 GiB pro Knoten
• Mindestanzahl von 2 Knoten stellt ausreichende Kapazität bereit.
Berechnungen der Gesamtkapazität
Klein (~100 gleichzeitige Benutzer)
|
Workload
|
Min. Pods
|
Max. Pods
|
CPU-Anforderung (Min.)
|
CPU-Anforderung (Max.)
|
Speicheranforderung (Min.)
|
Speicheranforderung (Max.)
|
|---|---|---|---|---|---|---|
|
cb-ai-service
|
2
|
10
|
1000m (1 vCPU)
|
5000m (5 vCPU)
|
2 GiB
|
10 GiB
|
|
Prometheus
|
1
|
1
|
500m
|
500m
|
1 GiB
|
1 GiB
|
|
Alertmanager
|
1
|
1
|
50m
|
50m
|
64 MiB
|
64 MiB
|
|
Node Exporter (DaemonSet)
|
3
|
5
|
150m
|
250m
|
90 MiB
|
150 MiB
|
|
kube-state-metrics
|
1
|
1
|
50m
|
50m
|
64 MiB
|
64 MiB
|
|
Grafana
|
1
|
1
|
100m
|
100m
|
128 MiB
|
128 MiB
|
|
OpenTelemetry Collector
|
2
|
2
|
500m
|
500m
|
1 GiB
|
1 GiB
|
|
Zwischensumme
|
11
|
21
|
2.350m (~2,4 vCPU)
|
6.450m (~6,5 vCPU)
|
~4,3 GiB
|
~12,4 GiB
|
|
+ 25 % Reservekapazität
|
~3.000m (~3 vCPU)
|
~8.060m (~8,1 vCPU)
|
~5,4 GiB
|
~15,5 GiB
|
Knoten: 1–2 im Basisbetrieb, 2–3 bei Spitzenlast (Standard_D8as_v5: 8 vCPU, 32 GiB)
Mittel (~300 gleichzeitige Benutzer)
|
Workload
|
Min. Pods
|
Max. Pods
|
CPU-Anforderung (Min.)
|
CPU-Anforderung (Max.)
|
Speicheranforderung (Min.)
|
Speicheranforderung (Max.)
|
|---|---|---|---|---|---|---|
|
cb-ai-service
|
2
|
10
|
1000m (1 vCPU)
|
5000m (5 vCPU)
|
2 GiB
|
10 GiB
|
|
Prometheus
|
2 (HA)
|
2 (HA)
|
2000m (2 vCPU)
|
2000m (2 vCPU)
|
4 GiB
|
4 GiB
|
|
Alertmanager
|
2 (HA)
|
2 (HA)
|
100m
|
100m
|
128 MiB
|
128 MiB
|
|
Node Exporter (DaemonSet)
|
4
|
8
|
400m
|
800m
|
240 MiB
|
480 MiB
|
|
kube-state-metrics
|
1
|
1
|
100m
|
100m
|
128 MiB
|
128 MiB
|
|
Grafana
|
1
|
1
|
200m
|
200m
|
256 MiB
|
256 MiB
|
|
OpenTelemetry Collector
|
2
|
2
|
1000m (1 vCPU)
|
1000m (1 vCPU)
|
2 GiB
|
2 GiB
|
|
Zwischensumme
|
14
|
26
|
4.800m (~4,8 vCPU)
|
9.200m (~9,2 vCPU)
|
~8,7 GiB
|
~17 GiB
|
|
+ 25 % Reservekapazität
|
~6.000m (~6 vCPU)
|
~11.500m (~11,5 vCPU)
|
~10,9 GiB
|
~21,2 GiB
|
Knoten: 2 im Basisbetrieb, 3–4 bei Spitzenlast (Standard_D8as_v5: 8 vCPU, 32 GiB)
Groß (~700 gleichzeitige Benutzer)
|
Workload
|
Min. Pods
|
Max. Pods
|
CPU-Anforderung (Min.)
|
CPU-Anforderung (Max.)
|
Speicheranforderung (Min.)
|
Speicheranforderung (Max.)
|
|---|---|---|---|---|---|---|
|
cb-ai-service
|
2
|
10
|
1000m (1 vCPU)
|
5000m (5 vCPU)
|
2 GiB
|
10 GiB
|
|
Prometheus
|
2 (HA)
|
2 (HA)
|
4000m (4 vCPU)
|
4000m (4 vCPU)
|
8 GiB
|
8 GiB
|
|
Alertmanager
|
2 (HA)
|
2 (HA)
|
200m
|
200m
|
256 MiB
|
256 MiB
|
|
Node Exporter (DaemonSet)
|
6
|
12
|
600m
|
1200m
|
360 MiB
|
720 MiB
|
|
kube-state-metrics
|
1
|
1
|
200m
|
200m
|
256 MiB
|
256 MiB
|
|
Grafana
|
2
|
2
|
500m
|
500m
|
512 MiB
|
512 MiB
|
|
OpenTelemetry Collector
|
3
|
3
|
3000m (3 vCPU)
|
3000m (3 vCPU)
|
6 GiB
|
6 GiB
|
|
Zwischensumme
|
18
|
32
|
9.500m (~9,5 vCPU)
|
14.100m (~14,1 vCPU)
|
~17,3 GiB
|
~25,7 GiB
|
|
+ 25 % Reservekapazität
|
~11.875m (~11,9 vCPU)
|
~17.625m (~17,6 vCPU)
|
~21,7 GiB
|
~32,1 GiB
|
Knoten: 3 im Basisbetrieb, 6–8 bei Spitzenlast (Standard_D8as_v5: 8 vCPU, 32 GiB)
Strategie für automatische Skalierung
Der Ansatz der automatischen Skalierung sorgt dafür, dass die Anwendung ohne manuelle Optimierung reaktionsschnell und effizient bleibt.
• Cluster Autoscaler passt Knoten an, wenn Änderungen des Bedarfs geplant werden. Daher erhalten ausstehende Pods ihre Kapazität, und inaktive Knoten werden getrimmt.
• Der HPA (Horizontal Pod Autoscaler) passt die Anzahl der Pod‑Replikate automatisch anhand der Echtzeitlast an, um die Reaktionsfähigkeit des Dienstes sicherzustellen.
Implementierungszuordnung (Terraform)
Zuordnung von Variablen zu Dimensionierungsentscheidungen
|
Dimensionierungsentscheidung
|
Terraform-Variable
|
Datei
|
|---|---|---|
|
VM-Größe des Benutzer-Pools
|
aks_user_pool_vm_size
|
infra.tfvars
|
|
Minimale/maximale Knoten für Benutzer-Pool
|
aks_user_pool_min_count / aks_user_pool_max_count
|
infra.tfvars
|
|
VM-Größe des System-Pools
|
aks_system_pool_vm_size
|
infra.tfvars
|
|
Minimale/maximale Knoten für System-Pool
|
aks_system_pool_min_count / aks_system_pool_max_count
|
infra.tfvars
|
|
Kapazität des OpenAI-Modells (TPM)
|
openai_gpt5_mini_capacity / openai_gpt5_nano_capacity
|
infra.tfvars
|
|
OpenAI-Bereitstellungs-SKU
|
openai_gpt5_mini_sku_name / openai_gpt5_nano_sku_name
|
infra.tfvars
|
|
Maximale Pods pro Knoten
|
Hartcodiert auf 50
|
modules/aks/main.tf
|
SKU-Typen
|
SKU-Typ
|
Beispiele
|
Abrechnung
|
Anwendungsfall
|
|---|---|---|---|
|
Pay-as-you-go-Dienste
|
DataZoneStandard, GlobalStandard
|
Abrechnung pro Token
|
Entwicklung, variable Workloads
|
|
PTU
|
DataZoneProvisionedManaged, GlobalProvisionedManaged, ProvisionedManaged
|
Reservierte Kapazität
|
Produktion, vorhersehbare Workloads
|
Beispiel-Parametersätze
# ── Small (100 concurrent users) ─────────────────────
aks_user_pool_vm_size = "Standard_D8as_v5"
aks_user_pool_min_count = 3
aks_user_pool_max_count = 6
openai_gpt5_mini_capacity = 3000
openai_gpt5_nano_capacity = 3000
# ── Medium (300 concurrent users) ────────────────────
aks_user_pool_vm_size = "Standard_D8as_v5"
aks_user_pool_min_count = 3
aks_user_pool_max_count = 10
openai_gpt5_mini_capacity = 6000
openai_gpt5_nano_capacity = 6000
# ── Large (700 concurrent users) ─────────────────────
aks_user_pool_vm_size = "Standard_D8as_v5"
aks_user_pool_min_count = 3
aks_user_pool_max_count = 12
openai_gpt5_mini_capacity = 12000
openai_gpt5_nano_capacity = 12000
Empfehlung
Beginnen Sie mit der Schätzung der Anforderungen an Benutzerverkehr, Verfügbarkeit und Observability. Wählen Sie ein kleines, mittleres oder großes Profil aus und konfigurieren Sie Terraform-Variablen entsprechend. Beispiel: aks_user_pool_vm_size, aks_user_pool_min_count/max_count. Vermeiden Sie feste Zahlen und wählen Sie das Profil, das Ihren Anforderungen am besten entspricht.
Beginnen Sie mit dem kleinen Profil (100 gleichzeitige Benutzer). Es bietet:
• Produktionsreife Zuverlässigkeit – 3 Knoten, High Availability für kritische Komponenten, 25 % Reservekapazität.
• Wachstumspfad – Durch Ändern der erforderlichen Terraform-Variablen auf mittel oder groß skalieren.
Cluster skaliert automatisch innerhalb des gewählten Minimums und Maximums. Beginnen Sie mit einem Profil, das Ihren Bedürfnissen entspricht, und passen Sie min_count und max_count im Laufe der Zeit an. Eine erneute Bereitstellung ist nicht erforderlich.
Einschränkungen und Grenzen konfigurierbarer Einstellungen
|
Thema
|
Link zur offiziellen Dokumentation
|
|---|---|
|
Azure OpenAI-Kontingente und -Grenzwerte
|
|
|
AKS-Dienstkontingente und -Grenzwerte
|
|
|
Azure-Abonnement- und Dienstgrenzwerte (Master-Liste)
|
|
|
Azure Cognitive Services-Grenzwerte
|
|
|
AKS-Knotenpool-Beschränkungen
|
Berechnung von Durchsatzeinheiten (PTUs) basierend auf dem Token-Verbrauch
|
Thema
|
Link zur offiziellen Dokumentation
|
|---|---|
|
PTU Übersicht und Dimensionierung
|
|
|
PTU-Rechner (Kapazitätsplanung)
|
|
|
Informationen zur PTU-Zuweisung
|
|
|
Erste Schritte mit PTUs
|
|
|
Überwachung der PTU-Auslastung
|
Zusammenfassung der PTU-Berechnung aus der Microsoft-Dokumentation
1. Erfassen Sie Ihre Workloadmetriken.
▪ Durchschnittliche Anzahl an Eingabe‑Tokens pro Anfrage
▪ Durchschnittliche Anzahl an Ausgabe‑Tokens pro Anfrage
▪ Anforderungen pro Minute (RPM) zur Spitzenzeit
2. Verwenden Sie den Azure PTU-Rechner.
▪ Gehen Sie zu: https://oai.azure.com/portal/calculator
▪ Wählen Sie Ihr Modell aus (z.B. gpt-5-mini).
▪ Geben Sie Ihre Workloadmerkmale ein.
▪ Der Rechner ermittelt die empfohlene PTU‑Anzahl.
3. Validieren Sie die Werte durch Monitoring.
▪ Überwachen Sie nach der Bereitstellung die Metrik ProvisionedManagedUtilizationV2.
▪ Liegt die Auslastung dauerhaft bei > 80 %, erhöhen Sie die PTU oder aktivieren Sie Spillover.
▪ Liegt die Auslastung unter < 30 %, ziehen Sie in Betracht, die PTU zu reduzieren oder zu Pay-as-you-go-Diensten zu wechseln.
Auszug aus der Microsoft-Dokumentation: "Provisioned Throughput Units (PTU) sind generische Einheiten der Modellverarbeitungskapazität, die Sie verwenden, um bereitgestellte Bereitstellungen so zu dimensionieren, dass der erforderliche Durchsatz für Verarbeitungsaufforderungen und Generierungen von Abschlüssen erreicht wird." Weitere Informationen dazu finden Sie unter Was ist der bereitgestellte Durchsatz für Foundry-Modelle?.