Command Line tools : nerdctl | crictrl | ctr

Container Runtime CLI Tools

Runtime: containerd
Used commonly in: Kubernetes

---

1️⃣ ctr – containerd Native CLI

✅ What It Is

• Low-level CLI for containerd

• Used mainly for debugging and advanced runtime operations

• ⚠ Not user-friendly (No Docker-style UX)

---

Common ctr Commands

Image Management

ctr images pull nginx:latest
ctr images list
ctr images rm nginx:latest

Container Management

ctr containers create docker.io/library/nginx:latest mynginx
ctr containers list
ctr containers delete mynginx

Task (Running Container) Management

ctr tasks start mynginx
ctr tasks list
ctr tasks kill mynginx
ctr tasks rm mynginx

Namespaces (Important in Kubernetes)

ctr namespaces list
ctr -n k8s.io containers list

---

When to Use ctr

• Debugging containerd directly

• Troubleshooting runtime issues

• Not recommended for daily use

---

2️⃣ nerdctl – Docker-like CLI for containerd

Project: nerdctl

✅ What It Is

• Docker-compatible CLI for containerd

• Feels similar to Docker CLI

---

Common nerdctl Commands

Image Commands

nerdctl pull nginx
nerdctl images
nerdctl rmi nginx

Container Commands

nerdctl run -d -p 8080:80 nginx
nerdctl ps
nerdctl stop <container>
nerdctl rm <container>

Build

nerdctl build -t myapp .

Logs / Exec

nerdctl logs <container>
nerdctl exec -it <container> sh

Compose

nerdctl compose up

---

When to Use nerdctl

• Docker replacement

• Working directly with containerd

• Local container testing

---

3️⃣ crictl – CRI CLI for Kubernetes

Project: crictl

✅ What It Is

• CLI for CRI (Container Runtime Interface)

• Used to debug containers running under Kubernetes

---

Common crictl Commands

Pods

crictl pods
crictl inspectp <pod-id>

Containers

crictl ps
crictl ps -a
crictl inspect <container-id>
crictl logs <container-id>
crictl stop <container-id>
crictl rm <container-id>

Images

crictl images
crictl pull nginx
crictl rmi nginx

Runtime Info

crictl info
crictl stats

---

When to Use crictl

• Kubernetes node debugging

• When kubectl is not enough

• Checking container runtime health

---

🔥 Key Differences

Tool	Level	Used For	Docker-like?
ctr	Very Low	containerd debugging	❌
nerdctl	User Level	Docker replacement	✅
crictl	Kubernetes Level	K8s troubleshooting	❌

---

🎯 Real Production Example

If a pod is stuck in CrashLoopBackOff

kubectl describe pod <pod-name>

SSH into node, then:

crictl ps -a
crictl logs <container-id>

---

If containerd is broken

ctr containers list

---

When people say “Kubernetes removed support for Docker”, it does NOT mean:

• ❌ Kubernetes can’t run Docker-built images anymore

• ❌ You must stop using Docker to build containers

It means something more specific.

🔧 What Actually Changed

Kubernetes used to rely on a built-in component called Dockershim to talk directly to Docker Engine.

In Kubernetes 1.24 (2022), Dockershim was removed.

So Kubernetes no longer talks directly to Docker Engine as a container runtime.

🧠 Why This Happened

Kubernetes uses something called the Container Runtime Interface (CRI).

Modern runtimes like:

• containerd

• CRI-O

support CRI natively.

Docker Engine does not natively implement CRI — Kubernetes had to maintain the extra Dockershim layer just to make it work.

Maintaining that extra layer added complexity and maintenance burden, so it was removed.

---

🚀 What You Use Instead

Most Kubernetes clusters now use:

• containerd (very common)

• CRI-O

Important:
Docker itself actually uses containerd internally, so in many cases the transition was smooth.

---

📦 Can You Still Use Docker?

Yes.

You can still:

• Build images using Docker

• Push images to a registry

• Deploy those images to Kubernetes

Container images follow the OCI standard, so they work regardless of whether they were built with Docker, containerd, or something else.

🏗 What Changed Architecturally

Before Kubernetes 1.24:

Kubernetes → Dockershim → Docker Engine → containerd → runc

After Dockershim removal:

Kubernetes → containerd (or CRI-O) → runc

runc is a low-level container runtime.

It is the program that actually:

• Creates containers

• Sets up Linux namespaces

• Applies cgroups (CPU/memory limits)

• Starts the container process

Think of it as the component that actually runs the container process on Linux.