Parlare al cluster Kubernetes con l'AI: sì, si può fare

What is a Kubernetes AI Assistant?

Kubernetes AI Assistants are tools designed to help engineers interact with clusters using natural language, automate troubleshooting, and generate YAML manifests. Popular options include K8sGPT for command-line diagnostics, kubectl-ai for executing cluster operations, and the Headlamp plugin for in-UI debugging. 

Instead of relying only on kubectl commands or manually writing YAML files, Kubernetes AI assistants understand requests like "show me pods that keep restarting," "create a deployment with three replicas," or "why is this service unavailable?" and translates them into Kubernetes commands, manifests, or troubleshooting steps.

These assistants may be integrated into IDEs, terminals, or web dashboards, allowing users to receive context-aware assistance while working with their clusters. Beginners can use them to learn Kubernetes through guided explanations and examples, while experienced operators can automate repetitive tasks, speed up troubleshooting, and efficiently manage complex environments.

The Challenge of Managing Kubernetes Clusters

Complexity and Learning Curve

Kubernetes is a powerful tool for managing containerized applications, but it comes with a steep learning curve. Even experienced developers can find it challenging to grasp all its concepts and components.

One reason for this complexity is that Kubernetes operates at a cluster level, managing not just individual applications but the entire infrastructure. This means that when you want to implement features like logging or monitoring, you have to consider the entire cluster, not just a single application .

Also, managing multiple clusters adds another layer of complexity. Many organizations run several Kubernetes clusters, each requiring coordination and optimization. Without the right tools, managing them can be overwhelming, even for experienced teams.

Traditional Interaction Methods

When you interact with Kubernetes, it involves using the kubectl command-line tool and writing YAML configuration files.

a. Using kubectl

kubectl is the command-line tool for communicating with Kubernetes clusters. It allows users to deploy applications, inspect and manage cluster resources, and view logs.

For example, to list all pods in the default namespace, you would use:

kubectl get pods

While powerful, kubectl commands can become complex, especially for more advanced operations. The users need to remember various flags and parameters, which can be daunting for newcomers.

b. Writing YAML Files

YAML files are used to define the desired state of Kubernetes resources. These configuration files specify how applications should run, including details like the number of replicas, container images, and resource limits.

Here's a simple example of a deployment YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example-container
        image: example-image
        ports:
        - containerPort: 8080

While YAML provides a structured way to define configurations, it has its pitfalls. Indentation errors, incorrect syntax, or using unsupported features can lead to deployment failures. Moreover, managing multiple YAML files for different environments or applications can become cumbersome.

Introducing AI into Kubernetes Management

Artificial Intelligence (AI) is transforming this landscape by enabling natural language interactions with Kubernetes. AI-powered tools can interpret plain English commands and translate them into appropriate Kubernetes operations. For example, instead of typing kubectl get pods, a user can simply ask, "What are the current pods in the production namespace?" and receive an immediate, accurate response.

This abstraction layer reduces the complexity associated with Kubernetes management, making it more accessible to users without deep technical expertise. By using AI, organizations can streamline operations, reduce the likelihood of human error, and enhance overall productivity.

When you integrate AI into Kubernetes management, it offers several advantages:

Improved Efficiency: AI can automate tasks, such as scaling applications or checking resource usage, allowing teams to focus on more strategic activities.

Reduced Errors: By interpreting natural language commands, AI minimizes the risk of syntax errors and misconfigurations that can occur with manual command-line inputs.

Democratization of Cluster Management: AI-powered tools enable individuals without extensive Kubernetes knowledge to manage clusters effectively, broadening the pool of users who can operate and maintain Kubernetes environments.

For example, tools like K8sGPT, Kubiya's Captain Kubernetes etc simplify the Kubernetes management.

How Model Context Protocol (MCP) Enables Kubernetes AI Assistants

The Kubectl Model Context Protocol (MCP)[still in beta] implements the MCP, which is a standardized interface that enables AI assistants to interact with Kubernetes clusters. By translating natural language prompts into executable commands, MCP facilitates seamless communication between users and Kubernetes systems.

Beyond the kubectl MCP, there's also the k8s-mcp-server, which extends MCP's capabilities to support additional tools like helm, istioctl, and argocd.

How MCP Works?

a. Interpretation: The AI assistant interprets the user's natural language input.

b. Translation: MCP converts this interpretation into a corresponding Kubernetes command.

c. Execution: The command is executed within the Kubernetes environment.

Example:

A user say, "Check the status of all pods in the staging environment." The AI, using MCP, would translate this into the appropriate kubectl command and retrieve the requested information. This protocol streamlines interactions, making Kubernetes management more intuitive and accessible.

An implementation of this protocol is the k8s-mcp-server, which acts as a bridge between language models and Kubernetes CLI tools, including kubectl, helm, istioctl, and argocd. 

>> Attend LIVE WEBINAR: From Prompt to MCP: Demystifying AI Native Dev and Ops

Kubernetes AI Assistant Tools Facilitating AI-Powered Kubernetes Interactions

How we selected these tools: We shortlisted Kubernetes AI tools based on natural-language interaction with live cluster state, diagnostics and root cause analysis, Model Context Protocol support, choice of LLM provider including self-hosted models, and safeguards such as read-only modes and approval steps before changes are applied.

Natural Language CLI Assistants

1. K8sGPT

Best for: Scanning clusters and explaining errors in plain English

Strengths: Built-in analyzers, many LLM backends, MCP server, masking

Things to consider: Findings limited to analyzer coverage; config stored in clear

K8sGPT is an open source tool that scans a Kubernetes cluster, triages what it finds, and reports the results in simple English. It codifies SRE experience into a set of analyzers and passes the most relevant details to a language model for enrichment. It runs as a CLI or inside the cluster through the k8sgpt-operator for continuous monitoring alongside Prometheus and Alertmanager.

It works with OpenAI, Azure OpenAI, Google Vertex AI, Amazon Bedrock, IBM watsonx, Cohere, Hugging Face, and local models served by LocalAI or Ollama. From v0.4.14 it also ships a Model Context Protocol server, so an assistant such as Claude Desktop can ask it to analyze a namespace and read back cluster health.

Key features include:

• Analyzer-based scanning: Running k8sgpt analyze executes built-in analyzers for pods, deployments, replica sets, services, ingresses, StatefulSets, jobs, CronJobs, nodes, persistent volume claims, ConfigMaps, and admission webhooks. Optional analyzers cover HPA, PodDisruptionBudget, NetworkPolicy, Gateway API objects, logs, storage, security, and Operator Lifecycle Manager resources.
• Explanations, filters, and documentation: The --explain flag sends findings to the configured model for a plain-English description, and --with-doc attaches the matching Kubernetes documentation. Filters restrict a scan to a resource type or a namespace, results can be written as JSON for pipelines, and k8sgpt analyze -s prints how long each analyzer took.
• MCP server for AI assistants: The command k8sgpt serve --mcp exposes 12 tools, 3 read-only resources, and 3 guided troubleshooting prompts over the Model Context Protocol. Stdio mode suits local assistants, while --mcp-http --mcp-port 8089 opens a stateless HTTP endpoint for network access and webhook integrations.
• Provider management and local models: The k8sgpt auth commands add, list, update, and remove backends and set a default provider. Amazon Bedrock system and application inference profiles are supported by ARN, and a customrest option covers other endpoints, so analysis can run entirely against a model hosted inside the network.
• Anonymization and opt-in remediation: Object names and labels are masked before being sent to an external backend and restored in the answer returned to the user. Analyzers can be enabled selectively, built-in analysis can run with no AI backend at all, and automatic application of fixes is a setting the operator turns on rather than a default.
• Custom analyzers and remote caching: Teams can serve their own analyzer against a published schema, register it with k8sgpt custom-analyzer add, and include it using --custom-analysis, which allows host-level data to be fed into a normal scan. Analysis results can be cached in AWS S3, Azure Blob Storage, or Google Cloud Storage instead of only on the local disk.

Limitations (based on publicly available sources):

• Masking does not cover everything: The project documents that anonymization is not applied to the ReplicaSet, PersistentVolumeClaim, Pod, and Log analyzers, and that event messages are not redacted, so identifying strings can reach an external model. Maintainers recommend a local model for business-critical environments.
• Credentials held in a plain text file: Configuration, including the provider API key, is stored unencrypted in the k8sgpt.yaml config file under the user profile, which shifts key protection onto file system permissions.
• Provider setup is a common failure point: Long-running open issues report 401 errors when calling OpenAI and a message that no provider is configured when Azure OpenAI is set as the backend, indicating that authentication and backend selection can be awkward to get right.
• Analysis speed and noise on busy clusters: Open requests ask for lower latency when a cluster has many errors, for a way to exclude known issues from every report, and for an input flag so saved cluster data can be analyzed without a live connection.

2. kubectl-ai

Best for: Driving kubectl from plain-English requests in a terminal

Strengths: Interactive sessions, wide provider choice, MCP both ways

Things to consider: Not an officially supported Google product

kubectl-ai is an open source assistant published by Google Cloud that sits in front of kubectl and turns a stated intent into cluster operations. It installs as a standalone binary, through krew as a kubectl plugin, or from a container image, and then runs either as an interactive shell or against a single instruction such as fetching logs for an application in a named namespace.

Because it reads from standard input, it composes with other Unix commands, so a log file can be piped in with a prompt asking for an explanation. Sessions can be created, listed, resumed, and deleted to carry context between runs, and behaviour is set through flags, environment variables, or a YAML config file.

Key features include:

• Tool-driven cluster operations: The assistant works through tools rather than free text alone, shipping with kubectl and bash built in. Confirmation for commands that modify resources is on by default and only bypassed by setting skipPermissions, and a maxIterations value caps how many steps the agent takes on one task.
• Interactive and scripted use: Interactive mode keeps context across a sequence of questions until the session is exited, while --quiet runs a single task for scripts and pipelines. A positional argument can act as a prefix to piped input, which is how a stack trace or log file gets combined with a question.
• Wide model provider support: Providers include Gemini as the default plus Vertex AI, OpenAI, Azure OpenAI, Grok, and AWS Bedrock, along with local serving through Ollama and llama.cpp. A tool-use shim covers models that need extra prompting to call tools, and a modelserving directory documents hosting a model on the cluster itself.
• MCP client mode: Starting with --mcp-client lets the assistant use tools from external MCP servers listed in mcp.yaml, including local stdio servers launched by command and remote HTTP servers with bearer token authentication. Parameter names and types are converted automatically for servers it does not recognise.
• MCP server mode with tool aggregation: The --mcp-server flag turns it into an MCP server that exposes Kubernetes tools to clients such as Claude, Cursor, and VS Code, and --external-tools additionally republishes tools discovered from other MCP servers through one endpoint. A streamable HTTP transport serves clients on a chosen port.
• Authentication and interface options: The HTTP endpoint can be turned into an OAuth 2.1 resource server that validates bearer tokens against an authorization server's JWKS, with an audience value that binds a token to that server. A web interface is available by setting the UI type, and custom tools are declared in tools.yaml.

Limitations (based on publicly available sources):

• HTTP endpoint open unless configured: The project states that the streamable HTTP endpoint is unauthenticated by default, meaning anyone able to reach the port can run kubectl and bash through it until an issuer and audience are configured.
• No official support commitment: The repository notes that this is not an officially supported Google product and that it is not covered by Google's open source vulnerability rewards programme, which affects how teams treat it in production.
• Provider-specific defects: Open bug reports cover malformed responses from the Bedrock provider, an MCP server that does not work as expected, and JSON parsing errors when streaming from an Ollama-hosted model.
• Documentation gaps around extensibility: Maintainers have an open request for example configurations for custom tools, so teams extending the tool set have limited reference material to work from.

3. Kube-Copilot

Best for: Diagnosing pods and generating manifests from prompts

Strengths: Analyze, audit, diagnose, execute, and generate commands

Things to consider: Small project that depends on local kubectl and trivy

Kube-Copilot is an open source command line assistant that applies a language model to routine cluster work. It exposes five commands: analyze issues for a resource, audit a Pod for security problems, diagnose a Pod, execute operations from written instructions, and generate manifests. Rather than reimplementing cluster access it calls the native kubectl and trivy binaries.

It is configured with environment variables and works with OpenAI, Azure OpenAI, Anthropic Claude, Google Gemini, Ollama, and other OpenAI-compatible endpoints by pointing the API base at them. Flags set the model, token ceiling, agent iteration limit, token counting, and verbose output. A separate Python implementation of the same project is also published.

Key features include:

• Resource analysis: The analyze command takes a resource type, name, and namespace and reports potential problems with that object. It defaults to pods but accepts other resource types, and the agent iteration and token limits are adjustable per invocation so longer investigations can be allowed where needed.
• Security auditing of pods: The audit command inspects a Pod for security issues and depends on trivy being installed locally, which is how container image vulnerabilities are assessed. This keeps scanning on the operator's machine and reuses an established scanner instead of a bundled implementation.
• Pod diagnosis: The diagnose command investigates problems for a named Pod in a namespace and accepts an MCP configuration file, so external tools can be consulted during the investigation. It is aimed at the common case of a workload that will not start or keeps restarting.
• Prompt-driven execution: The execute command carries out operations described in an instructions string and can also answer general questions about the cluster. Like diagnose, it accepts an MCP configuration file, which is how it reaches tools beyond kubectl during a multi-step task.
• Manifest generation with confirmation: The generate command turns a written prompt into Kubernetes manifests, for example a deployment running a set number of replicas of an image, and then asks whether the generated manifests should be applied. That prompt keeps a human decision between the model output and the cluster.
• MCP tool integration: Passing --mcp-config with a JSON file listing MCP servers makes their tools available to the model automatically. The documented examples include a sequential thinking server for step-by-step analysis and a Kubernetes MCP server launched through uvx.

Limitations (based on publicly available sources):

• Narrow maintainer base: The repository has roughly 236 stars and 31 forks with commits driven largely by one maintainer, so response times and long-term direction depend on a single contributor.
• External binaries required: Both kubectl with a working kubeconfig and, for the audit command, trivy must be installed on the machine, which adds setup steps and version drift to manage.
• Reported setup and output problems: Closed issues cover failures when analyzing any resource, a Helm installation returning a 404, formatting problems in model output, and credential errors when configuring Azure OpenAI.
• Conservative token defaults: The default token limit of 2048 for model responses is low for large manifests or long log excerpts, so the flag often has to be raised for real investigations.

MCP Servers for Conversational Cluster Access

4. Kubernetes MCP Server

Best for: Giving AI assistants native access to Kubernetes clusters

Strengths: Direct API access, multi-cluster, toolsets, read-only mode

Things to consider: Reported to stall on large clusters with many CRDs

Kubernetes MCP Server is an open source Model Context Protocol server for Kubernetes and OpenShift. It is written in Go and talks to the API server directly instead of shelling out to kubectl or helm, so no external tooling has to be present on the host. It is distributed as a single binary for Linux, macOS, and Windows plus npm, Python, and container packages, and a Helm chart.

Clients including Claude Code, Claude Desktop, VS Code, Cursor, and Goose connect over stdio, or over streamable HTTP and Server-Sent Events when the server is started with a port. It detects kubeconfig changes and updates itself, and can address several clusters at once by adding a context argument to each tool.

Key features include:

• Generic resource operations: Tools cover create or update, get, list, delete, and scale for any Kubernetes or OpenShift resource identified by apiVersion and kind, including custom resources. Creation and update use server-side apply with the full desired state, and list calls accept both field selectors and label selectors.
• Pod and node level access: Dedicated tools list pods across or within namespaces, fetch a pod, read logs including previous container logs, execute a command in a container, run an image as a new pod, delete a pod, and report CPU and memory usage. Node tools return kubelet logs, resource statistics, and pressure stall information.
• Toolsets that control exposure: Configuration and core toolsets are enabled by default, with optional sets for Helm, kcp workspaces, Kiali, KubeVirt, NetObserv, and Tekton. Enabling only what is needed reduces the context sent to the model and improves which tool it picks for a request.
• Safety and access controls: A read-only mode blocks all write operations, a separate flag disables destructive operations only, and a TOML configuration can deny whole resource kinds such as Secrets. HTTP mode supports OAuth and OIDC against providers including Keycloak and Microsoft Entra ID, and sensitive values are redacted from client-facing logs.
• Ecosystem tooling beyond core Kubernetes: Helm tools install, list, and uninstall releases. Tekton tools start pipelines and tasks and retrieve run logs. Kiali tools return mesh status, traffic graphs, Istio and Gateway API configuration, traces, and pod performance. KubeVirt tools create, clone, and manage virtual machine lifecycles.
• Prompts, observability, and deployment: Guided prompts include a cluster health check and Istio, KubeVirt, and Tekton troubleshooting flows. Optional OpenTelemetry tracing and metrics with configurable sampling are exposed together with a statistics endpoint, and configuration can be reloaded on signal or split across drop-in files.

Limitations (based on publicly available sources):

• Initialization problems on large clusters: An open issue reports the server hanging during initialization on production EKS clusters that carry a large number of custom resources, and a maintainer-filed issue notes the cluster health check prompt timing out against real clusters.
• Coarse read-only controls: Read-only behaviour is applied as a whole-server setting, and an open enhancement request asks for granular read-only permissions so specific operations can be allowed while others stay blocked.
• Multi-cluster targeting is not enforced: With several clusters configured, the context argument is optional, and an open issue asks for it to be required when more than one cluster is detected so that a request cannot land on the wrong cluster.
• Rough edges in write operations: Open issues include a missing namespace in the create or update tool and a planned rework of the resources API to align better with the MCP specification, so write paths are still changing.

5. Trivy MCP Server

Best for: Asking security questions about code, images, and repos

Strengths: Natural-language scans in the IDE, Aqua Platform option

Things to consider: Scans projects and images, not live cluster state

Trivy MCP Server is a plugin for Aqua Security's Trivy scanner that starts a Model Context Protocol server so an AI assistant can run security scans. It is installed with trivy plugin install mcp and started with trivy mcp, after which a developer can ask whether a project contains vulnerabilities or misconfigurations instead of assembling scan commands and reading report files.

It supports three scan targets: the local filesystem for a project, container images, and remote repositories. Transport options are stdio, streamable HTTP, and Server-Sent Events, and it connects to VS Code, Cursor, JetBrains IDEs, and Claude Desktop. An optional connection to the Aqua Platform adds policy checks.

Key features include:

• Natural-language scanning: Questions asked in an IDE chat are translated into Trivy scans and the findings are returned in the same conversation, so a question about vulnerabilities or misconfigurations in the current project does not require knowing the command syntax or output flags.
• Filesystem scanning of projects: A local directory can be scanned for vulnerabilities in dependencies and for misconfigurations in files it contains, which is the path most often used while code is being written and dependency manifests are changing.
• Container image scanning: Container images can be scanned for vulnerabilities through the same interface, which covers the artifact that will actually be deployed rather than only the source tree it was built from.
• Remote repository analysis: A remote repository can be analyzed for security problems without cloning it first, which is useful when assessing a dependency or a service owned by another team before adopting it.
• Flexible transports and IDE coverage: The server runs over stdio for local clients and over streamable HTTP or Server-Sent Events where a network endpoint is needed, and documented integrations cover VS Code, Cursor, JetBrains IDEs, and Claude Desktop.
• Optional Aqua Platform integration: Authenticating with an Aqua key and secret connects the server to the Aqua Platform for additional scanning and assurance policy compliance, which allows questions about whether a project breaches enterprise policy to be answered directly.

Limitations (based on publicly available sources):

• No live cluster queries: The documented scan targets are the local filesystem, container images, and remote repositories, so questions about the current state of a running cluster fall outside its scope and need a separate Kubernetes MCP server.
• Small project surface: The repository holds roughly 45 stars and 9 forks with a small commit history, and it is a plugin on top of Trivy rather than a separately supported product.
• Connection and documentation defects: Open issues report the SSE endpoint advertising 0.0.0.0 rather than the requested host, which causes clients to reject the connection, and login flags that no longer match the documented instructions.
• Suppression handling still requested: Adding entries to an ignore file and applying Aqua suppressions from the assistant remain open feature requests, so tuning noisy findings happens outside the conversation.

6. Testkube AI

Best for: Running and querying Kubernetes tests from AI tools

Strengths: MCP server over the whole API, event-driven test agents

Things to consider: Agents are paid tiers and AI authoring has not shipped

Testkube AI is the AI layer of Testkube, a test orchestration platform that runs tests inside Kubernetes clusters. It has three parts: an MCP server that exposes the platform API to AI tools, agents that react to test workflow events, and AI authoring that turns a described scenario into a runnable test. The MCP server and agents are available, and authoring is listed as coming soon.

Because the AI layer sits inside the testing platform, answers draw on the team's own execution history, logs, and artifacts rather than general knowledge. Tests continue to execute in the user's own clusters, OpenAI and Anthropic models are supported with more being added, and cloud customers can supply their own model.

Key features include:

• MCP server across the platform API: Testkube exposes its full API surface as an MCP server, so Claude, Cursor, Copilot, or another compatible client can run any test workflow and read results without leaving that tool. It connects to an existing Testkube installation and does not require new infrastructure to be stood up.
• Plain-language queries over test history: Execution history, logs, and failure details can be queried conversationally, which covers questions about which tests failed, when, and what the failure output was. Answers are grounded in the recorded executions of the environment rather than inferred.
• Event-driven AI agents: Agents are built against test workflow outcomes and trigger automatically when those events occur, so an investigation starts without a person initiating it. Agents run failure analysis using logs, artifacts, and environment context and continue working after a chat session ends.
• Automated reporting and reruns: Structured summaries are posted to Slack, Jira, or any webhook so results land where the team already works. A smart rerun capability re-executes tests to separate genuine failures from flaky ones before a summary is published.
• Framework-agnostic execution: The AI layer works on top of existing test workflows, so suites already running through Testkube with Playwright, k6, Postman, or pytest are covered without migration or changes to how tests are organized. Generated tests execute immediately in real infrastructure.
• Model choice and data handling: The model is selected in the Testkube interface, and cloud customers can bring their own model and pay their provider directly, which addresses licensing and data residency requirements. Test artifacts and results stay in the user's infrastructure while metadata such as logs and failure summaries goes to the configured provider.

Limitations (as reported by users on G2):

• No access control in local installs: A reviewer notes that a locally installed Testkube has no role-based access control, so separate users with different dashboard permissions cannot be created in that deployment model.
• Weak chaos testing and failure debugging: A reviewer describes chaos injection as inefficient and reports that failure simulation was not captured well, and asks for breakpoint debugging in the console to show the exact point of failure during a load test.
• Cost at larger scale: A reviewer comments that pricing may be high for a large organization, and the AI agents and authoring capabilities sit in the paid Pro and Enterprise tiers rather than the open source edition.
• Thin review evidence: With four reviews on the platform, there is limited independent feedback available on the AI features specifically, most of which shipped after those reviews were written.

Agentic AI Platforms for Cluster Operations

7. kagent

Best for: Running and governing AI agents as Kubernetes workloads

Strengths: Agents as CRDs, MCP and A2A support, OpenTelemetry traces

Things to consider: CNCF Sandbox project still under active development

kagent is a Kubernetes-native runtime for AI agents that was created at Solo.io and is now a CNCF Sandbox project. Agents, sessions, and tools are custom resources, so they are declared in YAML, versioned in Git, reviewed in pull requests, and rolled out with kubectl and GitOps in the same way as other workloads. It installs from a single Helm chart.

It ships MCP tool servers for cluster tooling such as kubectl, Prometheus, Argo CD, and GitHub, supports Go and Python runtimes, and orchestrates external frameworks including LangGraph, CrewAI, and Google ADK. Documented uses include incident triage, observability queries, platform self-service, and multi-agent workflows.

Key features include:

• Agents defined as custom resources: An agent is written as a CRD that points at a model, attaches the tools it needs, and names the cluster it runs in, then applied with kubectl. The controller provisions the runtime, wires up RBAC, and registers the agent with the service mesh, so lifecycle management uses existing cluster workflows.
• MCP tool layer for cluster access: Tools are exposed through MCP servers registered as resources and shared across agents, covering kubectl, Prometheus, Argo CD, GitHub, PagerDuty, and documentation sources. Because the interface is MCP, internal REST or gRPC APIs and databases can be added with a declarative spec.
• Agent-to-agent delegation: Agents discover and invoke one another over the Agent-to-Agent protocol, which allows a chain where one agent triages, another investigates, and a third remediates. The same protocol connects agents to chat channels including Slack, Discord, and Telegram.
• Human-in-the-loop controls: Tool approval gates require a person to authorise an action before it runs, agents can put questions back to a human, and approvals can cascade through a multi-agent flow. Combined with mesh-level mTLS, RBAC, and policy-driven egress, this keeps existing security controls in the path.
• Memory and context management: Persistent vector-backed memory carries context across sessions, automatic summarization compacts long histories so conversations stay coherent within token budgets, markdown knowledge such as runbooks is loaded from Git at startup, and reusable prompt fragments come from ConfigMaps.
• Runtime, storage, and observability: The Agent Substrate runtime uses a worker pool and actor model for fast starts, low overhead, and sandboxed isolation per agent, with Postgres-backed storage and reviewable migrations. Every prompt, tool call, and token emits OpenTelemetry traces alongside Prometheus metrics and structured logs.

Limitations (based on publicly available sources):

• Sandbox maturity: The project describes itself as a CNCF Sandbox project in active development with a public roadmap, and third-party write-ups suggest starting in a development or staging cluster before introducing agents to production.
• User-level authorization outstanding: An open feature request asks for user RBAC authorization in kagent, so restricting which people can use which agents is not yet handled inside the platform.
• Credential exposure question open: An open issue asks whether it is safe that a sandboxed agent process environment can contain real credentials when environment resolution is used, and that question has not been closed.
• Backlog churn: Several requests, including context window management and conversation summarization support and container signing, have been marked stale, and behaviour still depends heavily on the latency and token limits of the chosen model provider.

8. HolmesGPT

Best for: Investigating incidents across logs, metrics, and traces

Strengths: Many built-in toolsets, agentic loop, read-only by design

Things to consider: Read-only, so applying fixes needs extra integrations

HolmesGPT is an open source agent for investigating production incidents and a CNCF Sandbox project, created by Robusta.Dev with contributions from Microsoft. It runs an agentic loop that queries live observability data from several sources and works out likely root causes. It is not restricted to Kubernetes and also covers virtual machines, cloud services, databases, and SaaS platforms.

An operator mode runs health checks continuously in the background, reports problems in Slack, and with the GitHub integration can open pull requests for issues it finds. Health checks can be deployed alongside an application to verify a new version. By design it has read-only access and respects existing RBAC.

Key features include:

• Agentic investigation loop: Rather than answering from a single snapshot, the agent issues successive queries against connected data sources, narrowing down from an alert or a plain-text question to a probable cause. Investigations can be started from free text or from structured input such as a Prometheus alert.
• Large catalogue of built-in toolsets: Built-in data sources include Kubernetes pod logs, events, and resource status, Prometheus, Grafana, Loki, Datadog, Elasticsearch and OpenSearch, Coralogix, Tempo, VictoriaMetrics and VictoriaLogs, Kafka, RabbitMQ, MongoDB, SQL databases, Argo CD, Helm, Crossplane, AKS, Azure SQL, and cloud provider APIs, with any REST API addable.
• Bidirectional alert and ticket integrations: Alerts and tickets can be pulled from Alertmanager, PagerDuty, OpsGenie, and Jira for investigation, and the resulting analysis written back to the source or to Slack. That closes the loop between where an alert is raised and where the finding is recorded.
• Operator mode and scheduled checks: In operator mode the agent runs in the background around the clock, spots problems without being triggered, and messages Slack with what it found. Scheduled health checks monitor services for regressions and deployment verification checks confirm that a newly released version is healthy.
• Handling large telemetry volumes: Server-side filtering, JSON tree traversal, and tool output transformers keep large payloads out of the model context window. Per-tool memory limits, streaming of large results to disk, and automatic output budgeting are used to avoid the process being killed when querying big observability datasets.
• Model choice and read-only posture: Supported providers include OpenAI, Anthropic, Azure, Bedrock, and Gemini, and models can run locally or inside the cluster where data must not leave the environment. Access is read-only by design and RBAC permissions are respected, which is how the project positions it for production use.

Limitations (based on publicly available sources):

• Investigation without direct remediation: Read-only access means the agent reports findings rather than applying them, so changing the cluster requires the separate Kubernetes remediation toolset, the GitHub pull request path, or manual action.
• Some integrations depend on Robusta: The project lists Slack and Microsoft Teams end-to-end automation as available through Robusta, the commercial product behind it, while PagerDuty, OpsGenie, Jira, and GitHub integrations are documented as CLI only.
• Provider and parsing defects: Open bug reports include an unsupported parameters error on the final model call when using Bedrock and a type error concatenating a dictionary to a string, indicating provider-specific rough edges.
• Configuration and documentation gaps: A long-standing request asks for a way to specify which Kubernetes context to use, and other open issues cover documentation for OpenSearch traces and support for multiple Argo CD instances.

9. Komodor

Best for: Enterprise Kubernetes troubleshooting with guided analysis

Strengths: Agentic root cause analysis over cluster change history

Things to consider: SaaS only, priced for larger teams, dense interface

Komodor is a commercial Kubernetes management platform, and Klaudia is the agentic AI layer that powers it. Klaudia handles detection, investigation, remediation, and optimization, correlating logs, historical changes, and Kubernetes events to identify a root cause and set out remediation steps. It is activated with a toggle rather than an additional installation.

Hundreds of specialized workflow and subject matter agents run under an orchestration layer that calls different agents as an investigation develops, with or without a person in the loop. Klaudia runs on AWS Bedrock, Komodor states that customer data is not used for training, and the platform lists SOC 2 Type 2, GDPR, CCPA, and HIPAA compliance.

Key features include:

• Agentic root cause analysis: Klaudia uses retrieval over Komodor's own investigation data, internal knowledge, and expert prompts in a multi-layered process intended to keep answers grounded and reduce hallucinations. It draws on logs, historical changes, events, and metrics rather than a single point-in-time view of the cluster.
• Cascading failure identification: Because Kubernetes failures often propagate across dependent services, Klaudia reports not only what went wrong but which interconnected services are affected and where the origin lies, which is aimed at incidents that surface in several places at once.
• Interactive follow-up through KlaudiaChat: KlaudiaChat allows follow-up questions against a completed analysis, so a static root cause report becomes a conversation where extra context can be requested. Answers draw on the same knowledge base used for the original investigation.
• Extensible workflow and expert agents: Workflow agents handle detection, investigation, remediation, and optimization, while subject matter agents cover specific domains, and the architecture supports adding further agent types including ones based on custom resources. Agents run continuously and can act with or without human approval.
• Platform context around the agent: Klaudia sits inside a wider platform covering visualization and insights, troubleshooting, continuous reliability, and cost and performance optimization, which is where the change history, fleet view, and access controls that ground its answers come from.
• Security and deployment model: The agent is built on AWS Bedrock, requires no intrusive installation, and is enabled per environment with a toggle. Komodor states that customer data is never used for training and that the agent does not transfer personal or sensitive data, with controls over what is uploaded.

Limitations (as reported by users on G2):

• Pricing pressure on smaller teams: Several reviewers describe the cost as high, particularly for small teams and startups, and one reviewer objected strongly to the removal of the free tier and the price of the paid plan that replaced it.
• Interface density: A recurring criticism is that the interface feels cluttered and overwhelming, with reviewers reporting that it takes practice to know where to look and that cost reports in particular could be more intuitive.
• Kubernetes knowledge still needed: Reviewers note a learning curve for teams unfamiliar with Kubernetes or DevOps workflows, and one describes the platform as still oriented towards operations engineers rather than application developers.
• Integration and data retention gaps: Reviewers ask for deeper integration with multiple cloud providers to handle cases such as reserved instances and Fargate, more plug-and-play integrations, and longer retention of logs for pods that have been deleted.
• Delivery model and signal quality: One reviewer notes that on-premises installation is not offered because the product is SaaS, and another reports that AI-based insights are sometimes irrelevant and add noise.