LoadBalancer¶
Ein LoadbalancerInstance (LBI) ist ein logischer HAProxy-LoadBalancer, der in Polycrate als Managed Object verwaltet wird. Er gehört zu Organisation und Workspace, erhält eine öffentliche IP aus dem IPAM und wird über Regionen multi-site deployt.
Das Deployment läuft über das Block-Rollout-System — nicht mehr über K8sApp als kritischen Pfad.
Was ein LBI kann¶
| Feature | Beschreibung |
|---|---|
| Dedizierte öffentliche IP | IPAM-Zuweisung; API-Feld ip_address_value (flach, kopierbar) |
| Mehrere Ports | Port-Mappings inkl. API-Feld wizard_ports (HAProxy-Config wird generiert) |
| Freie Config | Zusätzliches HAProxy-Fragment |
| Endpoints | Health-Probes; Detail-UI mit Endpoints-Tab |
| Metriken | Billing-relevante Traffic-Instant-Werte (30d); Charts on-demand |
| Multi-Region | Pro Region ein Deployment mit Block im Region-Workspace |
Architektur¶
LoadbalancerInstance (Org + Workspace)
│
├── ip_address → IPAM
├── ports / wizard_ports / config
│
└── Deployments (1..n)
└── LoadbalancerInstanceDeployment
├── region → Region (bzw. Legacy LoadbalancerRegion-Bridge)
├── block → Block im region.workspace (HAProxy)
└── rollout_item → BlockRolloutItem
Desired State vs. Rollout¶
- LBI-Reconciliation setzt Desired State (Block-Config, Labels, Checksums) und enqueued bei Drift
block.enqueue_action('install'). - BlockRollout-Scheduler (ca. 5s Tick) dispatcht die ActionRuns und schreibt nach Completion den deployed Checksum zurück.
- Soft-Delete:
DELETEstartet Cleanup/Uninstall über denselben Rollout-Pfad.
Legacy-Bridge
Ältere LoadbalancerRegion-Objekte bleiben während der Soft-Migration sichtbar und sind intern an das generische Region-Modell angebunden. Neue Deployments sollten über Region gedacht werden.
Conditions¶
| Condition | Severity | Bedeutung |
|---|---|---|
LOADBALANCER_NO_HEALTHY_DEPLOYMENTS | CRITICAL | Kein Region-Deployment installed/serving |
LOADBALANCER_DEPLOYMENTS_PENDING | WARNING | Checksum-Drift oder laufende Installs |
Checksum-Drift allein führt nicht zu CRITICAL, solange Deployments installed sind und Traffic bedienen. Details: Conditions.
Anlegen & Konfigurieren¶
- LoadBalancer → Neu (Organisation + Workspace)
- IP aus dem IPAM wählen (oder zuweisen lassen)
- Ports /
wizard_portssetzen — Config wird regeneriert - Ziel-Regionen wählen — Deployments und Blocks entstehen per Reconciliation
- Optional Endpoints anhängen
Neue Instanzen starten mit state=WARNING (Provisioning in progress), bis Reconciliation und Rollout state=OK und eine IP liefern.
Über die API: api/v1/loadbalancers/... (Basename loadbalancerinstance).
Metriken¶
Billing- und Listenmetriken kommen aus stündlichen Metrics-Beats (nicht aus dem 60s-Reconcile):
| Kennzahl | Bedeutung |
|---|---|
| 30d Traffic (in/out) | Instant-Aggregat für Abrechnung und UI |
Ältere 24h-Bandwidth-/Connection-Median-Felder wurden entfernt. Charts können weiterhin on-demand aus VictoriaMetrics geladen werden — siehe Metriken.
Endpoints für Health¶
Mindestens ein Endpoint (z. B. HTTPS auf die öffentliche IP) steuert Reachability und trägt zum Object-State bei. State-Updates aus Agent-Check-Ergebnissen können sofort greifen (Hot-Path), nicht erst am nächsten Reconcile-Tick.
HAProxy System-Defaults (ab API 0.32.0)¶
Die generierte Default-Config nutzt lange Client-/Server-/Tunnel-Timeouts, damit langlebige TCP-Verbindungen (SSH, DB, WebSockets) nicht nach einer Minute abreißen. Werte kommen aus SystemConfig und fallen bei ungültigen Angaben auf Code-Defaults zurück:
| Schlüssel | Default |
|---|---|
LOADBALANCER_HAPROXY_MAXCONN | 10000 |
LOADBALANCER_HAPROXY_TIMEOUT_CONNECT | 5s |
LOADBALANCER_HAPROXY_TIMEOUT_CLIENT | 24h |
LOADBALANCER_HAPROXY_TIMEOUT_SERVER | 24h |
LOADBALANCER_HAPROXY_TIMEOUT_TUNNEL | 24h |
Änderungen an diesen Keys erzeugen Config-Drift und lösen einen LBI-Rollout aus. Region- spezifische Workload-Settings (region_config.haproxy) bleiben separat.