Skip to main content

Examples & Use Cases

Real-world scenarios demonstrating the Kubernetes Agent's Architect (Generation), Operator (Management), and ArgoCD Onboarding workflows.

🏗ī¸ Scenario 1: Generating a New Service​

Objective: Create a production-ready Helm chart for a Python backend service.

The Request​

User: "Create a helm chart for my payment-service. It's a Python FastAPI app using payment:v2 image. It needs a Redis connection and should be exposed on port 8000."

1. Planning (Gap Detection)​

The Planner Agent analyzes the request and notices a missing detail (Redis connection info), triggering a clarifying question.

Agent: "I can certainly help with that. To ensure the Redis connection is configured correctly, how should the application connect to Redis?

  1. Should I include a Redis sub-chart (deploy a new Redis)?
  2. Or will it connect to an external Redis URL provided via environment variables?"

User: "It connects to an external Redis at redis.infrastructure.svc."

2. Architecture Design​

The agent generates a plan:

  • Workload: Deployment (Stateless generic app)
  • Config: ConfigMap for REDIS_HOST environment variable.
  • Networking: Service on port 8000 + Ingress rules.
  • Health: Standard HTTP liveness probes on /health.

3. Generation & Validation​

The Generator Agent writes the files and runs validation:

Issue Detected:

Event: helm_lint_validator
Status: FAILED
Error: templates/deployment.yaml:23:21: invalid indentation in 'env' block.

Self-Healing Action: The agent automatically reads line 23, fixes the whitespace, saves the file, and re-runs validation. Passed.

Final Output​

The agent delivers the chart to /tmp/helm-charts/payment-service.

🕹ī¸ Scenario 2: Safe Installation (Helm Mgmt)​

Objective: Install a complex third-party application (ArgoCD) with safety checks.

The Request​

User: "Install ArgoCD from the official repo into the argocd namespace."

1. Discovery & Context​

The Helm Management Agent checks the cluster:

  • Namespace exists? No -> Plans creation.
  • Repo added? No -> Adds argo https://argoproj.github.io/argo-helm.
  • Release exists? No -> Mode: INSTALL.

2. Values Confirmation (HITL Gate)​

Before generating a full plan, the agent asks for configuration confirmation.

Agent: "I found the chart argo/argo-cd version 5.51.0.

Required Configuration: No mandatory values found, but I recommend enabling server.ingress.enabled if you want external access.

Do you want to proceed with default values or customize anything?"

User: "Enable ingress with host argocd.example.com."

3. Plan Approval (The "Nuclear Button")​

The agent generates the installation plan with the custom values and presents it for final sign-off.

Agent: "Here is the execution plan:

  1. Create namespace argocd.
  2. Install release argo-cd with server.ingress.hosts[0]=argocd.example.com.

Safety Check: Cluster connectivity is green.

[APPROVE / REJECT]"

User: "APPROVE"

4. Execution​

The agent executes helm install, waits for pods to become ready, and reports success.

🚑 Scenario 3: Troubleshooting & Recovery​

Objective: Diagnose a crashing pod and fix it.

The Request​

User: "Why is the payment-service crashing?"

1. Investigation (Query Path)​

The agent executes a read-only sequence:

  1. kubectl get pods -> Finds payment-service-5f8c... in CrashLoopBackOff.
  2. kubectl logs --previous -> Reads the crash log.

Log Finding:

panic: FATAL: env var 'STRIPE_API_KEY' not set

2. Remediation Proposal​

Agent: "The pod is crashing because the STRIPE_API_KEY environment variable is missing.

I can check the Deployment definition. Shall I verify if this variable is defined in the env section?"

🧭 Scenario 4: ArgoCD App Onboarding​

Objective: Onboard an application via ArgoCD with plan preview and approvals.

The Request​

User: "Onboard checkout-api from repo github.com/acme/platform at path /apps/checkout into project payments."

1. Prerequisite Checks​

The ArgoCD Orchestrator verifies:

  • Project payments exists.
  • Repo is registered and allowed by the project.
  • Application name is available (or requires update).

2. Plan Preview (HITL Gate)​

Agent: "Here is the plan:

  1. Confirm repo access for github.com/acme/platform.
  2. Create ArgoCD app checkout-api in project payments.
  3. Set destination namespace payments and sync policy manual.

[APPROVE / REJECT]"

User: "APPROVE"

3. Execute + Tool-Level Approval​

The agent runs the MCP calls and requests a final confirmation before the create action.

🔄 Scenario 5: Rollback​

Objective: Revert a failed upgrade quickly.

The Request​

User: "The last upgrade broke the site! Roll it back immediately."

Action​

  1. The agent lists history: helm history my-app.
    • Rev 5: DEPLOYED (Current, Broken)
    • Rev 4: SUPERSEDED (Last Good)
  2. Executes: helm rollback my-app 4.
  3. Verifies: Checks that pods from Rev 4 are running and healthy.

Agent: "Successfully rolled back my-app to revision 4. Pods are stable."