Docker VS Containerd
In UK8S, when creating a Kubernetes cluster with version V1.19 or later, the container engine is defaulted to Containerd, while clusters with Kubernetes versions earlier than 1.19 use Docker. These two container engines each have their own command-line tools for managing images and containers.
In order to allow UK8S clusters lower than 1.19 to be upgraded to 1.19+, UK8S also launched container runtime upgrade function to help customers upgrade smoothly.
Note: Nodes using the containerd runtime invoke CNI network plugins through containerd for Pod IP allocation. Installing Docker separately will overwrite containerd’s configuration files, leading to failed Pod IP allocation. Therefore, do not install Docker manually to avoid node unavailability.
Comparison of Docker and Containerd Commands
Image Management Command Comparison
| Image Related Functions | Docker | Containerd |
|---|---|---|
| Show Local Image List | docker images | crictl images |
| Download Image | docker pull | crictl pull |
| Upload Image | docker push | None |
| Delete Local Image | docker rmi | crictl rmi |
| View Image Details | docker inspect IMAGE-ID | crictl inspecti IMAGE-ID |
Container Management Command Comparison
| Container-Related Functions | Docker | Containerd |
|---|---|---|
| Display Container List | docker ps | crictl ps |
| Create Container | docker create | crictl create |
| Start Container | docker start | crictl start |
| Stop Container | docker stop | crictl stop |
| Remove Container | docker rm | crictl rm |
| View Container Details | docker inspect | crictl inspect |
| attach | docker attach | crictl attach |
| exec | docker exec | crictl exec |
| logs | docker logs | crictl logs |
| stats | docker stats | crictl stats |
Pod Command Comparison
| POD Related Functions | Docker | Containerd |
|---|---|---|
| Display POD List | None | crictl pods |
| View POD Details | None | crictl inspectp |
| Run POD | None | crictl runp |
| Stop POD | None | crictl stopp |
Container Runtime Upgrade
On the Plugins page of the console’s cluster management interface, select the “Container Runtime” tab (this tab is currently only visible for clusters upgraded from older versions to 1.19 or higher). From here, you can upgrade the container runtime for existing nodes that were part of the cluster before the upgrade. New nodes added after the cluster upgrade will use the containerd runtime by default.
The runtime upgrade will be performed sequentially, starting with all Master nodes followed by Node nodes. During the upgrade, each node will be taken out of service, and the Pods running on it will be evicted to other nodes, which may affect business operations. It is recommended to ensure that the cluster has sufficient resources and to perform this operation during periods of low business activity.