Kubernetes for Kubernetes and containers
Operating containers is a stream of small, urgent questions: which pods are crash-looping, what do the logs say, what is running right now. This native Kubernetes and OpenShift server is our top pick of three for that work because it talks to the cluster through the Kubernetes API directly, so an agent answers those questions without chaining kubectl by hand.
It ranks first here because cluster operations are exactly its scope. Docker covers the local container runtime and Argo CD reconciles GitOps state, but when the daily job is reading and acting on a live Kubernetes or OpenShift cluster, this is the core tool.
How Kubernetes fits
The everyday loop maps cleanly to the tools. pods_list and pods_list_in_namespace show what is scheduled, pods_get inspects one pod, and events_list reads the warnings and state changes behind a failure. nodes_log pulls kubelet and system logs from a node, and configuration_view confirms the active context so the agent does not act against the wrong cluster. For capacity, nodes_top, pods_top, and nodes_stats_summary report CPU and memory use. namespaces_list scopes the work. When intervention is needed, pods_delete triggers a restart and pods_exec runs a command inside a pod.
The limits are real. The write surface centers on pods and node-level operations rather than editing Deployments, Services, or other objects as first-class targets, and it does not build images or manage a registry. Docker is the better pick when the work is the local runtime, building and running containers under a build. Argo CD fits when the question is whether the cluster matches its Git-declared state. For inspecting and operating the cluster itself, this server is the one to reach for first.
Tools you would use
| Tool | What it does |
|---|---|
| configuration_view | Get the current Kubernetes configuration content as a kubeconfig YAML (minified to the current context by default). |
| events_list | List Kubernetes events (warnings, errors, state changes) for debugging and troubleshooting in the current cluster. |
| namespaces_list | List all the Kubernetes namespaces in the current cluster. |
| nodes_log | Get logs from a Kubernetes node (kubelet, kube-proxy, or other system logs) via the node's proxy endpoint. |
| nodes_stats_summary | Get detailed resource usage statistics from a node via the kubelet's Summary API. |
| nodes_top | List the CPU and memory consumption of nodes as recorded by the Kubernetes Metrics Server. |
| pods_list | List all the Kubernetes pods in the current cluster across all namespaces. |
| pods_list_in_namespace | List all the Kubernetes pods in a specified namespace. |
| pods_get | Get a Kubernetes pod by name in the current or provided namespace. |
| pods_delete | Delete a Kubernetes pod by name in the current or provided namespace. |
FAQ
- Can the agent read pod logs and exec into a container with this server?
- It reads node-level logs with nodes_log and can run a command inside a pod with pods_exec, which covers most live debugging. Combined with events_list for state changes and pods_get for pod detail, an agent can diagnose a crash-looping workload directly against the cluster.
- Is this server enough on its own for container work, or do I also need Docker?
- For cluster operations on Kubernetes or OpenShift it is the primary tool. If your work also involves building images or running containers locally under a build, the Docker server covers that runtime; this server operates the orchestrated cluster, not the local engine.