initial commit
This commit is contained in:
77
08-Słownik-K8s/Admission Webhook.md
Normal file
77
08-Słownik-K8s/Admission Webhook.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# Admission Webhook
|
||||
|
||||
#kubernetes #security #api #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Admission Webhook** to mechanizm Kubernetes pozwalający na **przechwycenie i walidację/modyfikację żądań do API servera** zanim zasób zostanie zapisany w etcd.
|
||||
|
||||
## Typy
|
||||
|
||||
### Validating Admission Webhook
|
||||
- **Sprawdza** czy żądanie jest prawidłowe
|
||||
- Może ALLOW lub DENY
|
||||
- Nie modyfikuje żądania
|
||||
- Przykład: "Czy AgentRun spełnia SympoziumPolicy?"
|
||||
|
||||
### Mutating Admission Webhook
|
||||
- **Modyfikuje** żądanie przed walidacją
|
||||
- Może dodawać, usuwać lub zmieniać pola
|
||||
- Przykład: "Dodaj domyślny SecurityContext do poda"
|
||||
|
||||
## Przepływ
|
||||
|
||||
```
|
||||
kubectl apply -f agentrun.yaml
|
||||
↓
|
||||
API Server:
|
||||
1. Authentication (kto?)
|
||||
2. Authorization / RBAC (czy może?)
|
||||
3. → Mutating Webhooks (modyfikacja)
|
||||
4. Schema Validation (OpenAPI)
|
||||
5. → Validating Webhooks (walidacja)
|
||||
6. Zapis do etcd
|
||||
```
|
||||
|
||||
## Kluczowe cechy
|
||||
|
||||
- **Synchroniczne** - żądanie czeka na odpowiedź webhooka
|
||||
- **Fail-open / fail-closed** - konfiguracja co robić gdy webhook jest niedostępny
|
||||
- **TLS required** - webhook musi serwować HTTPS (cert-manager w Sympozium)
|
||||
- **Scope** - filtrowanie po zasobach, operacjach, namespace'ach
|
||||
|
||||
## Przykład konfiguracji
|
||||
|
||||
```yaml
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingWebhookConfiguration
|
||||
metadata:
|
||||
name: sympozium-webhook
|
||||
webhooks:
|
||||
- name: validate.sympozium.ai
|
||||
rules:
|
||||
- apiGroups: ["sympozium.ai"]
|
||||
resources: ["agentruns"]
|
||||
operations: ["CREATE", "UPDATE"]
|
||||
clientConfig:
|
||||
service:
|
||||
name: sympozium-webhook
|
||||
namespace: sympozium-system
|
||||
path: /validate-agent-pods
|
||||
failurePolicy: Fail # Odrzuć jeśli webhook niedostępny
|
||||
```
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium używa admission webhook do enforcowania [[SympoziumPolicy]]:
|
||||
|
||||
- Sprawdza czy [[AgentRun]] spełnia politykę bezpieczeństwa
|
||||
- Waliduje tool gating (allow/deny per tool)
|
||||
- Enforces sandbox requirements
|
||||
- Sprawdza limity sub-agentów
|
||||
|
||||
Enforcement odbywa się **at admission time** (przed tworzeniem poda), nie at runtime. Więcej w [[Admission Webhooks i polityki]].
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Admission Webhooks i polityki]] | [[SympoziumPolicy]] | [[CRD - Custom Resource Definition]]
|
||||
87
08-Słownik-K8s/CRD - Custom Resource Definition.md
Normal file
87
08-Słownik-K8s/CRD - Custom Resource Definition.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# CRD - Custom Resource Definition
|
||||
|
||||
#kubernetes #api #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Custom Resource Definition (CRD)** to mechanizm Kubernetes pozwalający na **rozszerzenie API klastra o własne typy zasobów**. Po zainstalowaniu CRD, nowy typ zasobu jest traktowany przez API server identycznie jak wbudowane zasoby (Pod, Service, Deployment).
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
1. Instalacja CRD YAML → K8s API Server rejestruje nowy typ
|
||||
2. Użytkownik tworzy instancję → Zapisana w etcd jak każdy zasób
|
||||
3. Controller obserwuje → Reconciliuje desired state → actual state
|
||||
```
|
||||
|
||||
## Przykład
|
||||
|
||||
```yaml
|
||||
# Definicja CRD
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
metadata:
|
||||
name: agentruns.sympozium.ai
|
||||
spec:
|
||||
group: sympozium.ai
|
||||
versions:
|
||||
- name: v1alpha1
|
||||
served: true
|
||||
storage: true
|
||||
scope: Namespaced
|
||||
names:
|
||||
plural: agentruns
|
||||
singular: agentrun
|
||||
kind: AgentRun
|
||||
```
|
||||
|
||||
```yaml
|
||||
# Instancja CRD (Custom Resource / CR)
|
||||
apiVersion: sympozium.ai/v1alpha1
|
||||
kind: AgentRun
|
||||
metadata:
|
||||
name: my-run
|
||||
spec:
|
||||
task: "Check cluster health"
|
||||
```
|
||||
|
||||
## Kluczowe koncepty
|
||||
|
||||
| Koncept | Opis |
|
||||
|---------|------|
|
||||
| **CRD** | Definicja typu (schemat) |
|
||||
| **CR** (Custom Resource) | Instancja danego typu |
|
||||
| **Controller** | Kod obserwujący CR i realizujący intent |
|
||||
| **Operator** | Controller + CRD + logika domenowa |
|
||||
| **Status subresource** | Oddzielny endpoint do aktualizacji statusu |
|
||||
| **Finalizer** | Blokuje usunięcie do czasu cleanup |
|
||||
| **Validation** | Schema validation (OpenAPI v3) lub webhook |
|
||||
|
||||
## Dlaczego CRD a nie ConfigMap?
|
||||
|
||||
| CRD | ConfigMap |
|
||||
|-----|-----------|
|
||||
| Typowane, walidowane | Dowolne dane |
|
||||
| Status subresource | Brak statusu |
|
||||
| kubectl native (`kubectl get agentruns`) | Wymaga custom tooling |
|
||||
| RBAC per-resource | RBAC per-configmap |
|
||||
| Watch API (event-driven) | Polling |
|
||||
| ownerReferences (GC) | Manualne zarządzanie |
|
||||
|
||||
## CRD w Sympozium
|
||||
|
||||
Sympozium definiuje **7 CRDs** (API group: `sympozium.ai/v1alpha1`):
|
||||
|
||||
| CRD | Opis |
|
||||
|-----|------|
|
||||
| [[SympoziumInstance]] | Tożsamość agenta / tenant |
|
||||
| [[AgentRun]] | Pojedyncze wywołanie agenta |
|
||||
| [[PersonaPack]] | Bundle pre-konfigurowanych agentów |
|
||||
| [[SkillPack]] | Portable skills (Markdown + sidecar) |
|
||||
| [[SympoziumPolicy]] | Polityki governance |
|
||||
| [[SympoziumSchedule]] | Cron-based recurring tasks |
|
||||
| [[MCPServer]] | External MCP tool providers |
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Controller i Reconciler]] | [[Finalizer]] | [[ownerReference]]
|
||||
82
08-Słownik-K8s/ConfigMap i Secret.md
Normal file
82
08-Słownik-K8s/ConfigMap i Secret.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# ConfigMap i Secret
|
||||
|
||||
#kubernetes #storage #słownik
|
||||
|
||||
## ConfigMap
|
||||
|
||||
**ConfigMap** przechowuje **niekonfidencjalne dane** jako pary klucz-wartość. Montowane jako pliki lub zmienne środowiskowe w podach.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: my-agent-memory
|
||||
data:
|
||||
MEMORY.md: |
|
||||
# Agent Memory
|
||||
- Detected OOM on pod-x
|
||||
```
|
||||
|
||||
### Montowanie jako pliki
|
||||
```yaml
|
||||
volumes:
|
||||
- name: skills
|
||||
configMap:
|
||||
name: skillpack-k8s-ops
|
||||
volumeMounts:
|
||||
- name: skills
|
||||
mountPath: /skills
|
||||
readOnly: true
|
||||
```
|
||||
|
||||
### Ograniczenia
|
||||
- Max rozmiar: **1 MB** (etcd limit)
|
||||
- Brak szyfrowania
|
||||
- Widoczne w kubectl describe
|
||||
|
||||
## Secret
|
||||
|
||||
**Secret** przechowuje **poufne dane** (hasła, tokeny, klucze) zakodowane w base64.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: openai-key
|
||||
type: Opaque
|
||||
data:
|
||||
OPENAI_API_KEY: c2stYWJjMTIz # base64 encoded
|
||||
```
|
||||
|
||||
### Montowanie jako env vars
|
||||
```yaml
|
||||
envFrom:
|
||||
- secretRef:
|
||||
name: openai-key
|
||||
```
|
||||
|
||||
### Typy Secrets
|
||||
| Typ | Opis |
|
||||
|-----|------|
|
||||
| `Opaque` | Dowolne dane |
|
||||
| `kubernetes.io/tls` | Certyfikaty TLS |
|
||||
| `kubernetes.io/dockerconfigjson` | Docker registry credentials |
|
||||
| `kubernetes.io/service-account-token` | Token SA |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
### ConfigMaps
|
||||
- **Skills** - SkillPack → ConfigMap z Markdown instrukcjami, montowany w `/skills/`
|
||||
- **Memory** (legacy) - `<instance>-memory` z kluczem `MEMORY.md`
|
||||
- **Input** - Task + system prompt dla agenta
|
||||
- **MCP config** - Konfiguracja MCP serwerów
|
||||
|
||||
### Secrets
|
||||
- **AuthRefs** - Klucze API providerów LLM (OPENAI_API_KEY, ANTHROPIC_API_KEY)
|
||||
- **Channel credentials** - Telegram bot token, Slack token
|
||||
- **Web endpoint API key** - Auto-generated `sk-<hex>`
|
||||
- **Skill secrets** - GH_TOKEN dla github-gitops (mirrored do namespace runu)
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[SkillPack]] | [[Persistent Memory]] | [[SympoziumInstance]]
|
||||
79
08-Słownik-K8s/Controller i Reconciler.md
Normal file
79
08-Słownik-K8s/Controller i Reconciler.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Controller i Reconciler
|
||||
|
||||
#kubernetes #architecture #operator #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Controller** to pętla kontrolna w Kubernetes obserwująca stan zasobów i **doprowadzająca rzeczywisty stan do pożądanego** (desired state → actual state). **Reconciler** to funkcja wywoływana gdy stan zasobu zmienia się.
|
||||
|
||||
## Wzorzec reconciliation
|
||||
|
||||
```
|
||||
Desired state (CRD spec) → Controller → Actual state (K8s resources)
|
||||
|
||||
Pętla:
|
||||
1. Observe: Watch API server for changes
|
||||
2. Diff: Compare desired vs actual
|
||||
3. Act: Create/update/delete resources
|
||||
4. Repeat
|
||||
```
|
||||
|
||||
## Kluczowe koncepty
|
||||
|
||||
| Koncept | Opis |
|
||||
|---------|------|
|
||||
| **Watch** | Subskrypcja na eventy (create/update/delete) |
|
||||
| **Work queue** | Kolejka zasobów do reconciliation |
|
||||
| **Reconcile()** | Funkcja wywoływana per zasób |
|
||||
| **Requeue** | "Sprawdź mnie ponownie za N sekund" |
|
||||
| **Idempotent** | Reconcile() musi być bezpieczne do wielokrotnego wywołania |
|
||||
| **Level-triggered** | Reaguje na **stan**, nie na **event** |
|
||||
|
||||
## Level-triggered vs edge-triggered
|
||||
|
||||
```
|
||||
Edge-triggered: "Coś się zmieniło!" → reaguj na zmianę
|
||||
Level-triggered: "Jaki jest aktualny stan?" → doprowadź do desired
|
||||
|
||||
Kubernetes Controllers = LEVEL-TRIGGERED
|
||||
→ Nie ważne CO się zmieniło
|
||||
→ Ważne JAKI jest stan i JAKI powinien być
|
||||
→ Resilient na missed events
|
||||
```
|
||||
|
||||
## controller-runtime
|
||||
|
||||
Sympozium używa `sigs.k8s.io/controller-runtime` - framework Go dla Kubernetes controllers:
|
||||
|
||||
```go
|
||||
type AgentRunReconciler struct {
|
||||
client.Client
|
||||
Scheme *runtime.Scheme
|
||||
Log logr.Logger
|
||||
}
|
||||
|
||||
func (r *AgentRunReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
|
||||
// 1. Fetch resource
|
||||
// 2. Compare desired vs actual
|
||||
// 3. Create/update/delete
|
||||
// 4. Update status
|
||||
return ctrl.Result{RequeueAfter: 10 * time.Second}, nil
|
||||
}
|
||||
```
|
||||
|
||||
## Controllers w Sympozium
|
||||
|
||||
| Controller | Zasób | Co reconciliuje |
|
||||
|------------|-------|-----------------|
|
||||
| AgentRunReconciler | [[AgentRun]] | [[Job]]/Sandbox CR, RBAC, ConfigMaps |
|
||||
| SympoziumInstanceReconciler | [[SympoziumInstance]] | Channel [[Deployment|Deployments]], memory |
|
||||
| PersonaPackReconciler | [[PersonaPack]] | Instances, Schedules, memory |
|
||||
| SkillPackReconciler | [[SkillPack]] | ConfigMaps ze skills |
|
||||
| SympoziumScheduleReconciler | [[SympoziumSchedule]] | AgentRun na schedule |
|
||||
| MCPServerReconciler | [[MCPServer]] | Deployments, Services |
|
||||
|
||||
Więcej: [[Control Plane]] | [[Cykl życia AgentRun]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[CRD - Custom Resource Definition]] | [[Control Plane]] | [[Finalizer]]
|
||||
39
08-Słownik-K8s/DaemonSet.md
Normal file
39
08-Słownik-K8s/DaemonSet.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# DaemonSet
|
||||
|
||||
#kubernetes #workload #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**DaemonSet** zapewnia że **jeden pod działa na każdym (lub wybranych) nodzie** klastra. Gdy nowy node jest dodany, DaemonSet automatycznie deployuje na nim pod.
|
||||
|
||||
## Use cases
|
||||
|
||||
| Use case | Przykład |
|
||||
|----------|---------|
|
||||
| Log collection | Fluentd, Filebeat |
|
||||
| Monitoring | Node Exporter, Datadog Agent |
|
||||
| Storage | Ceph, GlusterFS |
|
||||
| Networking | Calico, Cilium |
|
||||
| **Inference discovery** | Sympozium Node Probe |
|
||||
|
||||
## Różnica vs Deployment
|
||||
|
||||
| | DaemonSet | [[Deployment]] |
|
||||
|---|-----------|------------|
|
||||
| Repliki | 1 per node (auto) | N (zdefiniowane) |
|
||||
| Scheduling | Gwarantowany per node | Scheduler decyduje |
|
||||
| Scaling | Dodanie/usunięcie node'a | Zmiana replica count |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
**Node Probe DaemonSet** (`cmd/node-probe/`):
|
||||
- Jeden pod na każdym nodzie
|
||||
- Probeuje localhost porty (Ollama :11434, vLLM :8000, etc.)
|
||||
- Annotuje node z odkrytymi inference providers
|
||||
- API Server czyta annotacje → TUI/Web UI pokazuje
|
||||
|
||||
Więcej: [[Node Probe - odkrywanie inferencji]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Node Probe - odkrywanie inferencji]] | [[Deployment]] | [[Pod]]
|
||||
47
08-Słownik-K8s/Deployment.md
Normal file
47
08-Słownik-K8s/Deployment.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Deployment
|
||||
|
||||
#kubernetes #workload #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Deployment** to zasób Kubernetes zarządzający **zestawem identycznych podów** (ReplicaSet). Zapewnia deklaratywne aktualizacje, rollback, skalowanie i self-healing.
|
||||
|
||||
## Kluczowe cechy
|
||||
|
||||
| Cecha | Opis |
|
||||
|-------|------|
|
||||
| **Replicas** | Ilość identycznych podów |
|
||||
| **Rolling update** | Stopniowa wymiana podów na nowe |
|
||||
| **Rollback** | Powrót do poprzedniej wersji |
|
||||
| **Self-healing** | Restart crashed podów |
|
||||
| **Scaling** | Zmiana ilości replik (ręczna lub HPA) |
|
||||
|
||||
## Deployment vs Job
|
||||
|
||||
| | [[Job]] | Deployment |
|
||||
|---|---------|------------|
|
||||
| Lifecycle | Run-to-completion | Long-running |
|
||||
| Restart | Never/OnFailure | Always |
|
||||
| Replicas | Completions | Desired count |
|
||||
| Use case | Batch, one-shot | Services |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Deployments są używane dla **długo żyjących komponentów**:
|
||||
|
||||
| Komponent | Repliki | Opis |
|
||||
|-----------|---------|------|
|
||||
| Channel pods | 1 per kanał | Telegram, Slack, Discord, WhatsApp |
|
||||
| Memory server | 1 per instance | SQLite + FTS5 na PVC |
|
||||
| Web proxy | 1 per instance | OpenAI-compat API (server mode) |
|
||||
| Controller | 1 | Reconciler CRDs |
|
||||
| API Server | 1 | HTTP + WebSocket |
|
||||
| NATS | 1 (StatefulSet) | Event bus |
|
||||
|
||||
[[AgentRun]] w **trybie server** tworzy Deployment + Service zamiast Job.
|
||||
|
||||
Więcej: [[Tryb Server vs Task]] | [[Kanały - Telegram Slack Discord WhatsApp]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Job]] | [[StatefulSet]] | [[Pod]] | [[Tryb Server vs Task]]
|
||||
64
08-Słownik-K8s/Finalizer.md
Normal file
64
08-Słownik-K8s/Finalizer.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Finalizer
|
||||
|
||||
#kubernetes #lifecycle #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Finalizer** to mechanizm Kubernetes **blokujący usunięcie zasobu** do czasu wykonania cleanup. Dopóki finalizer istnieje na zasobie, K8s nie usunie go z etcd.
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
1. Zasób ma finalizer: ["sympozium.ai/finalizer"]
|
||||
2. kubectl delete → DeletionTimestamp ustawiony, ale zasób ISTNIEJE
|
||||
3. Controller widzi DeletionTimestamp → wykonuje cleanup
|
||||
4. Controller usuwa finalizer z listy
|
||||
5. K8s widzi brak finalizerów → zasób usunięty z etcd
|
||||
```
|
||||
|
||||
## Bez vs z finalizer
|
||||
|
||||
```
|
||||
Bez finalizer:
|
||||
kubectl delete agentrun → NATYCHMIAST usunięty
|
||||
→ Orphaned Jobs, RBAC, ConfigMaps!
|
||||
|
||||
Z finalizer:
|
||||
kubectl delete agentrun → DeletionTimestamp set
|
||||
→ Controller: cleanup Jobs, RBAC, ConfigMaps
|
||||
→ Controller: remove finalizer
|
||||
→ Zasób usunięty
|
||||
```
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
### AgentRun finalizer
|
||||
```go
|
||||
const agentRunFinalizer = "sympozium.ai/agentrun-finalizer"
|
||||
```
|
||||
|
||||
Cleanup przy usunięciu:
|
||||
- Delete Job/Sandbox CR
|
||||
- Delete ephemeral RBAC (ClusterRole, ClusterRoleBinding)
|
||||
- Delete input ConfigMap
|
||||
- Delete MCP ConfigMap
|
||||
|
||||
### SympoziumInstance finalizer
|
||||
```go
|
||||
const sympoziumInstanceFinalizer = "sympozium.ai/finalizer"
|
||||
```
|
||||
|
||||
Cleanup:
|
||||
- Delete channel Deployments
|
||||
- Delete memory ConfigMap
|
||||
- Delete memory Deployment/Service
|
||||
|
||||
## Pułapki
|
||||
|
||||
- Jeśli controller jest niedostępny → finalizer blokuje usunięcie na zawsze
|
||||
- "Stuck" zasoby: trzeba ręcznie usunąć finalizer (`kubectl edit`)
|
||||
- Finalizer dodawany tylko dla non-terminal runs (nie dla Succeeded/Failed)
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Controller i Reconciler]] | [[ownerReference]] | [[Cykl życia AgentRun]]
|
||||
74
08-Słownik-K8s/Helm Chart.md
Normal file
74
08-Słownik-K8s/Helm Chart.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Helm Chart
|
||||
|
||||
#kubernetes #deployment #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Helm** to package manager dla Kubernetes. **Helm Chart** to paczka szablonów Kubernetes YAML z parametryzacją (values).
|
||||
|
||||
## Analogia
|
||||
|
||||
```
|
||||
apt install nginx → helm install sympozium sympozium/sympozium
|
||||
apt-get update → helm repo update
|
||||
dpkg -l → helm list
|
||||
```
|
||||
|
||||
## Struktura
|
||||
|
||||
```
|
||||
charts/sympozium/
|
||||
├── Chart.yaml # Metadata (nazwa, wersja)
|
||||
├── values.yaml # Domyślne parametry
|
||||
├── templates/ # Szablony K8s YAML
|
||||
│ ├── deployment.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── configmap.yaml
|
||||
│ └── ...
|
||||
└── charts/ # Sub-charts (zależności)
|
||||
```
|
||||
|
||||
## values.yaml
|
||||
|
||||
```yaml
|
||||
# Przykładowe parametry
|
||||
controller:
|
||||
replicas: 1
|
||||
image:
|
||||
repository: ghcr.io/sympozium-ai/sympozium/controller
|
||||
tag: v0.0.25
|
||||
resources:
|
||||
requests:
|
||||
cpu: 250m
|
||||
memory: 512Mi
|
||||
|
||||
agentSandbox:
|
||||
enabled: true
|
||||
defaultRuntimeClass: gvisor
|
||||
|
||||
observability:
|
||||
enabled: true
|
||||
otlpEndpoint: "otel-collector:4317"
|
||||
```
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium instalowane via Helm:
|
||||
```bash
|
||||
helm repo add sympozium https://deploy.sympozium.ai/charts
|
||||
helm install sympozium sympozium/sympozium
|
||||
```
|
||||
|
||||
Chart zawiera:
|
||||
- Controller Manager [[Deployment]]
|
||||
- API Server Deployment
|
||||
- Webhook Deployment + cert-manager integration
|
||||
- NATS [[StatefulSet]]
|
||||
- [[CRD - Custom Resource Definition|CRD]] manifests
|
||||
- [[RBAC]] (ClusterRole, bindings)
|
||||
- [[NetworkPolicy]] templates
|
||||
- Built-in [[PersonaPack|PersonaPacks]] i [[SkillPack|SkillPacks]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Struktura repozytorium]] | [[CRD - Custom Resource Definition]] | [[Control Plane]]
|
||||
71
08-Słownik-K8s/Job.md
Normal file
71
08-Słownik-K8s/Job.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Job (Kubernetes)
|
||||
|
||||
#kubernetes #workload #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Job** to zasób Kubernetes tworzący **pod który wykonuje zadanie i kończy się**. W odróżnieniu od [[Deployment]] (pody działają ciągle), Job tworzy pod który ma zakończyć się sukcesem.
|
||||
|
||||
## Zachowanie
|
||||
|
||||
```
|
||||
Job created → Pod created → Pod runs → Pod completes (exit code 0) → Job Succeeded
|
||||
→ Pod fails (exit code != 0) → Job retries or Failed
|
||||
```
|
||||
|
||||
## Kluczowe cechy
|
||||
|
||||
| Cecha | Opis |
|
||||
|-------|------|
|
||||
| **Run-to-completion** | Pod kończy się po wykonaniu zadania |
|
||||
| **Retry policy** | Konfigurowalny `backoffLimit` (ile razy retry) |
|
||||
| **Parallelism** | Wiele podów jednocześnie (`parallelism`) |
|
||||
| **TTL cleanup** | Automatyczne usuwanie po N sekundach |
|
||||
| **Completions** | Ile podów musi zakończyć się sukcesem |
|
||||
|
||||
## Przykład
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: agent-run-001
|
||||
spec:
|
||||
backoffLimit: 0 # Bez retries
|
||||
ttlSecondsAfterFinished: 300 # Usuń po 5 minutach
|
||||
template:
|
||||
spec:
|
||||
restartPolicy: Never
|
||||
containers:
|
||||
- name: agent
|
||||
image: agent-runner:v1
|
||||
```
|
||||
|
||||
## Job vs inne workloady
|
||||
|
||||
| Workload | Lifecycle | Restart | Use case |
|
||||
|----------|-----------|---------|----------|
|
||||
| **Job** | Run-to-completion | Never/OnFailure | Batch, one-shot |
|
||||
| [[Deployment]] | Long-running | Always | Web services |
|
||||
| CronJob | Periodic Job | Never/OnFailure | Scheduled batch |
|
||||
| [[DaemonSet]] | One per node | Always | Node agents |
|
||||
| [[StatefulSet]] | Ordered, stable | Always | Databases |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
**AgentRun w trybie task = Kubernetes Job:**
|
||||
|
||||
Każde wywołanie agenta tworzy Job z:
|
||||
- Agent container (LLM loop)
|
||||
- IPC Bridge sidecar
|
||||
- Skill sidecars
|
||||
- `backoffLimit: 0` (brak retry - lepsze logowanie błędów)
|
||||
- `restartPolicy: Never`
|
||||
|
||||
Po zakończeniu controller zbiera logi, wynik i token usage ze statusu poda.
|
||||
|
||||
Więcej: [[Model efemerycznych agentów]] | [[Cykl życia AgentRun]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Deployment]] | [[Model efemerycznych agentów]] | [[Pod]]
|
||||
101
08-Słownik-K8s/Kata Containers.md
Normal file
101
08-Słownik-K8s/Kata Containers.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Kata Containers
|
||||
|
||||
#kubernetes #security #sandbox #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Kata Containers** to technologia łącząca **lekkość kontenerów z bezpieczeństwem maszyn wirtualnych**. Każdy kontener (lub pod) uruchamiany jest wewnątrz dedykowanej, lekkiej VM z własnym kernelem.
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
Bez Kata:
|
||||
Container → shared Host Kernel
|
||||
|
||||
Z Kata:
|
||||
Container → Guest Kernel (dedykowany) → Hypervisor (QEMU/Cloud Hypervisor) → Host Kernel
|
||||
```
|
||||
|
||||
Każdy pod dostaje:
|
||||
- **Własny kernel Linux** (guest kernel)
|
||||
- **Własną przestrzeń pamięci** (izolacja hypervisora)
|
||||
- **Dedykowany agent** (kata-agent) zarządzający kontenerem wewnątrz VM
|
||||
|
||||
## Architektura
|
||||
|
||||
```
|
||||
┌──────────────────────────────────┐
|
||||
│ Host (Node) │
|
||||
│ │
|
||||
│ ┌────────────────────────────┐ │
|
||||
│ │ Lightweight VM │ │
|
||||
│ │ ┌──────────────────────┐ │ │
|
||||
│ │ │ Container │ │ │
|
||||
│ │ │ (agent pod) │ │ │
|
||||
│ │ └──────────────────────┘ │ │
|
||||
│ │ Guest Kernel (Linux) │ │
|
||||
│ └────────────────────────────┘ │
|
||||
│ Hypervisor (QEMU/Cloud HV/FC) │
|
||||
│ Host Kernel │
|
||||
└──────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Hypervisory wspierane
|
||||
|
||||
| Hypervisor | Opis | Użycie |
|
||||
|------------|------|--------|
|
||||
| **QEMU** | Pełnofunkcyjny, uniwersalny | Domyślny |
|
||||
| **Cloud Hypervisor** | Zoptymalizowany dla cloud-native | Produkcja |
|
||||
| **Firecracker** | Micro-VM od AWS (Lambda/Fargate) | Serverless |
|
||||
| **ACRN** | Dla IoT/embedded | Specjalistyczny |
|
||||
|
||||
## Porównanie z gVisor
|
||||
|
||||
| Aspekt | [[gVisor]] | Kata Containers |
|
||||
|--------|---------|-----------------|
|
||||
| Mechanizm | User-space kernel (Sentry) | Lightweight VM (hypervisor) |
|
||||
| Izolacja | Przechwytywanie syscalls | Pełna izolacja kernela |
|
||||
| Overhead | 5-10% | 15-20% |
|
||||
| Kompatybilność | ~95% syscalls | ~99% |
|
||||
| Startup time | Szybki (~100ms) | Wolniejszy (~500ms-2s) |
|
||||
| Memory overhead | Niski (~20MB) | Wyższy (~50-100MB per VM) |
|
||||
| GPU support | Ograniczone | Lepsze (PCI passthrough) |
|
||||
| Bezpieczeństwo | Silne | **Najsilniejsze** (VM boundary) |
|
||||
|
||||
## Kiedy Kata vs gVisor?
|
||||
|
||||
### Wybierz gVisor gdy:
|
||||
- Potrzebujesz niskiego overhead
|
||||
- Workload jest I/O-intensive
|
||||
- Chcesz szybki startup
|
||||
|
||||
### Wybierz Kata gdy:
|
||||
- Potrzebujesz **najsilniejszej izolacji** (compliance, untrusted code)
|
||||
- Workload wymaga pełnej kompatybilności syscalls
|
||||
- GPU passthrough jest potrzebny
|
||||
|
||||
## Użycie w Kubernetes
|
||||
|
||||
Kata integruje się przez [[RuntimeClass]]:
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: kata
|
||||
handler: kata-qemu
|
||||
```
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
```yaml
|
||||
agentSandbox:
|
||||
enabled: true
|
||||
runtimeClass: kata
|
||||
```
|
||||
|
||||
Wymaga: Kata Containers zainstalowane na nodach + RuntimeClass `kata`.
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[gVisor]] | [[Agent Sandbox - gVisor i Kata]] | [[RuntimeClass]] | [[Model bezpieczeństwa Defence-in-Depth]]
|
||||
51
08-Słownik-K8s/NATS JetStream.md
Normal file
51
08-Słownik-K8s/NATS JetStream.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# NATS JetStream
|
||||
|
||||
#kubernetes #messaging #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**NATS** to lekki, cloud-native system messaging. **JetStream** to warstwa persistence dodana do NATS, umożliwiająca **durable pub/sub** z replay, retention i consumer groups.
|
||||
|
||||
## NATS vs JetStream
|
||||
|
||||
| NATS Core | NATS JetStream |
|
||||
|-----------|----------------|
|
||||
| Fire-and-forget | Durable (zapisane na dysk) |
|
||||
| At-most-once | At-least-once delivery |
|
||||
| Brak replay | Replay od dowolnego punktu |
|
||||
| Brak consumer groups | Consumer groups + ack |
|
||||
| Ultra-fast | Szybki (trochę wolniejszy) |
|
||||
|
||||
## Porównanie z alternatywami
|
||||
|
||||
| System | Latency | Throughput | Complexity | Use case |
|
||||
|--------|---------|------------|------------|----------|
|
||||
| **NATS JetStream** | ~1ms | ~100K msg/s | **Niski** | Cloud-native, K8s |
|
||||
| Apache Kafka | ~5ms | ~1M msg/s | Wysoki | Big data, streaming |
|
||||
| RabbitMQ | ~3ms | ~50K msg/s | Średni | Enterprise messaging |
|
||||
| Redis Streams | ~1ms | ~200K msg/s | Niski | Caching + messaging |
|
||||
|
||||
## Kluczowe koncepty JetStream
|
||||
|
||||
| Koncept | Opis |
|
||||
|---------|------|
|
||||
| **Stream** | Named storage dla wiadomości (temat wildcard) |
|
||||
| **Consumer** | Subskrybent z cursor/offset tracking |
|
||||
| **Durable Consumer** | Consumer z persistence (survives restarts) |
|
||||
| **Ack** | Potwierdzenie przetworzenia wiadomości |
|
||||
| **Retention** | Limits (max age, max bytes) lub Interest-based |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
NATS JetStream jest **centralnym event bus'em** Sympozium:
|
||||
|
||||
- **Stream**: `sympozium` z subjects `sympozium.>`
|
||||
- **Retention**: 24h max age
|
||||
- **Deployment**: [[StatefulSet]] w `sympozium-system`
|
||||
- **URL**: `nats://nats.sympozium-system.svc:4222`
|
||||
|
||||
Tematy: patrz [[NATS JetStream - Event Bus]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[NATS JetStream - Event Bus]] | [[Przepływ danych i IPC]] | [[StatefulSet]]
|
||||
47
08-Słownik-K8s/Namespace.md
Normal file
47
08-Słownik-K8s/Namespace.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Namespace
|
||||
|
||||
#kubernetes #multi-tenancy #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Namespace** to wirtualny klaster wewnątrz klastra Kubernetes. Pozwala na **logiczną izolację zasobów** - zasoby w różnych namespace'ach nie widzą się nawzajem (domyślnie).
|
||||
|
||||
## Kluczowe cechy
|
||||
|
||||
- **Scope zasobów** - Pods, Services, ConfigMaps etc. są namespace-scoped
|
||||
- **RBAC** - uprawnienia mogą być ograniczone do namespace
|
||||
- **Resource Quotas** - limity CPU/memory per namespace
|
||||
- **NetworkPolicy** - izolacja sieciowa per namespace
|
||||
- **Brak hierarchii** - namespace'y są płaskie (no nesting)
|
||||
|
||||
## Zasoby namespace-scoped vs cluster-scoped
|
||||
|
||||
| Namespace-scoped | Cluster-scoped |
|
||||
|-----------------|----------------|
|
||||
| Pod, Service, Deployment | Node, Namespace |
|
||||
| ConfigMap, Secret | ClusterRole |
|
||||
| Role, RoleBinding | ClusterRoleBinding |
|
||||
| NetworkPolicy | PersistentVolume |
|
||||
| **CRDs Sympozium** | StorageClass |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
### Multi-tenancy
|
||||
Każda [[SympoziumInstance]] działa w namespace (domyślnie `sympozium-system`):
|
||||
- Zasoby instancji izolowane w namespace
|
||||
- [[RBAC]] per-namespace kontroluje dostęp
|
||||
- [[NetworkPolicy]] per-namespace izoluje sieć
|
||||
|
||||
### System namespace
|
||||
`sympozium-system` - namespace control plane:
|
||||
- Controller, API Server, Webhook
|
||||
- NATS JetStream
|
||||
- Built-in PersonaPacks, SkillPacks, Policies
|
||||
|
||||
### Efemeryczny RBAC
|
||||
Namespace-scoped Role + RoleBinding mają [[ownerReference]] → AgentRun = auto GC.
|
||||
Cluster-scoped zasoby nie mogą mieć cross-namespace ownerRef.
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[RBAC]] | [[SympoziumInstance]] | [[Model bezpieczeństwa Defence-in-Depth]]
|
||||
90
08-Słownik-K8s/NetworkPolicy.md
Normal file
90
08-Słownik-K8s/NetworkPolicy.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# NetworkPolicy
|
||||
|
||||
#kubernetes #security #network #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**NetworkPolicy** to zasób Kubernetes definiujący **reguły firewalla na poziomie podów**. Kontroluje jaki ruch sieciowy (ingress/egress) jest dozwolony do/z podów.
|
||||
|
||||
## Domyślne zachowanie
|
||||
|
||||
Bez NetworkPolicy: **wszystko jest dozwolone** - każdy pod może komunikować się z każdym innym podem i z internetem.
|
||||
|
||||
Z NetworkPolicy: reguły definiują whitelist - ruch nie pasujący do żadnej reguły jest **blokowany**.
|
||||
|
||||
## Przykład deny-all
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: deny-all-egress
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
sympozium.ai/component: agent
|
||||
policyTypes:
|
||||
- Egress
|
||||
egress: [] # Pusty = BLOCK ALL
|
||||
```
|
||||
|
||||
## Przykład z wyjątkami
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
sympozium.ai/component: agent
|
||||
policyTypes:
|
||||
- Egress
|
||||
egress:
|
||||
# Pozwól DNS
|
||||
- to:
|
||||
- namespaceSelector: {}
|
||||
ports:
|
||||
- port: 53
|
||||
protocol: UDP
|
||||
# Pozwól NATS
|
||||
- to:
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: nats
|
||||
ports:
|
||||
- port: 4222
|
||||
```
|
||||
|
||||
## Wymagania
|
||||
|
||||
NetworkPolicy wymaga **CNI plugin** wspierającego Network Policies:
|
||||
- Calico
|
||||
- Cilium
|
||||
- Weave Net
|
||||
- Antrea
|
||||
|
||||
**Flannel** domyślnie NIE wspiera NetworkPolicy.
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium używa NetworkPolicy do **izolacji agent podów**:
|
||||
|
||||
```
|
||||
Agent pod:
|
||||
Egress: DENY ALL
|
||||
Wyjątki:
|
||||
- DNS (UDP 53)
|
||||
- NATS event bus (TCP 4222)
|
||||
- Skonfigurowane egress rules z SympoziumPolicy
|
||||
```
|
||||
|
||||
Dzięki temu agent nie może:
|
||||
- Sięgnąć do internetu
|
||||
- Komunikować się z innymi podami
|
||||
- Exfiltrować danych
|
||||
|
||||
Jedyny punkt wyjścia to IPC Bridge → NATS (kontrolowany kanał).
|
||||
|
||||
Więcej: [[NetworkPolicy i izolacja sieciowa]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[NetworkPolicy i izolacja sieciowa]] | [[SympoziumPolicy]] | [[Model bezpieczeństwa Defence-in-Depth]]
|
||||
67
08-Słownik-K8s/PersistentVolumeClaim.md
Normal file
67
08-Słownik-K8s/PersistentVolumeClaim.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# PersistentVolumeClaim (PVC)
|
||||
|
||||
#kubernetes #storage #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**PersistentVolumeClaim (PVC)** to żądanie trwałego storage w Kubernetes. PVC abstrakcje underlying storage (dysk, NFS, cloud volume) i zapewnia **dane przetrwają restart poda**.
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
PVC (żądanie: 10Gi, ReadWriteOnce)
|
||||
↓
|
||||
StorageClass (provisioner: ebs/gce-pd/local)
|
||||
↓
|
||||
PersistentVolume (faktyczny dysk)
|
||||
↓
|
||||
Pod mountuje PVC
|
||||
```
|
||||
|
||||
## Access Modes
|
||||
|
||||
| Mode | Opis | Skrót |
|
||||
|------|------|-------|
|
||||
| ReadWriteOnce | Jeden node może czytać/pisać | RWO |
|
||||
| ReadOnlyMany | Wiele node'ów read-only | ROX |
|
||||
| ReadWriteMany | Wiele node'ów read/write | RWX |
|
||||
|
||||
## emptyDir vs PVC
|
||||
|
||||
| | emptyDir | PVC |
|
||||
|---|----------|-----|
|
||||
| Lifecycle | Z podem | Niezależny od poda |
|
||||
| Persistence | **NIE** - dane znikają | **TAK** - dane trwają |
|
||||
| Sharing | Między kontenerami w podzie | Między podami (z ograniczeniami) |
|
||||
| Speed | Szybki (RAM option) | Zależne od storage |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
### Memory PVC
|
||||
```yaml
|
||||
name: <instance>-memory-db
|
||||
spec:
|
||||
accessModes: [ReadWriteOnce]
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
Przechowuje SQLite DB z pamięcią agenta. Przetrwa restarty memory-server poda.
|
||||
|
||||
### WhatsApp PVC
|
||||
```yaml
|
||||
name: <instance>-channel-whatsapp-data
|
||||
spec:
|
||||
accessModes: [ReadWriteOnce]
|
||||
resources:
|
||||
requests:
|
||||
storage: 256Mi
|
||||
```
|
||||
Przechowuje WhatsApp credentials (QR link survives restarts).
|
||||
|
||||
### Strategy: Recreate
|
||||
Oba PVC są RWO (jeden pod na raz), więc Deployment Strategy musi być `Recreate` (nie RollingUpdate).
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Persistent Memory]] | [[ConfigMap i Secret]] | [[Kanały - Telegram Slack Discord WhatsApp]]
|
||||
59
08-Słownik-K8s/Pod.md
Normal file
59
08-Słownik-K8s/Pod.md
Normal file
@@ -0,0 +1,59 @@
|
||||
# Pod
|
||||
|
||||
#kubernetes #workload #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Pod** to **najmniejsza deployowalna jednostka** w Kubernetes. Pod zawiera jeden lub więcej kontenerów współdzielących sieć i storage.
|
||||
|
||||
## Kluczowe cechy
|
||||
|
||||
- **Współdzielona sieć** - kontenery w podzie widzą się jako `localhost`
|
||||
- **Współdzielone woluminy** - kontenery mogą mountować te same woluminy
|
||||
- **Shared lifecycle** - wszystkie kontenery startują i kończą się razem
|
||||
- **Unikalne IP** - każdy pod dostaje własne IP w klastrze
|
||||
- **Efemeryczny** - pod nie jest "naprawiany", jest zastępowany nowym
|
||||
|
||||
## Anatomia
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ Pod │
|
||||
│ Network namespace (shared IP) │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ Container │ │ Container │ ... │
|
||||
│ │ (main) │ │ (sidecar) │ │
|
||||
│ └──────────┘ └──────────┘ │
|
||||
│ │
|
||||
│ Volumes (shared): │
|
||||
│ /workspace (emptyDir) │
|
||||
│ /ipc (emptyDir, RAM) │
|
||||
│ /skills (projected ConfigMap) │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Multi-container patterns
|
||||
|
||||
| Pattern | Opis | Przykład w Sympozium |
|
||||
|---------|------|---------------------|
|
||||
| **Sidecar** | Kontener pomocniczy obok głównego | IPC Bridge, Skill sidecars |
|
||||
| **Init container** | Uruchamiany przed głównymi | wait-for-memory |
|
||||
| **Ambassador** | Proxy do zewnętrznych serwisów | MCP Bridge |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Agent Pod to multi-container pod z:
|
||||
- **Agent container** - główny (LLM loop)
|
||||
- **IPC Bridge sidecar** - komunikacja fsnotify → NATS
|
||||
- **Skill sidecars** - narzędzia (kubectl, helm)
|
||||
- **MCP Bridge** - proxy do MCP serwerów
|
||||
- **Sandbox** - opcjonalny kontener izolacji
|
||||
|
||||
Współdzielone woluminy umożliwiają IPC bez sieci.
|
||||
|
||||
Więcej: [[Cykl życia Agent Pod]] | [[Sidecar Pattern]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Job]] | [[Deployment]] | [[Sidecar Pattern]] | [[SecurityContext]]
|
||||
91
08-Słownik-K8s/RBAC.md
Normal file
91
08-Słownik-K8s/RBAC.md
Normal file
@@ -0,0 +1,91 @@
|
||||
# RBAC - Role-Based Access Control
|
||||
|
||||
#kubernetes #security #rbac #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**RBAC** (Role-Based Access Control) to system autoryzacji w Kubernetes. Definiuje **kto** (subject) może wykonywać **jakie operacje** (verbs) na **jakich zasobach** (resources).
|
||||
|
||||
## Komponenty
|
||||
|
||||
### Role (namespace-scoped)
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: Role
|
||||
metadata:
|
||||
name: pod-reader
|
||||
namespace: my-namespace
|
||||
rules:
|
||||
- apiGroups: [""] # "" = core API group
|
||||
resources: ["pods"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
```
|
||||
|
||||
### ClusterRole (cluster-scoped)
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: node-reader
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["nodes"]
|
||||
verbs: ["get", "list"]
|
||||
```
|
||||
|
||||
### RoleBinding (wiąże Role z podmiotem)
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: read-pods
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: my-agent
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: pod-reader
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
## Verbs
|
||||
|
||||
| Verb | Opis |
|
||||
|------|------|
|
||||
| `get` | Odczyt pojedynczego zasobu |
|
||||
| `list` | Listowanie zasobów |
|
||||
| `watch` | Obserwowanie zmian (streaming) |
|
||||
| `create` | Tworzenie nowego zasobu |
|
||||
| `update` | Aktualizacja istniejącego |
|
||||
| `patch` | Częściowa aktualizacja |
|
||||
| `delete` | Usuwanie zasobu |
|
||||
|
||||
## Scope
|
||||
|
||||
| Typ | Scope | Binding |
|
||||
|-----|-------|---------|
|
||||
| **Role** | Namespace | RoleBinding |
|
||||
| **ClusterRole** | Cały klaster | ClusterRoleBinding |
|
||||
| **ClusterRole** | Namespace (reuse) | RoleBinding |
|
||||
|
||||
## Privilege escalation prevention
|
||||
|
||||
Kubernetes nie pozwala na tworzenie ról z uprawnieniami większymi niż posiada twórca. Dlatego controller Sympozium wymaga `cluster-admin` - musi tworzyć dowolne role zdefiniowane w [[SkillPack|SkillPacks]].
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium implementuje **efemeryczny RBAC per-run**:
|
||||
|
||||
1. [[SkillPack]] deklaruje potrzebne uprawnienia (rbac/clusterRBAC)
|
||||
2. Przy tworzeniu [[AgentRun]], controller tworzy:
|
||||
- Role + RoleBinding (namespace-scoped, [[ownerReference]] → AgentRun)
|
||||
- ClusterRole + ClusterRoleBinding (label-based cleanup)
|
||||
3. Po zakończeniu runu → RBAC usunięty
|
||||
|
||||
Credentials istnieją **tylko przez czas trwania runu**.
|
||||
|
||||
Więcej: [[Efemeryczny RBAC per-run]] | [[Skill Sidecars i auto-RBAC]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Efemeryczny RBAC per-run]] | [[ServiceAccount]] | [[Skill Sidecars i auto-RBAC]]
|
||||
74
08-Słownik-K8s/RuntimeClass.md
Normal file
74
08-Słownik-K8s/RuntimeClass.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# RuntimeClass
|
||||
|
||||
#kubernetes #security #container-runtime #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**RuntimeClass** to zasób Kubernetes pozwalający na **wybór container runtime** dla poda. Domyślnie pody używają standardowego runtime (runc), ale RuntimeClass pozwala na użycie alternatywnych runtime'ów jak [[gVisor]] (runsc) czy [[Kata Containers]].
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
1. Administrator tworzy RuntimeClass
|
||||
2. Pod spec: runtimeClassName: gvisor
|
||||
3. Kubelet: zamiast runc, użyj runsc (gVisor)
|
||||
4. Pod uruchamiany w gVisor sandbox
|
||||
```
|
||||
|
||||
## Przykład
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: gvisor
|
||||
handler: runsc # Nazwa handler'a w konfiguracji containerd
|
||||
|
||||
---
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: kata
|
||||
handler: kata-qemu
|
||||
```
|
||||
|
||||
## Containerd konfiguracja
|
||||
|
||||
```toml
|
||||
# /etc/containerd/config.toml
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
|
||||
runtime_type = "io.containerd.runsc.v1"
|
||||
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu]
|
||||
runtime_type = "io.containerd.kata.v2"
|
||||
```
|
||||
|
||||
## Overhead scheduling
|
||||
|
||||
RuntimeClass może deklarować overhead:
|
||||
```yaml
|
||||
overhead:
|
||||
podFixed:
|
||||
memory: "120Mi"
|
||||
cpu: "250m"
|
||||
```
|
||||
|
||||
Kubernetes scheduler uwzględnia overhead przy planowaniu.
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium obsługuje RuntimeClass przez [[Agent Sandbox - gVisor i Kata]]:
|
||||
|
||||
```yaml
|
||||
# SympoziumPolicy - wymusza i ogranicza runtime classes
|
||||
agentSandboxPolicy:
|
||||
required: true
|
||||
defaultRuntimeClass: gvisor
|
||||
allowedRuntimeClasses: [gvisor, kata]
|
||||
```
|
||||
|
||||
Controller tworzy Sandbox CR z `runtimeClassName` ustawionym z konfiguracji.
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[gVisor]] | [[Kata Containers]] | [[Agent Sandbox - gVisor i Kata]]
|
||||
76
08-Słownik-K8s/SecurityContext.md
Normal file
76
08-Słownik-K8s/SecurityContext.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# SecurityContext
|
||||
|
||||
#kubernetes #security #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**SecurityContext** to konfiguracja bezpieczeństwa na poziomie poda lub kontenera. Definiuje **jak kontener jest uruchamiany** z perspektywy systemu operacyjnego.
|
||||
|
||||
## Kluczowe pola
|
||||
|
||||
```yaml
|
||||
securityContext:
|
||||
runAsNonRoot: true # Nie uruchamiaj jako root
|
||||
runAsUser: 1000 # UID procesu
|
||||
runAsGroup: 1000 # GID procesu
|
||||
readOnlyRootFilesystem: true # Root FS tylko do odczytu
|
||||
allowPrivilegeEscalation: false # Blokuj setuid/setgid
|
||||
capabilities:
|
||||
drop: ["ALL"] # Usuń WSZYSTKIE Linux capabilities
|
||||
add: ["NET_BIND_SERVICE"] # Dodaj konkretne (opcjonalnie)
|
||||
seccompProfile:
|
||||
type: RuntimeDefault # Seccomp profil
|
||||
```
|
||||
|
||||
## Pola wyjaśnione
|
||||
|
||||
### runAsNonRoot
|
||||
Wymusza uruchomienie kontenera jako użytkownik inny niż root (UID != 0). Jeśli obraz ma `USER root`, pod nie wystartuje.
|
||||
|
||||
### readOnlyRootFilesystem
|
||||
System plików kontenera jest read-only. Kontener może pisać tylko do zamontowanych woluminów (`/tmp`, `/workspace`). Zapobiega modyfikacji binariów.
|
||||
|
||||
### capabilities
|
||||
Linux capabilities to granularne uprawnienia (zamiast "all-or-nothing" root):
|
||||
|
||||
| Capability | Opis |
|
||||
|------------|------|
|
||||
| `CAP_NET_ADMIN` | Konfiguracja sieci |
|
||||
| `CAP_SYS_ADMIN` | Operacje administracyjne |
|
||||
| `CAP_NET_BIND_SERVICE` | Bindowanie portów < 1024 |
|
||||
| `ALL` | Wszystkie naraz |
|
||||
|
||||
`drop: ["ALL"]` usuwa WSZYSTKIE capabilities - kontener ma minimalne uprawnienia.
|
||||
|
||||
### seccompProfile
|
||||
**Seccomp** (Secure Computing Mode) filtruje syscalls na poziomie kernela:
|
||||
- `RuntimeDefault` - profil domyślny containerd (blokuje niebezpieczne syscalls)
|
||||
- `Unconfined` - brak filtrowania
|
||||
- `Localhost` - custom profil z pliku
|
||||
|
||||
### allowPrivilegeEscalation
|
||||
Blokuje mechanizmy eskalacji uprawnień:
|
||||
- setuid/setgid bity na plikach
|
||||
- `no_new_privs` flag w kernelu
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Agent containers mają **hardened SecurityContext**:
|
||||
|
||||
```go
|
||||
SecurityContext: &corev1.SecurityContext{
|
||||
ReadOnlyRootFilesystem: true,
|
||||
AllowPrivilegeEscalation: false,
|
||||
Capabilities: &corev1.Capabilities{
|
||||
Drop: []corev1.Capability{"ALL"},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
W połączeniu z [[NetworkPolicy]] i [[RBAC]], tworzy to defense-in-depth.
|
||||
|
||||
Więcej: [[Model bezpieczeństwa Defence-in-Depth]] | [[Cykl życia Agent Pod]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Model bezpieczeństwa Defence-in-Depth]] | [[gVisor]] | [[Kata Containers]] | [[Pod]]
|
||||
49
08-Słownik-K8s/ServiceAccount.md
Normal file
49
08-Słownik-K8s/ServiceAccount.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# ServiceAccount
|
||||
|
||||
#kubernetes #security #rbac #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**ServiceAccount** to tożsamość przypisana do podów w Kubernetes. Pody używają ServiceAccount do autentykacji wobec API servera i uzyskania uprawnień zdefiniowanych w [[RBAC]].
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
Pod → ServiceAccount → Token (auto-mounted) → K8s API Server
|
||||
↓
|
||||
RoleBinding sprawdza:
|
||||
"Czy ten SA ma Role z verbs?"
|
||||
```
|
||||
|
||||
Token jest automatycznie montowany w podzie pod:
|
||||
```
|
||||
/var/run/secrets/kubernetes.io/serviceaccount/token
|
||||
```
|
||||
|
||||
## Domyślne zachowanie
|
||||
|
||||
- Każdy namespace ma `default` ServiceAccount
|
||||
- Pody bez jawnego SA używają `default`
|
||||
- `default` SA ma minimalne uprawnienia (prawie żadne)
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Controller tworzy **dedykowany ServiceAccount** `sympozium-agent` w namespace runu:
|
||||
|
||||
```
|
||||
1. ensureAgentServiceAccount() → tworzy SA
|
||||
2. Role/ClusterRole → definiuje uprawnienia (z SkillPack)
|
||||
3. RoleBinding → wiąże SA z Role
|
||||
4. Pod spec: serviceAccountName: sympozium-agent
|
||||
5. Skill sidecar używa tokenu SA do kubectl/API calls
|
||||
6. Po zakończeniu → SA i RBAC garbage-collected
|
||||
```
|
||||
|
||||
Agent container **nie używa** tokenu SA (brak dostępu do K8s API).
|
||||
Skill sidecar **używa** tokenu SA (kubectl via automounted token).
|
||||
|
||||
Więcej: [[RBAC]] | [[Efemeryczny RBAC per-run]] | [[Skill Sidecars i auto-RBAC]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[RBAC]] | [[Efemeryczny RBAC per-run]] | [[Pod]]
|
||||
64
08-Słownik-K8s/Sidecar Pattern.md
Normal file
64
08-Słownik-K8s/Sidecar Pattern.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Sidecar Pattern
|
||||
|
||||
#kubernetes #patterns #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**Sidecar Pattern** to wzorzec architektoniczny w Kubernetes gdzie **dodatkowy kontener** (sidecar) jest uruchamiany obok głównego kontenera w tym samym [[Pod|podzie]]. Sidecar rozszerza lub uzupełnia funkcjonalność głównego kontenera.
|
||||
|
||||
## Cechy
|
||||
|
||||
- Współdzieli **sieć** z głównym kontenerem (localhost)
|
||||
- Współdzieli **woluminy** (np. /ipc, /workspace)
|
||||
- Ma **własne zasoby** (CPU, memory limits)
|
||||
- Ma **własny lifecycle** (może mieć inne healthchecks)
|
||||
- **Nie modyfikuje** głównego kontenera
|
||||
|
||||
## Typowe zastosowania
|
||||
|
||||
| Sidecar | Rola | Przykład |
|
||||
|---------|------|---------|
|
||||
| Log collector | Zbiera logi | Fluentd, Filebeat |
|
||||
| Proxy | Routing sieciowy | Envoy (Istio), Linkerd |
|
||||
| Auth | Autentykacja/autoryzacja | OAuth2 proxy |
|
||||
| Monitoring | Metryki | Prometheus exporter |
|
||||
| **IPC Bridge** | Komunikacja | Sympozium: fsnotify → NATS |
|
||||
| **Skill sidecar** | Narzędzia | Sympozium: kubectl, helm |
|
||||
|
||||
## Komunikacja main ↔ sidecar
|
||||
|
||||
| Metoda | Opis | Użycie w Sympozium |
|
||||
|--------|------|---------------------|
|
||||
| **Shared volume** | Pliki w współdzielonym katalogu | `/ipc/` - JSON request/response |
|
||||
| **localhost** | HTTP/gRPC na localhost | Memory server API |
|
||||
| **Shared network** | Porty na localhost | MCP bridge |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
Sympozium to **intensywny użytkownik sidecar pattern**. Typowy agent pod:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ Agent Pod │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ MAIN: │ │ SIDECAR: │ │ SIDECAR: │ │
|
||||
│ │ Agent │ │ IPC │ │ Skill │ │
|
||||
│ │ Runner │ │ Bridge │ │ (kubectl)│ │
|
||||
│ └──────────┘ └──────────┘ └──────────┘ │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ SIDECAR: │ │ SIDECAR: │ │
|
||||
│ │ MCP │ │ Sandbox │ │
|
||||
│ │ Bridge │ │ (opcj.) │ │
|
||||
│ └──────────┘ └──────────┘ │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Kluczowa innowacja: **skill sidecary mają własny [[RBAC]]**, a agent container nie ma żadnych credentials K8s.
|
||||
|
||||
Więcej: [[Skill Sidecars i auto-RBAC]] | [[Cykl życia Agent Pod]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Pod]] | [[Skill Sidecars i auto-RBAC]] | [[Przepływ danych i IPC]]
|
||||
27
08-Słownik-K8s/StatefulSet.md
Normal file
27
08-Słownik-K8s/StatefulSet.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# StatefulSet
|
||||
|
||||
#kubernetes #workload #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**StatefulSet** zarządza podami ze **stabilną tożsamością** - stały hostname, ordered deployment/scaling, i persistent storage per pod.
|
||||
|
||||
## Różnica vs Deployment
|
||||
|
||||
| | StatefulSet | [[Deployment]] |
|
||||
|---|-------------|------------|
|
||||
| Pod names | Ordered: `nats-0`, `nats-1` | Random: `nats-7d8f9-abc` |
|
||||
| Scaling | Sekwencyjne (0, 1, 2...) | Równoległe |
|
||||
| Storage | PVC per pod (stałe) | Shared lub brak |
|
||||
| Network | Stable DNS per pod | Load-balanced Service |
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
**NATS JetStream** jest deployowany jako StatefulSet:
|
||||
- Stały hostname (`nats-0.nats.sympozium-system.svc`)
|
||||
- Persistent storage dla JetStream data
|
||||
- Durable event bus z replay capability
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[NATS JetStream - Event Bus]] | [[Deployment]] | [[Pod]]
|
||||
87
08-Słownik-K8s/gVisor.md
Normal file
87
08-Słownik-K8s/gVisor.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# gVisor
|
||||
|
||||
#kubernetes #security #sandbox #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**gVisor** to projekt open-source od Google implementujący **user-space kernel** - warstwę pośrednią między kontenerem a kernelem hosta. Zamiast pozwalać kontenerowi na bezpośrednie wywołania systemowe (syscalls) do kernela hosta, gVisor przechwytuje je i obsługuje we własnym user-space kernelu o nazwie **Sentry**.
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```
|
||||
Bez gVisor:
|
||||
Container → syscall → Host Kernel (współdzielony!)
|
||||
|
||||
Z gVisor:
|
||||
Container → syscall → Sentry (user-space kernel) → ograniczone syscalls → Host Kernel
|
||||
```
|
||||
|
||||
**Sentry** reimplementuje dużą część interfejsu Linux kernel (ponad 200 syscalls) w Go. Tylko niewielka liczba prawdziwych syscalls jest przekazywana do hosta.
|
||||
|
||||
## Kluczowe komponenty
|
||||
|
||||
| Komponent | Rola |
|
||||
|-----------|------|
|
||||
| **Sentry** | User-space kernel - obsługuje syscalls kontenera |
|
||||
| **Gofer** | File server - pośredniczy w dostępie do systemu plików |
|
||||
| **runsc** | OCI runtime - integruje się z containerd/runc |
|
||||
|
||||
## Dlaczego to ważne?
|
||||
|
||||
### Problem z tradycyjnymi kontenerami
|
||||
Kontenery współdzielą kernel hosta. Exploit w kernelu (np. CVE w obsłudze syscalls) = ucieczka z kontenera = dostęp do hosta i wszystkich innych kontenerów.
|
||||
|
||||
### Rozwiązanie gVisor
|
||||
- Kontener rozmawia z **Sentry**, nie z prawdziwym kernelem
|
||||
- Nawet jeśli Sentry zostanie skompromitowany, ma ograniczony dostęp do hosta
|
||||
- Powierzchnia ataku kernela zredukowana z ~400 syscalls do ~50
|
||||
|
||||
## Porównanie z alternatywami
|
||||
|
||||
| Technologia | Izolacja | Overhead | Kompatybilność |
|
||||
|-------------|----------|----------|-----------------|
|
||||
| Kontenery (runc) | Namespace + cgroups | ~0% | 100% |
|
||||
| **gVisor** | User-space kernel | **5-10%** | ~95% (nie wszystkie syscalls) |
|
||||
| [[Kata Containers]] | Lightweight VM | ~15-20% | ~99% |
|
||||
| Pełna VM (KVM) | Hypervisor | ~30%+ | 100% |
|
||||
|
||||
## Ograniczenia
|
||||
|
||||
- **Nie wszystkie syscalls** są implementowane (np. niektóre ioctl)
|
||||
- **Overhead I/O** - Gofer dodaje pośrednika do operacji plikowych
|
||||
- **Networking** - netstack (własny stack sieciowy) może mieć różnice w zachowaniu
|
||||
- **GPU** - ograniczone wsparcie dla GPU passthrough
|
||||
|
||||
## Użycie w Kubernetes
|
||||
|
||||
gVisor integruje się z K8s przez [[RuntimeClass]]:
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: gvisor
|
||||
handler: runsc
|
||||
```
|
||||
|
||||
Pod używający gVisor:
|
||||
```yaml
|
||||
spec:
|
||||
runtimeClassName: gvisor
|
||||
```
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
W Sympozium gVisor jest opcjonalną warstwą izolacji dla agent podów. Konfiguracja w [[AgentRun]] lub [[SympoziumInstance]]:
|
||||
|
||||
```yaml
|
||||
agentSandbox:
|
||||
enabled: true
|
||||
runtimeClass: gvisor
|
||||
```
|
||||
|
||||
Integracja via [[Agent Sandbox - gVisor i Kata]] (kubernetes-sigs/agent-sandbox).
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Kata Containers]] | [[Agent Sandbox - gVisor i Kata]] | [[RuntimeClass]] | [[SecurityContext]]
|
||||
66
08-Słownik-K8s/ownerReference.md
Normal file
66
08-Słownik-K8s/ownerReference.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# ownerReference
|
||||
|
||||
#kubernetes #lifecycle #garbage-collection #słownik
|
||||
|
||||
## Co to jest?
|
||||
|
||||
**ownerReference** to metadata na zasobie Kubernetes wskazująca na jego "właściciela". Gdy właściciel jest usunięty, Kubernetes **automatycznie garbage-collectuje** zasoby-dzieci.
|
||||
|
||||
## Jak działa?
|
||||
|
||||
```yaml
|
||||
# Child resource (np. Job)
|
||||
metadata:
|
||||
ownerReferences:
|
||||
- apiVersion: sympozium.ai/v1alpha1
|
||||
kind: AgentRun
|
||||
name: my-run-001
|
||||
uid: abc-123
|
||||
controller: true
|
||||
blockOwnerDeletion: true
|
||||
```
|
||||
|
||||
```
|
||||
Usunięcie AgentRun → K8s GC → Usunięcie Job → Usunięcie Pod
|
||||
```
|
||||
|
||||
## Cascade deletion
|
||||
|
||||
| Typ | Zachowanie |
|
||||
|-----|------------|
|
||||
| **Foreground** | Owner czeka na usunięcie children |
|
||||
| **Background** | Owner usunięty natychmiast, children async |
|
||||
| **Orphan** | Children nie są usuwane (osierocone) |
|
||||
|
||||
## Ograniczenia
|
||||
|
||||
- ownerReference działa **tylko w tym samym namespace**
|
||||
- Cluster-scoped zasoby (ClusterRole) **nie mogą** mieć ownerRef na namespace-scoped (AgentRun)
|
||||
- Dlatego Sympozium używa label-based cleanup dla cluster RBAC
|
||||
|
||||
## Użycie w Sympozium
|
||||
|
||||
### Automatyczne (ownerRef)
|
||||
```
|
||||
PersonaPack → owns → SympoziumInstance → owns → Channel Deployment
|
||||
→ owns → Memory ConfigMap
|
||||
→ owns → AgentRun → owns → Job
|
||||
→ owns → Role
|
||||
→ owns → RoleBinding
|
||||
```
|
||||
|
||||
Usunięcie PersonaPack = kaskadowe usunięcie CAŁEGO drzewa.
|
||||
|
||||
### Manualne (label-based, bo cross-namespace)
|
||||
```
|
||||
ClusterRole (cluster-scoped) ← label: sympozium.ai/agentrun: my-run
|
||||
ClusterRoleBinding ← label: sympozium.ai/agentrun: my-run
|
||||
|
||||
Controller czyści po labelach w reconcileCompleted()
|
||||
```
|
||||
|
||||
Więcej: [[Finalizer]] | [[Efemeryczny RBAC per-run]] | [[PersonaPacks - zespoły agentów]]
|
||||
|
||||
---
|
||||
|
||||
Powiązane: [[Finalizer]] | [[Controller i Reconciler]] | [[CRD - Custom Resource Definition]]
|
||||
Reference in New Issue
Block a user