gVisor on Kubernetes: Node Ready does not prove the runtime handler exists
How to check a node before an agent sandbox is scheduled on it, and what we saw when the handler was missing.
Installing gVisor on a Kubernetes node does not show that the node can run a gVisor Pod. We found this in controlled node tests at Plori on September 6, 2026.
The short answer
- Verify the effective runtime configuration during the current boot before the scheduler sends an agent sandbox to the node.
- Then run a real Kubernetes Pod through the declared RuntimeClass.
- Node Ready and install markers do not prove the handler exists. In our tests a RuntimeClass existed while its handler was absent, and an install success marker remained after the handler was gone.
What each check shows
| Check | What it establishes |
|---|---|
| Installed gVisor files | The node has the runtime and its required files |
| Effective containerd handler | The active CRI configuration can select gVisor |
| Kubernetes RuntimeClass | A Pod can request that named handler |
| Successful Pod and DNS test | Scheduling, runtime execution and name resolution worked for the tested workload |
When it applies
- After a reboot: tie the proof to the node identity and the current boot. In our run, admission rejected the old proof after a reboot, qualified the new boot, and passed the independent validation again.
- If the handler disappears: we removed the handler on a disposable node and left its readiness label. A new protected Pod failed sandbox creation with a missing-handler error. We saw no fallback to the default runtime.
- Limits: the tests do not establish continuous runtime health, qualify every storage and network integration, or constitute a security assessment. Repeat them after changes to the node image, container runtime, gVisor release or cluster networking.
The full post has the six-step checklist for qualifying a fresh node, and the two ordering failures we hit.