This document describes how image cache works and its billing rules, creation, and usage method. You can use image cache to accelerate image pull during instance creation so as to expedite instance startup. This capability is applicable to TKE Serverless cluster Pods and super nodes.
How does it work
During the accelerated startup of instances using image cache, a container instance is pre-launched to pull the image, which is stored on a customizable-sized data disk. This data disk is then used as a Cloud Block Storage (CBS) snapshot cache, meaning the image data is already saved in the snapshot. When creating a container instance or Pod, selecting automatic or manual image cache matching will create the corresponding number of disks (data disks) based on the image snapshot and directly mount them to the instance, bypassing the need to download image layers, thus improving the creation speed of container instances and Pods.
Compared with the image reuse capability, image cache has the following strengths:
It has no time limit and is only subject to the lifecycle of the image cache (snapshot).
You only need to cold start a Pod in advance, which will be terminated immediately after snapshot creation.
It has no limit on AZs, as AZs will be automatically matched during cloud disk creation based on snapshot.
It has no limit on workloads, as workloads in the same region can be matched.
Billing
The following resources are involved when you create an image cache, and their billing rules are as detailed below:
Billable Items
Billing
Documentation
Mirror cache
When you create an image cache, you need to run a 2C4G container instance to pull the image. After image cache creation, the container instance will be automatically released, and its billing will stop.
When you create an image cache, you need to bind a Premium Cloud Storage data disk to store the image. The disk size is customizable and 20 GB by default. After image cache creation, the data disk will be automatically released, and its billing will stop.
A snapshot will be created based on the above-mentioned data disk, and its lifecycle will be the same as that of the image cache. It is billed by usage duration and capacity.
When utilizing the image cache, a Premium Cloud Storage data disk of the same capacity will be created based on the matched image cache snapshot and attached to the Pod. Therefore, in addition to the cost of creating the Pod itself, additional data disk fees will be incurred. The formula for calculating the data disk fees is as follows:
Data disk fees = Capacity * Unit price * Instance runtime duration
2. Select Application Center > Image Cache in the left sidebar, and click Create Instance on the Image Cache page.
3. On the Create image cache page, configure relevant parameters, as shown in the figure below:
Instance name: custom.
Region: select as needed.
Container network: assign an IP address within the container network IP range to the container instance.
Security Group: a security group has the capabilities of a firewall and can limit the network communication of the instance. It is "default" by default.
Operating system: Select Windows or Linux.
Image: select the image and version to be cached as needed.
Image Credentials: when you select Docker Hub or a private image in a third-party image repository, you must enter the image credentials, i.e., access address, username, and password of the repository.
Advanced settings:
Cache size: It determines the size of the snapshot and the data disk bound during instance creation.
Note:
The image size displayed in the image repository is the size of the compressed data. Creating an image cache involves pulling and expanding the image. If the image or image compression ratio is too large, the default 20 GB data disk will be insufficient, so a larger data disk space is recommended.
Expiration policy: Select the retention duration of the image cache, which is "Permanent" by default.
4. Click Create instance. After the image cache is created, it will be displayed in the image cache list. You can click the event name to view the creation progress.
Creating image cache with CRD
The image cache add-on needs to be installed in the cluster if you want to create an image cache with CRD. After the add-on is installed, you can use Tencent Cloud image cache with the method of CRD+Controller without the need to call the cloud API. The steps are as follows:
If there are any exception, you can check the events:
kubectl describe imc xxx
Using an existing image cache
When creating a Pod in a Serverless cluster, you can enable the image cache feature by clicking Show Advanced Settings on the Create Workload page, as shown in the following image:
Two image cache match methods, Automatic match and Manual match, are supported. Select one as needed.
Automatic match
Manual match
If you select Automatic match, the optimal image cache will be matched automatically according to the following match policy:
If the image names and versions are completely the same, the image cache can be matched.
Images with a smaller cache size will be matched first.
Images with a later creation time will be matched first.
Note
If the versions are both "nginx: latest", the image cache can still be matched; however, as the creation time may be different, the versions may be inconsistent. Therefore, we recommend you specify the version clearly when creating an image cache and instance.
If the corresponding image cache fails to be matched, an image will be pulled normally.
If you select Manual match, you need to manually select a specific image cache. Note that after you manually specify an image cache, a data disk will be directly created based on the image cache snapshot and bound to the instance. However, if the data disk does not have the image entered during instance creation (that is, an incorrect image cache is specified manually), an image will be pulled from the newly created data disk.
You can specify a Pod annotation to use an image cache on super nodes in TKE clusters. For more information, see super node Annotation.
You can check whether the match succeeds in the instance creation event.
If the match is successful, the following event will be displayed:
If this event is not displayed, no appropriate image caches have been matched.
Note that if you choose to manually match an image cache but it fails to be matched, an image will be pulled from the newly created data disk, and the following event will be displayed: