kagent: agenci AI jako natywne zasoby Kubernetes

Kubernetes zarządza podami, serwisami, ingress-ami, certyfikatami. Od niedawna może zarządzać też agentami AI — tak samo jak każdym innym workloadem. Projekt kagent, stworzony przez Solo.io w 2025 roku, trafił właśnie do CNCF Sandbox.

Problem: agenci AI poza kontrolą platformy

Kiedy zespół DevOps chce uruchomić agenta AI — do diagnostyki klastra, analizy logów, zarządzania rolloutami — zwykle robi to poza standardowym cyklem deploymentu: skrypt w Pythonie, serwis uruchamiany ręcznie, klucz API wklejony do zmiennej środowiskowej. Brak RBAC, brak observability, brak wersjonowania, brak GitOps.

kagent odpowiada na to pytanie: co jeśli agent byłby po prostu kolejnym zasobem Kubernetes?

Architektura

Trzy elementy:

Agent CRD — definicja agenta jako obiekt Kubernetes (apiVersion: kagent.dev/v1alpha2). Zawiera konfigurację modelu, system prompt, listę dozwolonych narzędzi i opcjonalną konfigurację A2A.

Controller — obserwuje obiekty Agent i tworzy dla każdego działającego agenta pod komunikujący się przez protokół A2A (Agent-to-Agent). Status agenta widać przez kubectl — warunki Accepted i Ready jak przy każdym innym zasobie.

Tool server — serwer MCP (kagent-tool-server) oferujący 22 narzędzia do interakcji z klastrem: czytanie logów, zapytania do Prometheus, inspekcja Gateway API i HTTPRoute, zarządzanie rolloutami. Lista narzędzi widocznych dla modelu jest zawężana przez toolNames — allowlist.

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: cluster-assistant
spec:
  type: Declarative
  declarative:
    modelConfig: default-model-config
    systemMessage: |
      Jesteś asystentem klastra Kubernetes. Odpowiadaj tylko na pytania
      o zasoby w podanym namespace. Nie modyfikuj żadnych obiektów.
    tools:
      - name: kagent-tool-server
        type: McpServer
        mcpServer:
          toolServerRef:
            name: kagent-tool-server
          toolNames:
            - get_pods
            - get_logs
            - describe_service

A2A i multi-agent

Każdy agent jest eksponowany jako endpoint A2A na kontrolerze (/api/a2a/kagent/<agent-name>/, port 8083). Agenci mogą odkrywać się nawzajem i delegować zadania — to fundament pod architektury wieloagentowe, gdzie jeden agent-planista rozdziela pracę między wyspecjalizowane agenów-wykonawców.

Protokół A2A to standard rozwijany przez Google (Agent Development Kit, na którym oparty jest kagent). Wiadomości przesyłane są przez JSON-RPC — message/send. Kiedy agent czeka na zatwierdzenie operacji przez człowieka, zwraca stan input-required.

Human-in-the-loop przez requireApproval

Kluczowy mechanizm bezpieczeństwa: pole requireApproval przy definicji narzędzia wstrzymuje wykonanie przed wywołaniem i czeka na odpowiedź operatora (approve lub reject). Pozwala to budować agentów, którzy planują i proponują zmiany, ale aplikują je tylko za ludzką zgodą.

tools:
  - name: kagent-tool-server
    type: McpServer
    mcpServer:
      toolServerRef:
        name: kagent-tool-server
      requireApproval:
        - apply_manifest
        - delete_resource
      toolNames:
        - apply_manifest
        - delete_resource
        - get_pods
        - get_logs

RBAC jak przy każdym workloadzie

Domyślna instalacja przez Helm daje kagent-tool-server ServiceAccount z uprawnieniami cluster-admin — zbyt szerokie dla produkcji. Zalecane podejście: zastąpić ClusterRoleBinding rolą tylko do odczytu i dodać osobną regułę pozwalającą na zapis wyłącznie do agents.kagent.dev.

Weryfikacja standardowym narzędziem:

kubectl auth can-i create agents.kagent.dev \
  --as=system:serviceaccount:kagent:kagent-tool-server
# yes

kubectl auth can-i create deployments \
  --as=system:serviceaccount:kagent:kagent-tool-server
# no

Modele i instalacja

kagent działa z lokalnymi modelami przez Ollama i zewnętrznymi dostawcami: OpenAI, Anthropic, Azure OpenAI, Gemini. Konfiguracja modelu przez obiekt ModelConfig.

Instalacja przez Helm:

helm repo add kagent https://kagent-dev.github.io/kagent
helm repo update

helm install kagent kagent/kagent \
  --namespace kagent \
  --create-namespace \
  --set modelProvider=ollama \
  --set ollama.model=qwen3-coder:30b-a3b-q4_K_M

Uwaga praktyczna z testów CNCF: mniejsze modele (7B, 8B) generują błędne wywołania narzędzi lub pomijają krok aplikowania zmian. Modele rzędu 30B działają stabilnie. Dla produkcji rekomendowane są modele hostowane.

Przypadki użycia

Według dokumentacji kagent celuje w typowe zadania operacyjne:

• diagnostyka łączności przez kolejne hoopy serwisów
• analiza degradacji wydajności z Prometheus
• generowanie alertów i reguł nagrywania
• debugowanie konfiguracji Gateway API i HTTPRoute
• zarządzanie progressive rolloutami (canary, blue-green)

Każdy z tych przypadków to dziś zwykle praca eksperta z dostępem do klastra. kagent pozwala skodyfikować tę wiedzę w agencie i udostępnić ją szerszemu zespołowi — z kontrolowanym zakresem uprawnień.

Co to oznacza dla platform engineeringu

Integracja agentów AI z Kubernetes przez CRD to logiczny krok: te same narzędzia CI/CD, te same polityki OPA/Kyverno, ten sam audit log. Agent staje się artefaktem, który można wersjonować w repozytorium, deployować przez ArgoCD
i obserwować przez Prometheus.

Projekt jest na wczesnym etapie (v1alpha2, domyślny tryb unsecure), ale kierunek jest czytelny. Jeśli GitOps dla konfiguracji klastra stał się standardem, GitOps dla agentów AI to następny przystanek.

Źródła: kagent.dev, CNCF Blog — Running kagent on your laptop, The New Stack — Kubernetes is evolving to handle AI agents, CNCF Projects — kagent