LoadBalancer

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

  1. LBI-Reconciliation setzt Desired State (Block-Config, Labels, Checksums) und enqueued bei Drift block.enqueue_action('install').
  2. BlockRollout-Scheduler (ca. 5s Tick) dispatcht die ActionRuns und schreibt nach Completion den deployed Checksum zurück.
  3. Soft-Delete: DELETE startet Cleanup/Uninstall über denselben Rollout-Pfad.

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

  1. LoadBalancer → Neu (Organisation + Workspace)
  2. IP aus dem IPAM wählen (oder zuweisen lassen)
  3. Ports / wizard_ports setzen — Config wird regeneriert
  4. Ziel-Regionen wählen — Deployments und Blocks entstehen per Reconciliation
  5. 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.

Verwandte Themen