CRICTL Kubernetes Command Line Tool for Troubleshooting
CRICTL is not a command that you may have heard about when working with Kubernetes, but it is a really great utility to troubleshoot your Kubernetes cluster at the container runtime level. It provides a direct line of sight to the container runtime such as containerd or others like CRI-O. We will take a look at how to setup CRICTL and use it in a few practical examples for your Kubernetes cluster.
Table of contents
What is crictl?
First of all, let’s take a look at what CRICTL is exactly. It is a command line tool that is used to interact with your container runtimes that are used by Kubenetes. You can use the tool to inspect and troubleshoot your containers and podes and also images directly from the runtime. The key here is that it doesn’t need the Kubernetes control plane to get this information as it speaks directly to the container runtime.
Points to note:
- It allos direct access to container runtimes
- If kubectl is not working or doesn’t give you the information you need crictl helps
- If a node is isolated, you can still interact with the runtime which can definitely be helpful
Installing crictl
Let’s look at the process to install crictl and see how you can get up and running with the tool. You can install the CRICTL tool by curling down the tar.gz file or using something like wget, extracting the file, and then copying to usr/local/bin.
To find the latest release of the crictl tool, visit the download page here:
To download, the version you want to download, use the command example below, replacing the version with the version you want to download:
curl -LO https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.31.1/crictl-v1.31.1-linux-amd64.tar.gz
Next, we would like to unzip the file:
tar -xvzf crictl-v1.31.1-linux-amd64.tar.gz
Next, we can move the directory to our /usr/local/bin directory:
mv crictl /usr/local/bin
Finally, check that it is installed by running the command:
crictl --version
Configuring crictl for Your Environment
By default, crictl
looks for the container runtime socket at /var/run/dockershim.sock
. If you’re using containerd
(common in modern Kubernetes setups), you will need to update your configuration. This is what I had to do when using it with a Microk8s Kubernetes cluster:
nano /etc/crictl.yaml
For containerd, you add the following in that file:
runtime-endpoint: unix:///var/snap/microk8s/common/run/containerd.sock
To test and see if the change has taken effect, run the following command:
critcl info
Below, we don’t get an error running the command so everything looks good pointed to the containerd runtime.
Example CRICTL Commands to use
Let’s look at a few example of using CRICTL and see how we can use th
Listing pods or containers
One of the things you may want to do with CRICTL is list your pods or containers. You can do this with CRICTL, using the following command:
crictl pods
This command returns the pod ID, namespace, and pod names. It will also give you the state of all pods on the node.
Similar to using the docker cli, you can list containers running on a container host node using the following:
crictl ps
For all containers, including stopped ones:
crictl ps -a
Viewing logs
You can view the logs for a specific container using the following command:
crictl logs <container_id>
Inspecting containers
Inspecting Containers Get detailed information about a containers:
crictl inspect <container_id>
Listing images
Debugging Images List all images available on the node:
crictl images
Removing images
Remove an unused image:
crictl rmi <image_id>
Pulling images
Pull an image manually:
crictl pull nginx:latest
Stopping and removing pods
Managing Pods Remove a pod (useful for stuck or orphaned pods):
crictl stopp <pod_id>
crictl rmp <pod_id>
Troubleshooting sandboxes
Debugging Sandbox Issues In Kubernetes, pods are associated with sandboxes. List all sandboxes and inspect sandboxes:
crictl sandboxes
crictl inspectp <sandbox_id>
Troubleshooting with crictl
As CRICTL is primarily for troubleshooting in most cases, let’s consider a few examples of issues you might use CRICTL to troubleshoot. Note the following:
- When a Kubernetes pod is in a CrashLoopBackOff State: You can use
crictl logs
to get logs and troubleshoot for error messages - When a Pod Wonโt Start: Check the sandbox state: code
crictl sandboxes crictl inspectp <sandbox_id>
- When Disk Space is an Issue: List all images and remove unused ones:
crictl images crictl rmi <image_id>
crictl vs. kubectl
You might wonder how do crictl and kubectl compare. They are both great tools but have their strengths and definite use cases. Note the following helpful comparison:
Feature | kubectl | crictl |
---|---|---|
Scope | talks to all nodes in cluster | specific to a node |
Interaction | uses Kubernetes API | Direct comms with container runtime |
Use Case | day-to-day management and troubleshooting of Kubernetes objects | Used to troubleshoot containers and runtime |
Visibility | All nodes | local node only |
crictl
excels in node-level debugging, especially when the Kubernetes API server or kubectl
commands arenโt helpful.
Wrapping up
Kubernetes is one of those solutions that it takes an acquired skill and experience to troubleshoot. But, it also takes the right tools and know what to use when. CRICTL is a command line tool that you may not have been familiar with but definitely one that you want to take notice of. Get this downloaded in your home lab and start experimenting with it to see how it can be helpful. It can definitely be a valuable addition to your troubleshooting toolbelt as it can help pinpoint issues or troubleshoot Kubernetes when kubectl might not be able to such as when a node is isolated.
I wonder where this “sandboxes” comes from. For me “crictl sandboxes” doesn’t work at all. It doesn’t look like a valid crictl option.
cretin,
Thanks for the comment! This is a feature of crictl that I want to play around with more. Take a look at the documentation here: https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md
There’s nowhere in the documentation there that I’m seeing “sandboxes” as an option. What I’m seeing is “crictl pods” (which lists pod sandboxes). I’m not sure if this is what you meant in your article, but if you did, then I think you should write “crictl pods” instead, otherwise it’s quite confusing.
I think you used a much older crictl version as that stated in your article and this is where the confusion stems from.
If you have a look at this crictl merge (https://github.com/containerd/cri/issues/534), you will see that ‘sandboxes’ has been completely removed and replaced by ‘crictl pods’.