Capabilities · Infrastructure and Kubernetes
Understand why infrastructure misbehaves.
Ask about the Kubernetes clusters you run: why a pod crashes or cannot be scheduled, which rollout broke a service, what will hurt in a drain or an upgrade. Verbiqo reads the cluster through its API, read-only, and machines through the metrics Prometheus already collects.
The task
- Find why workloads fail: crashes, running out of memory, images that cannot be pulled, pods that cannot be scheduled.
- Find stuck rollouts and the rollout that broke a service, with the command to go back for a person to run.
- See nodes under pressure, and room against requests and real use.
- Check what will hurt in a drain or an upgrade before it happens.
- Explain networking and service mesh faults, and review Pod Security, RBAC and network policy.
Who it helps
Platform and SRE teams, developers who deploy to the cluster, and operations staff on call. What each can ask depends on the clusters and namespaces their account can read.
Supported sources
| Source | What Verbiqo reads | What it needs |
|---|---|---|
| Kubernetes | Named resources and events through GET and LIST, and container logs where the connection allows them, masked line by line. Never Secrets or ConfigMaps. Never exec, attach, port-forward or proxy. | A kubeconfig whose account can read but not change the cluster. One that can administer it is refused |
| Machines | CPU, memory, disk and network from the node metrics your Prometheus already collects, when a Prometheus source is attached. | Read access to the Prometheus query API |
Example
Kubernetes, with container logs · real transcript, lab cluster
Question
Why is checkout in the shop namespace failing?
Checks Verbiqo ran
describe deployment shop/checkout- Logs of the previous container, masked as read
- Warnings and node conditions across the cluster
Findings Measured
- Critical: container
appkeeps restarting (CrashLoopBackOff), 2 pods of 2, 94 restarts. - Critical: a container writes credentials into its log. Verbiqo masked them.
- The container log reports
DB_HOST unreachable:db01does not resolve.
Explanation Your model
The application cannot reach the database: the log shows DB_HOST unreachable, and db01 does not resolve.
Limits stated
4 other findings on the cluster were kept apart from the question. Nothing was changed.
Limitations
- Verbiqo never changes the cluster: it gives the command, such as a rollback, for a person to run.
- It does not run commands inside containers, and reads logs only where the connection allows it.
- It sees only the namespaces and resources the account may read.
- It does not read cloud provider accounts, and it does not monitor continuously or alert.
Next step
Read how to connect a cluster, or try it on your own.