k8m: a single-binary Kubernetes AI dashboard with MCP permissions

The gap k8m targets: a console that also answers questions

Most Kubernetes dashboards are read-mostly viewers. You get a resource tree, a YAML editor, a log viewer, and you leave the tab when you need to understand why a Pod is crash-looping. k8m's premise is that the explanation should live next to the resource. It is a Mini Kubernetes AI Dashboard, built with AMIS on the frontend and using kom as its Kubernetes API client, distributed as a single executable. The README states the design goal directly: all functionality is integrated into one binary so deployment stays simple.

The audience is narrower than "everyone who runs Kubernetes". It is the operator who manages more than one cluster, wants Chinese-language AI output over Describe text and logs, and does not want to stand up a separate AI gateway, a separate MCP server and a separate dashboard. The README lists support for standard Kubernetes, AWS EKS, k3s, kind and k0s cluster types, which tells you the target is heterogeneous fleets rather than one managed offering.

How k8m works: kom for the API, plugins for features, MCP for the model

Three layers are visible from the repository. The first is the Kubernetes client: go.mod pins github.com/weibaohui/kom v0.2.72 alongside k8s.io/client-go v0.34.11, so k8m is not shelling out to kubectl for its own operations. The second is the feature layer, which the README describes as plugin-based: features are enabled on demand and consume no resources when disabled. That is why the binary can carry CRD discovery, a Helm market, cluster inspection and event forwarding without every deployment paying for all of them.

The third layer is the AI and MCP side. go.mod includes github.com/mark3labs/mcp-go v1.0.0 and github.com/sashabaranov/go-openai v1.42.1, matching the README's claim that k8m both consumes MCP tools and can act as an MCP Server for other model clients. The README states there are 49 built-in multi-cluster MCP tools and that they can be combined into more than a hundred cluster operations, with every MCP call logged.

The permission design is the part worth reading twice. The README says cluster management permissions and MCP call permissions are connected: whoever uses the model executes MCP with their own permissions. That is a deliberate choice against the common pattern where an AI agent holds a single service-account token and acts as a superuser on behalf of every user. It only holds if the user model is complete, and k8m's model is its own: users and user groups, per-cluster grants of read-only, Exec, or cluster administrator, plus namespace allow and deny lists. None of that is Kubernetes RBAC. It is a second authorization system layered in front of the API server, and it is only as good as its coverage.

Running k8m from a release binary or docker-compose

The README gives two paths. The first is the release binary: download it from the GitHub releases page, run it, and open port 3618. The second is docker-compose, which the README calls the recommended route. Both create the same default account, k8m with password k8m, and the README explicitly says to change the username and password and enable two-factor authentication after going live.

The compose file below is the one shown in the README. It maps 3618 to 3618 and mounts ./data into /app/data, which is where the default SQLite database lives.

services:
  k8m:
    container_name: k8m
    image: registry.cn-hangzhou.aliyuncs.com/minik8m/k8m
    restart: always
    ports:
      - "3618:3618"
    environment:
      TZ: Asia/Shanghai
    volumes:
      - ./data:/app/data

If you prefer the binary, the README's run section is one command, and the flag list is where the deployment decisions actually are. The flags below are copied from the README's usage output; note that --kubeconfig defaults to /root/.kube/config and --in-cluster defaults to enabled.

./k8m --kubeconfig /root/.kube/config --port 3618 --login-type password

The README says k8m scans the directory next to the configured kubeconfig and registers the clusters it finds there. That behavior is worth understanding before you point it at a machine that holds credentials for environments you did not intend to expose in one console. For a first real use, the sequence in the README is: start the container, open port 3618, log in as k8m, then use the left-hand tree to reach a Pod, read its logs, and select text in the console to get an AI explanation. A .env.example sits at the repository root for the same settings in environment form, including OPENAI_API_KEY, OPENAI_API_URL, OPENAI_MODEL and DB_DRIVER.

Where k8m stops being the right tool

k8m does not enforce anything at admission time. A user with cluster administrator rights in k8m can do what cluster administrator rights allow, and the namespace allow and deny lists are k8m's own configuration, not a Kubernetes policy object. If your requirement is that no workload may ever run with a privileged security context, or that every image must come from an approved registry, k8m will not satisfy it. You want an admission controller or a policy engine for that, and k8m sits beside them, not in place of them.

The AI features inherit the usual limits of the model behind them. The README states that k8m ships with Qwen2.5-Coder-7B built in and supports deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, with the option to point at your own private model including ollama. A seven-billion-parameter model reading a Describe output will sometimes be wrong, and the README does not describe any verification step between a model suggestion and the cluster operation it recommends. Treat the AI output as a second opinion, not as a change plan.

There is also an operational cost the README does not quantify. The Dockerfile shows the runtime image installing curl, bash, inotify-tools, busybox-extras, tzdata, aws-cli, ca-certificates, helm, tar and gzip on top of Alpine. That is a larger attack surface than a static Go binary alone, and it exists because k8m needs Helm and shell tooling inside the container. If you deploy the bare binary instead, you trade that surface for a dependency on whatever is already on the host.

k8m against k8sgpt and KubeSphere

The closest comparison in the README itself is k8sgpt, which k8m says it has integrated for Chinese-language output. The difference is the shape of the product. k8sgpt is a scanner and a CLI: you run it, it analyzes resources and reports problems, and it fits into a pipeline or a CronJob. k8m is a console with a scanner inside it. If your workflow is "run a check in CI and fail the build", k8m's scheduled inspection with Lua rules and DingTalk, WeCom, Feishu or custom webhook delivery is a different fit than a command you can call from a script.

KubeSphere is the other name that comes up. It is a full platform: its own installer, its own multi-tenancy, its own console, its own set of extensions. k8m is deliberately smaller. The README's own framing is miniaturization, one executable, no separate installation of a platform on top of the cluster. The trade follows from that: KubeSphere gives you a platform with its own tenancy model and a heavier footprint, while k8m gives you a dashboard you can start with docker-compose in a minute and that borrows the cluster's existing API server. If you already run KubeSphere, adding k8m is a second console, not a replacement.

Maintenance, licence and the upgrade path

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.26.19 landed on 2026-09-10, v0.26.18 on 2026-08-14, and v0.26.17 on 2026-03-05. The gap between v0.26.17 and v0.26.18 is roughly five months, which is a useful signal about cadence: this is a project that ships in bursts rather than on a fixed schedule. The version numbers stay in the 0.x range, so the API and the MCP tool surface can move between releases.

Upgrade cost depends on how you deploy. With the compose file, the upgrade is pulling a new image tag and restarting, and the SQLite database in ./data carries your users, permissions and inspection rules forward. With the binary, you replace the file. Neither path is documented as having a rollback procedure, and the README does not describe a database migration policy, so a snapshot of the data directory before an upgrade is the only cheap insurance the documentation supports.

The licence is MIT, stated in the README badge and present as LICENSE at the repository root. MIT permits commercial use and modification, and the README states the project can be used commercially with no restrictions. That is the extent of what the documentation says; whether your organization's own obligations apply to a modified fork is a question for your legal team, not something this article can settle.

Editorial conclusion

Adopt k8m if you run several clusters, want an AI assistant inside the same console you already use for Pod logs and Helm, and care that MCP tool calls execute with the caller's own cluster permissions rather than a shared admin token. Skip it if you need a policy engine, an admission controller or anything that must enforce rules before a request reaches the API server: k8m is a dashboard, and its authorization model is the one it defines for its own users. Before rolling it out, change the default k8m/k8m credentials, set JWT_TOKEN_SECRET to something other than your-secret-key, and confirm which kubeconfig directory the process scans on your hosts.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. weibaohui/k8m on GitHub