On a containerd Kubernetes node, what replaces `docker ps`, and how does crictl's view differ?

## Who each CLI is talking to `docker ps` is a thin client; the work happens in `dockerd`, which the CLI reaches over `/var/run/docker.sock`. On a Kubernetes node whose runtime is containerd, the node agent never spoke to dockerd - it makes CRI gRPC calls into containerd - so there is no dockerd holding those containers, and frequently no `docker` binary installed at all. Even where Docker Engine *is* installed on such a node, for builds or for legacy tooling, `docker ps` still will not show the cluster's containers. Docker Engine drives containerd inside the containerd **namespace** `moby`, while the Kubernetes node agent uses the namespace `k8s.io`. A containerd namespace is a tenancy partition of the runtime's own metadata, so the two sets of containers are simply invisible to each other's clients. This is the single most common surprise after a runtime migration: the command runs, exits zero, and prints an almost empty table. ## crictl: a CLI shaped like the CRI contract `crictl` ships from the Kubernetes `cri-tools` project and speaks the CRI gRPC API directly to a runtime endpoint. Because the contract has two services, crictl's verbs split the same way: - RuntimeService: `crictl pods` (sandboxes), `crictl ps` (containers), `crictl inspect`, `crictl inspectp`, `crictl logs`, `crictl exec`, `crictl stats` - ImageService: `crictl images`, `crictl pull`, `crictl rmi`, `crictl imagefsinfo` The endpoint comes from `/etc/crictl.yaml` (`runtime-endpoint: unix:///run/containerd/containerd.sock`) or from `--runtime-endpoint`. Recent crictl releases warn when you rely on endpoint auto-detection instead of configuring it, so set it explicitly on nodes you expect to debug under pressure. Two structural differences from `docker ps` are worth stating out loud in an interview. **Sandboxes are first class.** CRI models a pod as a sandbox plus its containers, so `crictl pods` lists the sandboxes and `crictl ps` lists containers with the sandbox they belong to. A pod that fails before any application container starts shows up as a sandbox with nothing inside it - a state the docker CLI has no vocabulary for. **Much of docker's surface does not exist here.** There is no `crictl build`: the ImageService can pull, list and remove images, but building is not part of the CRI contract at all. There is no `crictl network` or `crictl volume` either - pod networking is configured by a CNI plugin when the sandbox is created, and volumes are mounted by the node agent from the pod spec, so the runtime holds no such objects to list. ## crictl is a debugger, not a manager Everything crictl shows is owned by the node agent, which continuously reconciles the node's containers against the pods assigned to it and garbage-collects whatever it does not recognise. `crictl rm` on a live container gets it recreated seconds later; `crictl rmi` on an image the node still wants forces a re-pull. Treat crictl as read-mostly: `pods`, `ps -a`, `logs`, `inspect`, `images`, `stats`. ## A worked example A chat-message fan-out service ships as a static Go binary in a `scratch` image - 11.4 MB, no shell, no coreutils. Three of its 14 replicas keep restarting on one node, and you have a root shell on that node but no cluster access: ```bash crictl pods --name fanout crictl ps -a --pod <pod-id> crictl logs --previous <container-id> crictl inspect <container-id> ``` `crictl exec -it <container-id> sh` is useless here, because the image contains no `/bin/sh`. That is exactly when `logs --previous` and `inspect` carry the investigation: the exit code, the resolved args and the mounts come from the runtime's own record of the container rather than from anything inside the image. ## nerdctl and ctr `nerdctl` is a docker-compatible CLI for containerd: `nerdctl ps`, `nerdctl run`, and, with BuildKit behind it, `nerdctl build` - something crictl cannot do at all. It works at containerd's own layer rather than through CRI, so it is namespace-scoped and defaults to the `default` namespace; `nerdctl ps` on a Kubernetes node prints an empty table until you say `nerdctl --namespace k8s.io ps`. `ctr` is containerd's own low-level client, equally namespace-scoped and deliberately unfriendly. The rule of thumb: reach for **crictl** when the question is 'what does the cluster's runtime think is running on this node', and for **nerdctl** when you want docker-like ergonomics against containerd itself.