This topic introduces the P2P acceleration feature, including its basic concepts, configurations, how to use it, and how to troubleshoot errors.
What is P2P acceleration
When an ECS instance pulls an image, all image data comes from the server. When dozens of ECS instances pull the same image at the same time, the server maintained by Alibaba Cloud ensures a smooth download experience. However, if your cluster consists of hundreds or even thousands of ECS instances, the server bandwidth limit can throttle your image distribution speed.
Container Registry Enterprise Edition supports P2P acceleration, which significantly improves the image download speed when a large number of cluster nodes are pulling the same image. This helps speed up application deployment.
- P2P acceleration performs better when the cluster contains more than 300 nodes.
- We recommend that you deploy cluster nodes across multiple zones and VSwitches.
- We recommend that you use ECS instances that support local SSD or have large memory.
- P2P acceleration may not be effective when the cluster contains a small number of nodes or idle memory is insufficient.
Configure the P2P acceleration plug-in
Currently, the P2P acceleration plug-in supports the following cluster types: Kubernetes cluster, multi-zone Kubernetes cluster, and managed Kubernetes cluster. Serverless Kubernetes cluster is not supported.
To install the plug-in, log on to a Linux or Windows server and use kubectl to connect
to your Kubernetes cluster. Run the
kubectl get pod command. If the output indicates that the cluster is running normally, you can then
install the plug-in.
We recommend that you use SSH to log on to a random node in the cluster. To log on to a worker node, see Connect to Kubernetes clusters through kubectl.
We recommend that you modify the
max-concurrent-downloads parameter in dockerd to speed up image download. Default is 3. You can change it
to a value between 5 and 20. For more information, see this Docker official document.
The installation script differs depending on the instance. Log on to the Container Registry console and check the P2P Acceleration page for detailed instructions.
Pull an image through P2P acceleration
To pull an image through P2P acceleration, you need to use a domain whose name contains
distributed. For example,
hello-df-registry-vpc.distributed.cn-hangzhou.cr.aliyuncs.com:65002. For more information, see the Install the P2P acceleration plug-in through a script
section on the P2P Acceleration page.
By default, port 65002 is used. If you want to use port 443, you can specify
export PORT="443" when you install the plug-in. Note that this will occupy port 443 on all nodes.
Before you pull an image, you need to log on to the corresponding image repository.
docker login hello-df-registry-vpc.distributed.cn-hangzhou.cr.aliyuncs.com:65002. To pull an image, use the docker pull command or specify the image when you create
an application in the console. For example, to pull from image repository bar under
namespace foo, run the following command:
docker pull hello-df-registry-vpc.distributed.cn-hangzhou.cr.aliyuncs.com:65002/foo/bar.
When you pull an image through P2P acceleration, image layer data is pre-downloaded in the background and then transmitted to Docker Engine. This is the reason that the download progress bar remains stuck at the beginning and reaches 100% within a short time later.
In testing, 300 ecs.i2.xlarge nodes, each of which uses a local SSD and has a specification of 4-core 8 GB, are used to concurrently pull an image, which consists of 4 image layers and each layer is 512 MB in size. The download time is shortened by 80% compared with when P2P acceleration is not used.
To list the pods that have installed the P2P acceleration plug-in, run the following command:
kubectl get pod -n cr-dfagent -o wide
- If the number of pods is not the same as that of worker nodes:
- Check whether the nodes where no pod is deployed have taints, which affect the scheduling of DaemonSet.
- Install the P2P acceleration plug-in again.
- If some of the pods are in the CrashLoopBackOff state, run the
kubectl logscommand to view logs about these pods.
kubectl -n cr-dfagent logs -f POD_NAME df-agent kubectl -n cr-dfagent logs -f POD_NAME df-nginx
If the issue persists, submit a ticket.