All applications starts in the same way, usually with a simple deployment made up of a tiny and organised Docker Container which is built and deployed within minutes. As your business grows, that tiny Docker Container doesn’t rely on a small Image anymore, and the assets built in it, the compiled code and all those needed libraries starts eating up disk space like Godzilla.

Good news! This is a sign your business grew enough to face those problems. bad news! Your business core package is fat, and it doesn’t run as fast as it used to.

We face 2 problems here. One is the increased complexity that, maybe, can be resolved by investing some engineering hours into refactoring. The other problem is the time it takes to the Kubernetes Cluster to pull the Image when it needs scaling.

We will just focus on the second scenario, as the first one is pretty straightforward to understand (lots of coffee, yep).

Let’s say you have your platform running on an Alibaba Cloud Kubernetes cluster with a Deployment with some 4~5 replicas. Then, there is an increase in traffic and the Autoscaler starts adding pods to the Deployment to fit all those new users.

If your Image is too big, it will take very long to scale, as most of the time will be just occupied pulling the Image from the registry. Today, I bring you 2 solutions when using ACK.

Using Alibaba Cloud’s Own Container Registry

This solution is definitely a good fit if you have only one Kubernetes Cluster or if all your Clusters are in the same region, as we can take advantage of the internal Container Registry’s VPC endpoint to make the transfer lightning-fast and also save in that way some monies, as transfers happening within VPCs and between VPCs in the same region are free of charge on Alibaba Cloud.

As shown in the picture, the ACK Cluster will connect to the Container Registry using the internal VPC network, a route faster than the open Internet, certainly beating it on every single case and, as mentioned before, free of charge and more secure.

Using The Enterprise Edition of Alibaba Cloud Container Registry

This is the ideal solution when you have Clusters in more than one region, or if your Cluster is located in a different region than where you are pushing the images to.

As drawn in the picture above, the Enterprise Edition of the Container Registry has the ability of replicating Images between instances located in different regions. Why is this useful? One scenario where this is handy is when you have to use exactly the same Docker Image in different regions for compliance and reliability reasons. The other scenario is if you push Images to, as an example, North Virginia in the United States and you need to consume that Image in an ACK Cluster located in Shanghai, China. This last example means your CI/CD tool will push the Image locally in the US if that’s your region and, within minutes, your Image will be available to be used inside China Mainland. Pretty cool!

Conclusion

Kubernetes was made with the cloud inbuilt in its design. As its a complex framework to learn, its normal to feel a bit lost when dealing with some problems that, at first sight, should be easy to fix. This example is perfect to show how cloud providers, in this case Alibaba Cloud, implement Kubernetes into their product ecosystem to offer a perfect symbiosis between the Kubernetes API and the cloud provider API, mixing and matching their solutions to help you build your business.