Docker VS Containerd
When creating a new Kubernetes version in UK8S v1.19 and later, the container engine has been replaced with Containerd by default, whereas Kubernetes versions prior to 1.19 were Docker. Both container engines have their own command tools to manage 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.
Please note that nodes adopting the containerd runtime will use CNI network plug-ins to allocate Pod IP through containerd. If docker is installed separately, it will override the relevant configuration files of containerd, causing the Pod IP allocation to fail. Therefore, please do not install docker separately to avoid making the node unavailable.
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 plug-in page of the cluster management page in the console, select the “Container Runtime” tab (this tab currently only shows for clusters that have been upgraded to version 1.19 and above), and you can upgrade the legacy nodes before the cluster upgrade to the container runtime. The new nodes added after the cluster upgrade will be containerd runtime by default.
The runtime upgrade will proceed in the order of upgrading all Master nodes first, then upgrading Node nodes. During the upgrade, the node will be unavailable, and its Pod will be evicted to other nodes, which may affect the business. It is recommended to ensure sufficient cluster resources when performing this operation and operate during off-peak business hours.