AIOps CLI for Kubernetes and Cloud Incidents: Practical Clanker Workflows

When production breaks, the first problem is rarely "we need a prettier dashboard." The first problem is usually context. Which pod is failing? Which deploy changed? Which region is affected? Which cost line item moved? Which public endpoint is exposed?

The open-source Clanker CLI is built for that first loop. It gives operators and agents a terminal-native way to ask live infrastructure questions, inspect Kubernetes and cloud state, and produce reviewed plans before making changes.

Clanker Cloud uses the same engine in a desktop workspace. But the CLI is useful on its own, especially for incident workflows where speed, auditability, and local credentials matter.

---

Workflow 1: Ask a Live Infrastructure Question

The fastest AIOps workflow is a grounded question against real infrastructure state.

clanker ask "what's the status of my chat service lambda?" | cat

Or with a specific AWS profile:

clanker ask --profile prod "what's the last error from my api lambda?" | cat

This is not a static chatbot answer. The CLI routes the request, pulls provider state through local credentials, and uses the configured AI provider to summarize what matters.

For teams running Clanker Cloud, this same loop appears in the desktop app with saved context, visual topology, and longer-running workflows. The CLI is the fast path; the app is the collaborative workspace.

---

Workflow 2: Debug Kubernetes Without Command Archaeology

Kubernetes incidents often start with command archaeology: kubectl get pods, then describe, then events, then logs, then metrics, then a context switch to the cloud console.

Clanker CLI provides a natural-language Kubernetes path:

clanker k8s ask "why is my pod crashing" | cat
clanker k8s ask "which pods are using the most memory" | cat
clanker k8s ask "show me warning events from the cluster" | cat

The k8s ask workflow uses a staged pipeline: decide which kubectl operations are needed, execute them, then synthesize the results into a readable response. Follow-up questions can reuse context for the same cluster.

For a live incident, that matters. The operator does not need to remember the exact command sequence for every failure mode. The CLI can gather the raw evidence and explain the likely next step.

---

Workflow 3: Inspect Security Drift

Security scanning is often treated as a separate compliance task. In practice, it belongs inside day-to-day operations. Public APIs, IAM blast radius, missing auth, and exposed databases are production health issues.

Clanker CLI includes a security command for best-effort provider-side inspection:

clanker security | cat

You can scope the scan to a concern:

clanker security "review public APIs, IAM blast radius, and auth gaps" | cat

Or pin provider context:

clanker security --profile prod --gcp-project my-gcp-project --workspace prod | cat

This gives teams a local, scriptable way to run recurring checks without moving credentials into a hosted scanner. Clanker Cloud expands the same idea into richer security views and Deep Research scans across connected infrastructure.

---

Workflow 4: Investigate Cost Spikes Before Optimizing

Cost optimization starts with attribution. A bill increase is not actionable until you know which resources, tags, regions, or workloads changed.

With the CLI, operators can start with direct questions:

clanker ask --aws "what services increased spend this week?" | cat
clanker ask "which Kubernetes workloads look oversized?" | cat

The useful pattern is not "auto-delete waste." The useful pattern is evidence first: identify the resource, understand its owner, check whether it was tied to a deploy, and then decide what to change.

Clanker Cloud's AWS cost spike use case takes this further by placing spend movement next to topology and recent changes. The CLI gives terminal-first teams the same open-source investigation starting point.

---

Workflow 5: Generate a Reviewed Plan

AIOps should not jump from "I found a problem" to "I changed production." The safer bridge is a plan.

Clanker CLI's maker mode generates a JSON plan before execution:

clanker ask --aws --maker "create a small ec2 instance and postgres rds" | cat

That output can be reviewed by a human, attached to a ticket, checked into a PR, or passed through another approval step.

Only after review do you apply it:

clanker ask --aws --maker --apply --plan-file plan.json | cat

Destructive operations require --destroyer, which keeps deletion intent explicit:

clanker ask --aws --maker --destroyer "delete the staging rds instance" | cat

This is the CLI-level version of Clanker Cloud's review-before-execution model.

---

Workflow 6: Let Agents Ask, Without Giving Them Raw Credentials

Teams increasingly want AI agents to help with infrastructure work. The mistake is giving an agent direct cloud credentials and hoping it behaves.

Clanker CLI gives agents a narrower tool surface through MCP:

clanker mcp --transport http --listen 127.0.0.1:39393 | cat

An MCP-capable agent can call Clanker tools locally, route infrastructure questions, and run approved CLI commands without owning the underlying credential configuration itself.

This is where the CLI and Clanker Cloud line up cleanly. The CLI exposes a terminal-native MCP surface. The desktop app exposes an app-aware MCP workspace with saved settings and richer context. Both keep the operational boundary local.

---

When to Use CLI vs Clanker Cloud

Use the CLI when you need:

• Scriptable incident checks.
• CI/CD or GitHub Actions integration.
• Terminal-first debugging.
• A local MCP server for agents.
• Auditable open-source behavior.

Use Clanker Cloud when you need:

• Visual topology and resource context.
• Multi-provider investigation in one workspace.
• Deep Research across a full estate.
• Saved model and provider configuration.
• A better human review surface for plans and findings.

They are not competing paths. Clanker Cloud is powered by the same open-source engine, so the workflows transfer.

---

Start with One Incident Query

Install the CLI from github.com/bgdnvk/clanker, connect the provider you already use, and ask one real question:

clanker ask "what looks unhealthy in production?" | cat

That is the smallest useful AIOps loop: live state, local credentials, clear answer.

When the workflow needs a broader view, open Clanker Cloud and bring the same engine into the desktop workspace.