kubectl-ai Roadmap

[droot]

Hi Everyone, Thanks to you all, our project is off to a such a great start. It's been great to see so much enthusiasm and positive energy all around. I think we have an opportunity to build something really special here. To keep the momentum going, I am sharing an early draft of the roadmap for the project to seek feedback on the priorities.

Roadmap

kubectl-ai is an AI-powered assistant for kubernetes and associated cloud infrastructure. It should be be able to:

• Answer questions related to kubernetes concepts
• Answer questions related to resources in a kubernetes cluster and associated cloud.
• Perform operations that involves creating/updating/deleting one or more resources in a cluster and associated cloud
• Troubleshoot a mis-configuration or unexpected behavior in a kubernetes cluster

P0: Bugs

Anything that prevents using kubectl-ai should be addressed first. Unblocking usage is the key to making something people want. Issues that are identified as bugs will be labelled with the label bug.

P0: Tools Extensibility (bring your own tools: BYOT)

kubectl-ai uses built-in tools such as kubectl and bash. One of the big advantages of using kubernetes is the rich ecosystem of tools and we have observed users use multiple tools (OSS and in-house tools) to accomplish k8s related tasks. We are also observing that MCP (model context protocol) has become a standard way to discover and call external tools.

Example CUJs:

• Respond to a github issue containing kubernetes related troubleshooting query (requires kubectl and github mcp server or gh custom tool)
• Install a helm chart and verify the resources (requires helm and kubectl)
• Estimate the current costs of all the nodes in a cluster (requires using kubectl and (gcloud/aws/az).
• Create a gke cluster and deploy nginx app in web namespace (terraform, kubectl)

kubectl-ai should:

• [ ] Support plugging in additional tools
• [ ] Support integration with MCP servers.
• [ ] Rich evals to evaluate performance of using additional tools as well tools exposed by MCP servers.

P0: K8s-bench

An agent is as good as the evals. Our current evals are saturated especially with Gemini 2.5 pro and we need evals that represent user realistic scenarios and also represents complexity of today’s cloud infrastructure.

K8s-bench should:

• [ ] Have well defined guidelines and instructions for adding evals.
• [ ] Periodically publish evals for top models (starting with Gemini at least).
• [ ] 10 evals per category of CUJ. Categories are – troubleshooting, creating/updating/deleting resources, operations involving kubectl commands and other tools, fixing mis-configuration, and answering questions related to resources.
• [ ] Sufficient hard evals to ensure that the saturation is at 60-70% range for the top-most model.
• [ ] Score results on the basis of other parameters such as input/output tokens, costs, thinking budgets and latency.

P1: Code Quality and Contributor experience

kubectl-ai is in its early days and we expect it to evolve rapidly especially given the state of the AI industry. We want to ensure that it is easy to contribute to the project. We need to ensure that kubectl-ai is not bloated with unnecessary features and should not be afraid to say NO.

Project should ensure:

• [ ] Faster dev loops
• [ ] Contributors should be able to develop locally without any external dependencies.
• [ ] Healthy test coverage (unit, integration and e2e). We need to strike a healthy balance here and prioritize test coverage for the core pieces.
• [ ] Less toil. We should automate as much as possible. We should also explore leveraging coding agents for development.
• [ ] Clear and concise contributing guide.

P2: Experiments/POCs

We want to encourage experiments and POC in the projects. We think it is important to foster creativity and have fun. POCs are critical to understanding the complexity of a problem and shape of the solution. We prefer POCs over design docs.

POC backlog:

• [ ] Remote kubectl-ai agent
• [ ] MCP-Server for kubernetes
• [ ] GUI (HTML) based interface for the agent
• [ ] Terminal UI (using bubbletea or rtview)
• [ ] Session management
• [ ] Secure tool use: - [ ] isolated exec (pods, containers, drop permissions, ...) - [ ] block specific commands for tools - [ ] experiment without shell command, which is too broad

P2: Misc Enhancements

• [ ] list/load specific prompts/TSGs that would help diagnose (some overlap with MCP)

/cc @tuannvm @hakman @zvdy @appleboy @yumosx @gaga5lala @sadikkuzu @Azathoth-X @seunggihong @j796160836 @anyoptional @LinPr @Vinay-Khanagavi @titaneric @ruinshe @DoctorLai @pilz0 @RRethy @mattn @selimacerbas @sinwoobang @mschneider82 @cwrau @mikebz @janetkuo @justinsb

[hakman]

Awesome plan @droot! 💯

For POCs, it would be nice to start thinking of additional security:

• isolated exec (pods, containers, drop permissions, ...)
• block specific commands for tools
• experiment without shell command, which is too broad

and predefined prompts (seems similar to sessions):

• list/load specific prompts/TSGs that would help diagnose

[mikebz]

Thank you @droot to providing a clear direction! Excited for the energy of the community coming together!

[droot]

@hakman good suggestions, I added them to the roadmap.

@mikebz absolutely, fun times ahead 🚀

[sinwoobang]

I love ths plan. I would like to add my two cents. I've integrated kubectl-ai MCP into my vibe coding tool–Cline, but Cline chose to generate kubectl command by itself even I clearly instructed to use kubectl-ai. It may be better to have a clear plan to stand out kubectl-ai's MCP tools. Otherwise, the LLM's default capability and other MCPs can take precedence.

[Azathoth-X]

I would love to pitch a POC in a few days for the remote kubectl-ai. Just want to confirm if the direction of development for this is an exposed http API endpoint ? For the GUI interface, I would like clarifications:

• will it part of the same repo?
• if yes, will it be required to create it using go and tmpl ?
• will it store previous conversations?

[droot]

I love ths plan. I would like to add my two cents. I've integrated kubectl-ai MCP into my vibe coding tool–Cline, but Cline chose to generate kubectl command by itself even I clearly instructed to use kubectl-ai. It may be better to have a clear plan to stand out kubectl-ai's MCP tools. Otherwise, the LLM's default capability and other MCPs can take precedence.

That's a good observation. Agentic tools like cline, cursor that have direct access to kubectl and bash directly, have limited utility of the mcp-server mode of kubectl. mcp-server mode is also an experiment to try different approaches especially around what tools should be exposed. For ex. whether to expose kubectl like tool vs tools that map 1:1 to APIs offered by k8s. I think remote-mcp-server is going to be more useful component and overlaps with remote kubectl-ai agent work. Thanks for sharing the feedback, this validates some of our thinking. I am excited about mcp-client integration as well because because that can power workflows involving more tools.

[droot]

I would love to pitch a POC in a few days for the remote kubectl-ai. Just want to confirm if the direction of development for this is an exposed http API endpoint ? For the GUI interface, I would like clarifications:

• will it part of the same repo?
• if yes, will it be required to create it using go and tmpl ?
• will it store previous conversations?

About POCs, no permission required :), hack away. POC will help us answer some of the questions. For repo, we plan to keep everything in the same repo, we can restructure it along the way.

[selimacerbas]

Thanks for the detailed roadmap, @droot. I would like to share some ideas, considering the enterprise and security perspective, to help make kubectl-ai production-ready.

1. Strict RBAC Adherence: I think we could add explicit checks for any policy violations and ensure all command executions respect the user's Kubernetes RBAC. This would also be important for multi-tool and multi-cluster operations.

2. Prompting Examples: Provide some guidelines for users on how to run effective commands.

3. Multi-tool and Multi-Cluster Operations: Discover all registered KubeContexts (or fleet clusters), then broadcast common tasks such as rollouts, config drift scans, and cost reports across a named set of clusters. kubectl-ai could also collect reports from monitoring tools and suggest optimizations.

4. Sandboxed Execution & Dry-Run Mode: Implement isolated execution (as @hakman suggested) and robust command allow/deny lists to mitigate risks. We could also consider introducing a DRY-RUN mode for users who want to test the tool by seeing the intended commands and expected outcomes without actual execution, while still receiving feedback. ex. kubectl-ai --dry-mode.

5. Template Schema for Tool Integration: Utilizing a YAML templating tool like Carvel YTT, we could enable users to get a template schema. This could be useful for custom tools. kubectl-ai could then validate the YAML file's correctness before running it. ex. kubectl-ai get --custom-tool-template

[ruinshe]

Thanks for the detailed roadmap!

I had an idea about security, I think we should find ways to avoid passing sensitive key information (such as values of Kubernetes Secrets) between different tools. Showing secret values to users if they have permission to view them is fine, but I don't think passing them to another tools without user's approval is fine in this case.

[tuannvm]

@droot Thanks for creating the roadmap! Would it make sense to use GitHub Project to manage the phases and milestones? It could help us track progress, assign tasks, and keep everyone aligned.

The repo has gained good traction and is attracting more and more contributors, so I think it would be great if we could improve project management to encourage even greater collaboration.

[tuannvm]

With the recent release of Jules, I believe kubectl-ai—especially with its ability to call a remote MCP server or interact with another agent—will greatly expand its use cases.

Imagine a scenario where a Kubernetes deployment fails or a pod enters a CrashLoopBackOff state. kubectl-ai could detect the issue and, through integration with Jules, automatically open a GitHub issue or trigger a code-level investigation:

• kubectl-ai: "Pod is crashing due to a suspected memory leak."
• Jules: Clones the repository, analyzes recent changes, suggests or implements a fix, and creates a pull request for review.

[bryantidd]

Secure tool use would be a big plus. The ability to lock down the use of kubectl to a "reporter only', even if the user has additional permissions would help in deploying kubectl-ai in production environments. I would like to couple secure tool use with a custom system prompt that would direct the agent to provide the execution command to the user, rather than try to execute it.... forcing human in the loop for such actions. Thanks for a great AI agent/tool