Tryb Server vs Task

#sympozium #agenty #server-mode

Dwa tryby wykonania

Task mode (default)

Kubernetes Job - run-to-completion
Pod istnieje tylko przez czas wykonania
Garbage collection po zakończeniu
Dla: one-shot tasks, scheduled runs, channel messages

Server mode

Kubernetes Deployment + Service
Pod żyje długo
Nie jest usuwany po "zakończeniu"
Dla: web endpoints, long-running services

Kiedy server mode?

Server mode aktywowany gdy:

AgentRun.spec.mode = "server" (jawnie ustawione)
SkillPack ma sidecar.requiresServer = true

Typowy use case: web-endpoint skill, który eksponuje agenta jako HTTP API.

Architektura server mode

SympoziumInstance z skill "web-endpoint"
    ↓
Instance Reconciler → tworzy AgentRun (mode: server)
    ↓
AgentRun Reconciler → reconcilePendingServer():
  1. Deployment (zamiast Job)
  2. Service (ClusterIP)
  3. HTTPRoute (Envoy Gateway, jeśli dostępny)
  4. Auto-generated API key (Secret)
    ↓
Web Proxy Sidecar:
  - /v1/chat/completions (OpenAI-compat)
  - /sse, /message (MCP protocol)
  - Rate limiting
  - Auth via API key

Przepływ request'u w server mode

HTTP Client → Gateway → HTTPRoute → Service → Web Proxy Pod
    ↓
Web Proxy tworzy per-request AgentRun (mode: task!)
    ↓
Normalny flow: Job → Agent → wynik → Web Proxy → HTTP Response

Kluczowe: web proxy sidecar sam działa w server mode, ale każdy request to osobny task-mode AgentRun - zachowujemy ephemeral model dla izolacji.

Reconciliation server mode

reconcileServing() (zamiast reconcileRunning):

Sprawdza Deployment health
Sprawdza Service health
Reconciliuje HTTPRoute
Requeue co 30 sekund

reconcileDelete() dla server mode:

Delete Deployment
Delete Service
Delete HTTPRoute
Delete API key Secret

Faza Serving

AgentRun phases:
  Pending → Serving (nie Running!)
  Serving (długo) → Succeeded (gdy usunięty)

Powiązane: Web Endpoints - OpenAI-compat API | Cykl życia AgentRun | Model efemerycznych agentów

2.1 KiB Raw Permalink Blame History