Your Kubernetes services have a live observability tab. Metrics, logs, and events, per pod, one click away. Your VM services have a shell prompt and an SSH key. When a pod misbehaves you read a graph. When a VM service misbehaves you open port 22.
That split is the blind spot. It is not that VMs are unobservable. It is that observing them means logging in by hand, and logging in by hand is both slow and a security liability. ZopDay closes the gap: VM deployment spaces now expose live metrics, logs, and events across AWS, Azure, and GCP, with no SSH, no public IP, and no bastion.
Kubernetes Got Observability. Your VMs Got SSH.
Most platforms run two worlds. Kubernetes gives you a control plane that already tracks every pod, so a dashboard reads container metrics, tails logs, and lists restart events without anyone touching a node. The VM world has none of that wiring. The instance is a box, and the only door is the shell.
So the on-call playbook diverges. For a pod, you open the tab. For a VM, you find the bastion, fetch the key, SSH in, and grep through files you hope still exist. Two workflows, two skill sets, and the slower one is the one you reach for under pressure. The signals you actually need are identical in both worlds. You want recent metrics to see saturation, the same way container CPU throttling shows up on a graph but hides from a shell. You want logs to read the error. You want events to see what the platform did: a restart, an OOMKill on Kubernetes, a redeploy. Pods surfaced all 3 signals. VM services surfaced none of them in one place.
| Signal | Kubernetes pod | VM service (previously) |
|---|---|---|
| Metrics | Live in the tab | SSH in, run a tool by hand |
| Logs | Tailed in the tab | SSH in, grep a file |
| Events | Listed in the tab | Not available |
| Access path | Read-only dashboard | Open port 22 + bastion |
The VM column is the blind spot. Every row of it routes through a login.
SSH Access Is a Tax and a Standing Liability
The SSH workaround looks free because the port is already open. It is not free. It is a recurring tax paid in time and in attack surface.
The time tax is the round trip. You locate the right bastion, pull or rotate a key, jump to the instance, then reconstruct state from log files that may have rotated away. None of that produces a graph anyone else can read, so the knowledge dies in your terminal. The security tax is larger and permanent. An open inbound SSH port is a standing target, and a bastion host is a second one: a box you must patch, monitor, and access-review forever. AWS is explicit that closing inbound ports and removing bastions improves your posture, because leaving SSH ports open raises the risk of unauthorized commands on the instance. Every key you hand out is a credential you now have to rotate and revoke.
The control-plane alternative removes both taxes at once. Session-style access over a cloud control plane needs 0 open inbound ports. The session runs inside a connection encrypted over TLS, and who may connect is decided by IAM, not by who holds a key. There is no jump box to patch because there is no jump box.
The Control-Plane Exec Channel Replaces the Bastion
Every major cloud already ships the door that makes the bastion redundant. AWS has Systems Manager. Azure has VM run-command and its agent. GCP has Identity-Aware Proxy and the OS agent. Each one runs a command inside the instance without any inbound network path. The instance reaches out to the control plane, so nothing has to reach in.
ZopDay reads VM observability over that channel. It does not SSH. It uses the cloud’s own exec path to inspect the running containers on the VM, then streams what it finds into the same tab your clusters already use. The instance keeps its inbound ports closed, there is no public IP requirement, and there is no key to hand out. The plumbing differs by cloud, but the operator never sees that: you open a service, you read its signals, and the cloud-specific exec channel stays under the surface. That is the same model behind live Kubernetes visibility for pods, now extended to instances.
Parity Beats Depth: One Mental Model Across Clusters and VMs
The headline here is not a new dashboard. It is parity. The VM tab shows the same 3 signals as the cluster tab, in the same place, read the same way.
Parity is worth more than depth during an incident. A single mental model means the on-call engineer does not switch tools or context when the failing service happens to run on a VM. They look where they always look. The cost of “where do I even start” drops to zero, because the answer is identical for pods and instances, which is exactly what keeps incident MTTR low.
| Signal | Cluster tab | VM tab (now) | How it is read |
|---|---|---|---|
| Metrics | Yes | Yes | Container stats over the control plane |
| Logs | Yes | Yes | Running-container output, streamed |
| Events | Yes | Yes | Restarts and lifecycle changes |
| Login required | No | No | IAM-scoped, no SSH |
This also moves knowledge out of private terminals. When a VM service degrades, the graph is in the tab, not in one engineer’s scrollback. The next person sees the same evidence.
When This Works, and When It Does Not
This is not a trick, and the caveat is specific. The control-plane channel depends on the cloud’s agent being present on the instance and on an IAM role that grants exec permission. It works when your VM runs containers and carries the cloud agent. It breaks when the agent is missing or the role is too narrow, and the right fix is to install the agent or widen the role, not to fall back to SSH.
Container logs over this path are live. You see what a container is emitting while it runs. Output that was written and rotated away before you looked is gone, the same as it would be over SSH. If you need durable history, ship logs to a store; the tab is for the running state.
That covers the common case: a service deployed to a VM space that you want to watch the way you already watch pods. Open the observability tab, read the three signals, and leave port 22 closed.
