Query pods, deployments, events, logs, and metrics across your Kubernetes clusters
The copilot can answer questions about any aspect of your connected Kubernetes clusters — pod status, container logs, events, resource specifications, metrics, network policies, deployments, and more. The examples on this page illustrate common query patterns, but you can ask anything about your clusters in natural language.
Use @cluster-name to direct your query to a specific Kubernetes cluster. You can target multiple clusters in a single query for cross-cluster comparisons.
@prod-eks-cluster show me pods in CrashLoopBackOff
@prod-eks-cluster @staging-eks-cluster compare the resource limits for the auth-service deployment
If you have only one cluster connected, the copilot targets it automatically — no @ prefix needed.
Find your cluster names on the Clusters page in the Kestrel dashboard. The name matches whatever you set when connecting the cluster.
Query network policies, services, and connectivity.
@prod-eks-cluster What network policies apply to pods in the payments namespace? Can the payments-api reach the orders-db service?
@prod-eks-cluster Show me all ingress and egress rules for the frontend namespace. Are there any policies that could be blocking traffic to the external payment gateway?
@prod-eks-cluster List all services in the production namespace with their types, ports, and selectors.
@prod-eks-cluster Trace the full request path from the frontend ingress to the database for the order-service — which services are involved and what network policies apply at each hop?
Compare resources and configurations across multiple connected clusters.
@prod-eks-cluster @staging-eks-cluster Compare the resource limits for the auth-service deployment across both clusters. Are there any discrepancies in CPU or memory requests?
@prod-eks-cluster @staging-gke-cluster Are the same network policies applied to the payments namespace in both clusters?
@prod-eks-cluster @staging-eks-cluster Which deployments exist in production but not in staging?
@prod-eks-cluster @staging-eks-cluster Compare the image tags for all deployments in the checkout namespace. Which services are running different versions?
@prod-eks-cluster Pods in the payments namespace are throwing 5xx errors. What’s going on? Cross-reference with Datadog latency and error rate metrics for the payments-api service.
Kestrel:
I found 3 pods in the payments namespace showing issues:
payments-api-7f8b9c-x4k2m — Running but 12 container restarts in the last hour
payments-api-7f8b9c-n3j8p — CrashLoopBackOff since 14:47 UTC
Datadog metrics show the payments-api P99 latency spiked from 85ms to 3.8s at 14:32 UTC. Error rate jumped from 0.1% to 14.2% at the same time. The container logs from payments-api-7f8b9c-n3j8p show repeated FATAL: connection pool exhausted, max_connections=10 errors. The deployment was updated at 14:30 UTC — image changed from v2.13.2 to v2.14.0.
You:
What changed in v2.14.0? Can you find the PR?
Kestrel:
The image tag v2.14.0 maps to PR #847 in acme/payments-service, merged at 14:28 UTC by @jane.doe. The PR description says “Optimize DB connection handling” — it reduced DB_MAX_CONNECTIONS from 50 to 10 in the deployment environment variables. This matches the connection pool exhausted error in the logs. The connection pool is now too small for the current request volume.
You:
Roll back the deployment to v2.13.2 and increase the memory limit to 512Mi while you’re at it.
Kestrel:
Here’s the proposed change for the payments-api deployment:
Revert image tag from v2.14.0 to v2.13.2
Increase memory limit from 256Mi to 512Mi
(displays diff with Safe Apply, Create PR, and Copy options)