Walkthrough

Note: This walkthrough uses direct helm install commands for clarity. In production, manage these releases through your GitOps pipeline (Argo CD, Flux).

Prerequisites

• A Kubernetes cluster with kubectl access and permission to create namespaces, ClusterRoleBindings, and Secrets
• Helm 3 installed locally
• An LLM provider API key exported in your shell (the demo uses an OpenAI-compatible endpoint via OPENAI_API_KEY)
• git installed — as of this recording, the AURA Helm chart is not hosted, so you install it from a clone of the repo
• Optional: the AURA quickstart guide OTel demo environment, which the upstream example values target

Step 1: Clone the AURA repository

The chart lives in the repo under deployment/helm/aura:

git clone https://github.com/mezmo/aura.git

Step 2: Prepare the AURA values file

Start from the example at examples/quickstart-k8s-sre/aura-values.yaml in the repo. It ships configured for the OTel demo environment with Kubernetes and Prometheus MCP servers and two workers (cluster_inspector, metrics_analyst).

This walkthrough uses a trimmed version — one Kubernetes MCP server and one worker — so that later videos can demonstrate adding an MCP server and worker incrementally. The AURA config is embedded as TOML under config.content:

config:
  content: |
    memory_dir = "/tmp/aura-orchestration"

    [mcp]
    sanitize_schemas = true

    [mcp.servers.kubernetes]
    transport = "http_streamable"
    url = "http://kubernetes-mcp-server.kubernetes-mcp-server.svc.cluster.local:8080/mcp"
    description = "Kubernetes cluster operations: pods, deployments, services, nodes, logs, events"

    [mcp.servers.kubernetes.scratchpad]
    "*" = { min_tokens = 5180 }

    [agent]
    name = "Kubernetes SRE Agent"
    alias = "kubernetes-sre"
    system_prompt = """
    You are a Kubernetes SRE coordinator.

    - Use cluster_inspector for pod status, deployments, logs, events, and node health.

    Always specify namespaces explicitly.
    Prefer read-only operations unless the user explicitly requests changes.
    """
    turn_depth = 20

    [agent.llm]
    provider = "openai"
    api_key = "{{ env.OPENAI_API_KEY }}"
    base_url = "https://inference.baseten.co/v1"
    model = "deepseek-ai/DeepSeek-V4-Flash-0731"
    context_window = 200_000

    [agent.scratchpad]
    enabled = true
    context_safety_margin = 0.20
    max_extraction_tokens = 10_000
    turn_depth_bonus = 6

    [orchestration]
    enabled = true
    max_planning_cycles = 2
    quality_threshold = 0.7
    allow_direct_answers = true
    allow_clarification = false
    tools_in_planning = "summary"

    [orchestration.timeouts]
    per_call_timeout_secs = 120

    [orchestration.worker.cluster_inspector]
    description = "Kubernetes cluster inspection: check pod status, read logs, list deployments and services, review events, assess node health"
    turn_depth = 10

    mcp_filter = [
      "configuration_view",
      "events_list",
      "namespaces_list",
      "nodes_log",
      "nodes_stats_summary",
      "nodes_top",
      "pods_get",
      "pods_list",
      "pods_list_in_namespace",
      "pods_log",
      "pods_top",
      "resources_get",
      "resources_list",
    ]
    preamble = """
    You are a Kubernetes cluster specialist. Use the available tools to inspect
    cluster state: check pod health, read logs, list deployments and services,
    review events, and assess node status.

    Always specify namespaces explicitly. Report findings with specific resource
    names, namespaces, and status conditions.
    """

Step 3: Install the AURA Helm chart

Install from the cloned repo, creating a dedicated namespace and passing the LLM API key as a Secret from your environment:

helm install aura ./aura/deployment/helm/aura \
  -n aura --create-namespace \
  -f aura-values.yaml \
  --set secrets.openaiApiKey="$OPENAI_API_KEY"

Step 4: Install the Kubernetes MCP server

The Kubernetes MCP server comes from the containers org on GitHub (the maintainers of Podman) and is hosted as an OCI chart, so no clone is required. The values file below runs it in read-only mode — enforced both by RBAC (the built-in view ClusterRole, which has no Secrets access) and by the --read-only startup flag — and disables Ingress, since AURA runs on the same cluster:

fullnameOverride: kubernetes-mcp-server

image:
  registry: ghcr.io
  repository: containers/kubernetes-mcp-server
  version: v0.0.66

rbac:
  create: true
  extraClusterRoleBindings:
    - name: view
      roleRef:
        name: view
        external: true

extraArgs:
  - --read-only

ingress:
  enabled: false

Install it into its own namespace:

helm install kubernetes-mcp-server oci://ghcr.io/containers/charts/kubernetes-mcp-server \
  --version 0.1.0 \
  -n kubernetes-mcp-server --create-namespace \
  -f kubernetes-mcp-server-values.yaml

Step 5: Verify both rollouts

kubectl rollout status deployment -n kubernetes-mcp-server
kubectl rollout status deployment -n aura

Both should report successfully rolled out.

Step 6: Connect to AURA and run a smoke test

If you exposed AURA, the AURA CLI can connect to it from anywhere. The simplest path for a first session is to exec into the pod and point the bundled CLI at the local server:

kubectl exec -n aura -it deploy/aura -- ./aura --api-url http://localhost:8080

To exercise both the LLM provider and the MCP tooling in one pass, ask for a cluster status check:

Check every pod in the ruleprod-apps namespace and tell me which are not Ready.

In the demo, the cluster_inspector worker inspected all 11 pods in the namespace, confirmed every pod Ready, and flagged a finding worth attention: two frontend pods each carrying 24 restarts with OOMKilled (exit code 137) against a 128Mi memory limit — Ready at inspection time, but a stability concern to investigate.

Next Steps & Docs

• Move the release into your GitOps repo (Argo CD or similar) so the deployment is declarative and repeatable
• Add further MCP servers (Prometheus, Grafana) and workers to broaden investigation coverage — to be covered in the next video in this series
• AURA GitHub repository — chart, example values, and quickstart
• AURA Documentation — configuration reference and MCP server catalog

Installing AURA into a Kubernetes cluster

0:00 Hello everyone. Today I'll be showing you how to install AURA into a Kubernetes cluster. We'll be doing this in a local demo kind cluster that's running some demo workloads.

Installing the Kubernetes MCP server with Helm

0:16 We'll start by running this script to install the Kubernetes MCP using helm.

Installing AURA with Helm and reviewing the values

0:32 Next, we'll install AURA, also using helm. Here are the Helm values. You can see this is a basic Kubernetes agent connecting to the in-cluster Kubernetes MCP server.

Connecting with the AURA CLI over a port forward

1:01 Next, we'll connect to AURA using the AURA CLI and a Kubernetes port forward.

Asking the agent what is running and getting a root cause

1:15 Now that we're connected, we can ask things of the agent like what apps are running in my cluster. AURA finds the issue: the payment service is in an error state. We'll ask it to dig into this.

Where a long-running install leads

2:05 In just a few minutes, we installed AURA on our cluster, were able to ask it questions about it, and get a root cause analysis on an issue with one of our services. Installing AURA as a long-running service is the first step to integrating it into our incident response workflows, such as getting an automated RCA on new incidents or connecting to Slack.