Containerd Commands And Info
Containerd Commands
Containerd supports namespaces at the container runtime level. These namespaces are entirely different from the Kubernetes namespaces. Containerd namespaces are used to provide isolation to different applications that might be using containerd like docker, kubelet, etc. Below are two well-known namespaces.
K8s.io : contains all the containers started from the CRI plugin by kubelet, irrespective of the namespace in Kubernetes
moby : comprises all containers started by docker
Since containerd allows different apps to use different namespaces, we must provide k8s.io as a namespace when interacting with containerd directly, to manage containers started as part of PMK stack. All containers started in PMK stack are added to thek8s.io namespace. Even the containers started by PMK directly (i.e., etcd, bouncer and kube-proxy as added to k8s.io namespace) need the apiserver to be able to access the etcd container and similar containers for the same reasons.
Container Commands
docker ps
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io ps
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock ps
ctr -n k8s.io containers list
docker inspect
Example
docker inspect etcd
/opt/pf9/pf9-kube/bin/nerdctl inspect
Example
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io inspect etcd
for more detail info use -mode=native
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io inspect -mode=native etcd
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock inspect <container ID>
ctr -n k8s.io containers info <container ID>
docker exec
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io exec -it etcd /bin/sh
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock exec -ti <container ID> sh
1. get the container ID from list of containers
2. check if the container has a task associated with it (not all containers have a task associated. For such containers nerdctl or crictl might need to be used to exec)
ctr -n k8s.io tasks ls
3. Exec into container using ID
ctr -n k8s.io tasks exec--exec-id /bin/sh
docker images
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io images
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock images
ctr -n k8s.io images list
docker network
/opt/pf9/pf9-kube/bin/nerdctln -n k8s.io network ls
N/A
N/A
docker system info
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io system info
N/A
N/A
docker logs
/opt/pf9/pf9-kube/bin/nerdctl -n k8s.io logs etcd
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock logs <container-id>
/opt/pf9/pf9-kube/bin/crictl -r unix:///run/containerd/containerd.sock logs <container ID>
N/A
Containerd Logs Locations
/var/log/containers/
/var/log/pods/
Containerd Configuration File
/etc/containerd/config.toml
Partially Migrated Clusters
One of the questions often raised was, “what happens if the cluster is partially migrated, i.e., some nodes are running with containerd runtime while others are running with docker runtime?”
Pods continued to run as usual when the cluster is partially migrated. Moreover, the pods were able to communicate across nodes irrespective of the container runtime on the source and destination nodes where the pods are running.
Last updated
Was this helpful?