Gemini CLI's MCP support has matured quickly since its general availability, and it handles Kubernetes MCP's tool surface reasonably well — its strength is aggregating structured output across many calls into a coherent summary, which suits the "check everything in this namespace" style of triage. This topic covers setup, log aggregation across pods, a concrete incident walkthrough, and an honest comparison against Claude Code's handling of the same tool calls.
Installing and Connecting Kubernetes MCP to Gemini CLI
Gemini CLI reads MCP server config from ~/.gemini/settings.json (global) or .gemini/settings.json (project). Register the server:
{
"mcpServers": {
"kubernetes": {
"command": "kubernetes-mcp-server",
"args": ["--kubeconfig", "/Users/you/.kube/config-staging"],
"trust": false
}
}
}
The trust field matters here — leaving it false (or omitted) means Gemini CLI will prompt for confirmation before invoking each tool call, which is exactly the behavior you want for a cluster-mutating tool surface. Only set trust: true for a server you've already scoped to strictly read-only RBAC, and even then, treat it as an explicit trade of safety for speed.
For the Node package:
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["-y", "mcp-server-kubernetes"],
"env": {
"KUBECONFIG": "/Users/you/.kube/config-staging"
},
"trust": false
}
}
}
Verify the connection:
gemini
/mcp list
This shows connected servers, their tool counts, and trust status. If a tool call hangs waiting for confirmation and you don't see a prompt, check that you're running in an interactive terminal — Gemini CLI's confirmation UI doesn't render the same way in a piped/non-interactive session, which can make it look stuck when it's actually just waiting on stdin.
Tips
- Leavetrust: falsefor any Kubernetes MCP server pointed at a real cluster — the per-call confirmation prompt is cheap insurance against a mistaken mutation.
- Run/mcp listafter every settings.json edit — Gemini CLI, like most of these tools, doesn't reliably hot-reload MCP config into a session already in progress.
- If tool-call confirmations seem to hang, confirm you're in an interactive terminal session, not a scripted/piped invocation.
Querying Cluster State and Aggregating Pod Logs from Gemini CLI
Gemini CLI does well with prompts that ask it to gather and summarize across a scoped set of resources, which is the exact shape of most first-response triage:
List all pods across namespaces order-service-prod and order-service-staging
that are not in Running/Ready state. For each, get the last 30 log lines
and summarize any common error pattern across them.
A useful pattern specific to log aggregation: ask for a structured comparison rather than a narrative summary, since it's easier to scan and act on:
For the unhealthy pods you found, produce a table: pod name, namespace,
restart count, last termination reason, and the first distinct error
line from its logs.
| Pod | Namespace | Restarts | Reason | First Error Line |
|-----------------------------------|-------------------------|----------|-------------|--------------------------------------------|
| order-worker-6c9f8d-abc12 | order-service-prod | 6 | OOMKilled | (no log — killed before flush) |
| order-worker-6c9f8d-def34 | order-service-prod | 6 | OOMKilled | (no log — killed before flush) |
| order-api-8d7f6c-ghi56 | order-service-staging | 2 | Error | "connection refused: redis-staging:6379" |
This table format immediately tells a useful story: the two order-worker pods sharing an identical OOMKilled reason and no log output point at a systemic memory-limit problem across the whole worker fleet, not a one-off. The order-api pod's Redis connection error is unrelated — a separate staging-environment networking issue. Separating these two clusters of symptoms is exactly the kind of triage judgment worth double-checking manually before you act on either one, but the table gets you there fast.
Tips
- Ask Gemini CLI for tabular output when aggregating status across multiple pods — it's a more scannable format than prose for spotting shared failure patterns.
- Treat identical failure reasons across multiple pods in the same Deployment as a systemic signal (resource limits, bad config, bad image) rather than investigating each pod independently.
- A pod with no captured log output at time of OOM kill is normal, not a tooling failure — the OOM killer doesn't wait for a log flush.
Practical Example: Tracing a 5xx Spike to a Single Unhealthy Pod
Scenario: your ingress metrics show a 5xx error rate spike on api-gateway-prod, but you don't yet know which backend is causing it.
The api-gateway-prod ingress is showing a 5xx spike. List the pods
backing the api-gateway Service, check their readiness status, and
check recent events for any of them.
Chain: resources_get on the Service (to confirm the selector), resources_list on pods matching that selector, then events_list per pod.
- name: api-gateway-7f8b9c-p1: Ready=true, restartCount=0
- name: api-gateway-7f8b9c-p2: Ready=true, restartCount=0
- name: api-gateway-7f8b9c-p3: Ready=false, restartCount=3
- name: api-gateway-7f8b9c-p4: Ready=true, restartCount=0
One pod out of four is unready with restarts — in a round-robin load-balanced Service, that's roughly a 25% failure rate landing on real requests, which lines up with a partial 5xx spike rather than total outage. Follow with:
Get logs and events for api-gateway-7f8b9c-p3 specifically.
events:
- reason: Unhealthy
message: "Readiness probe failed: HTTP probe failed with statuscode: 503"
lastState:
terminated:
reason: Error
exitCode: 1
Combined with the previous log tail showing a repeated panic: nil pointer dereference right before each restart, the picture is clear: one bad pod is crash-looping intermittently, briefly passing readiness after restart, taking live traffic, then failing again. The fix here is immediate — cordon or delete that specific pod so the Deployment replaces it — not a broader rollback, since the other three replicas are healthy:
kubectl delete pod api-gateway-7f8b9c-p3 -n api-gateway-prod
This is a case where scoping the fix to the actual faulty replica, rather than reflexively rolling back the whole Deployment, is the right call — but only because the evidence (one bad pod, three healthy ones, no Deployment-wide event) supports it. If all four pods showed the same panic, that would point to a bad image rollout instead, and the correct action would be rollout undo, not a pod delete.
Tips
- A partial 5xx spike with some pods behind a Service healthy and one or two unhealthy points at an individual bad replica, not a bad rollout — check readiness/restart counts per pod before assuming you need a Deployment-wide rollback.
- Deleting a single crash-looping pod (letting the ReplicaSet recreate it) is a valid, low-blast-radius fix when the rest of the Deployment is healthy — reserverollout undofor when the failure pattern is uniform across replicas.
- Correlate the readiness-probe failure reason with the container's actual crash log — a 503 on the probe just means "not ready," the panic in the log is the actual root cause.
Comparing Kubernetes MCP Output Between Gemini CLI and Claude Code
Both tools call the same underlying MCP server and get identical raw tool results — the difference is entirely in how each agent plans multi-step chains and formats the output back to you.
Chaining behavior: Claude Code tends to plan a full multi-step investigation up front and execute it with less intermediate narration, which is faster for well-understood patterns (crash loop triage) but occasionally skips a step you'd have wanted surfaced. Gemini CLI narrates more between steps and asks for confirmation more readily (partly a function of the trust: false default), which is slower per-turn but leaves a clearer audit trail of what was checked and why.
Output formatting: Gemini CLI defaults to more structured tabular summaries when you ask for comparisons across multiple resources; Claude Code tends toward prose summaries unless you explicitly request a table, though both will produce a table on request.
Tool-call confirmation: Gemini CLI's per-call trust gating is more conservative by default than Claude Code's, which relies more on your project-level permission rules and prompt instructions to gate mutating calls. If your team's risk tolerance is low, Gemini CLI's default posture requires less upfront configuration to get a safe baseline; Claude Code requires you to set that discipline explicitly (see Topic 2 in this module) but then runs faster once it's set.
Practical takeaway: for exploratory, high-volume read-only investigation across many resources, either tool works well. For anything touching a mutating call in production, don't rely on either tool's default behavior alone — combine RBAC scoping (Topic 1) with explicit confirmation gates regardless of which agent you're driving.
Tips
- Don't assume identical prompts produce identical tool-call sequences across agents — the underlying MCP tool results are the same, but planning and confirmation behavior differ meaningfully.
- If your team standardizes on Gemini CLI for cluster work, its default confirmation-per-call behavior is a reasonable baseline safety net — don't disabletrustcasually just for speed.
- Whichever agent you use, the RBAC scoping from Topic 1 of this module is the real safety boundary — agent-level confirmation prompts are a second layer, not a substitute.
Tips
Tips
- Keeptrust: falsein Gemini CLI's MCP config for any server touching a real cluster — the confirmation-per-call behavior is a deliberate, useful friction point.
- Ask for tabular summaries when triaging multiple pods — Gemini CLI produces genuinely scannable comparisons that speed up spotting shared failure patterns.
- When a Service's backing pods show a partial-unhealthy pattern (some Ready, some not), scope the fix to the specific bad replica before reaching for a full rollback.