1. Application Architecture Matches Business Growth and Operations Capability

At industry conferences, in documents and blogs, we constantly see all kinds of excellent solutions — but if you copy them straight into your own business, you keep hitting walls. Because these technical solutions were incubated in specific business scenarios; different business forms, different business scales, and different stages of business development all affect how technology lands.

On the other hand, applications need people to maintain them, and a suitable platform must be built to assist with application lifecycle management — which requires matching operations capability. Lagging operations capability lowers production efficiency and gives competitors an opening; operations capability that is too far ahead has a low return on investment and can easily drag a company down.

We do not need to build a Weibo just to handle a few tens of thousands of QPS of traffic and cope with various hot-spot traffic surges; nor do we need to hire a batch of top experts to chase the latest technology fads and burn through cash flow.

Application architecture matches business growth and operations capability. As the business moves forward and makes money, with more users and more demand, it drives architectural upgrades; and those architectural upgrades in turn serve users better and enable more users to succeed. This is a dynamic, mutually reinforcing process, and it also drives the flow of technical people, who find the right position in the market.

2. Kubernetes Under Multiple Locations, Early Stage

As shown in the figure above, in the early days of business growth we can deploy applications in the regions where customers are concentrated, providing service nearby.

Each Location can provide an independent, complete external service. Location can be interconnected with Location over the public network, establishing tunnels to carry the transmission of control flow. The control flow here is not limited to commands; it can also be user metadata and the like, but it should not transmit user-generated data, such as uploaded images, documents, and so on.

Because of business isolation, many Kubernetes clusters are deployed in each Location. The fewer nodes a single Kubernetes has, the easier it is to maintain, the smaller the blast radius, and the more controllable the risk.

But this also means we will have many clusters, and managing and maintaining these clusters also takes manpower. At the same time, differences in cluster versions also increase the difficulty of development adaptation, affect application technology selection, and weaken the value of accumulated operations experience.

3. Kubernetes Under Multiple Locations, Middle Stage

As shown in the figure above, once the business has a certain scale, we can consolidate clusters.

In the early days, to avoid risk, the number of clusters would be very large; a department with hundreds of clusters brings huge costs to cluster management and maintenance.

Cluster maintainers focus every day on insufficient resources, memory leaks, images that cannot be pulled, adding and removing nodes, insufficient permissions, configuration differences, and so on. On the other hand, what they see is that some new clusters have very low load and very new kernel versions, and users report no problems. That is also the downside of having a large number of small clusters: high maintenance cost and limited room for HPA scaling.

By consolidating clusters, we can effectively raise the overall load rate of the cluster. But along with that come all kinds of problems brought by ultra-large-scale clusters:

• Scheduling efficiency
• Network management
• Service forwarding
• Metering and billing
• …

After solving these problems, a series of benefits follows:

• Improved resource utilization
• Huge room for scaling
• Better cluster management

Along with deeper exploration of Kubernetes and the surrounding technology stack, this cultivates a group of technical people with more insight into cloud native.

4. Kubernetes Under Multiple Locations, Late Stage

First we need to reach a consensus: when operations capability allows, one large cluster is better than a large number of small clusters.

Second, anything that can be done inside a cluster should not cross clusters. In the early stage, because services were distributed across various small clusters, frequent cross-cluster service calls were not only low in performance but also extremely costly in maintaining forwarding rules.

Although consolidating clusters can solve these problems, in the late stage a single large cluster cannot withstand the impact of large traffic in a single Location. Therefore, we have the figure below:

In one Location, we divide several Regions; each Region is a large cluster, and Region is interconnected with Region over internal network lines, able to transmit both control flow and user data.

Of course, if the business architecture has been unitized, then each cluster is a Unit. This is not only clearer for developers, but also lets operations staff quickly understand the architecture and integrate into the team whether or not they are familiar with Kubernetes.

As shown in the figure above, a Region contains several units. These units belong to different environments and different businesses, but they are architecturally equivalent, and through unified platform software we can manage these units without distinction.

5. Summary

This article is mainly about some thoughts on deploying Kubernetes across multiple regions. This content originated from a major application architecture adjustment I am going through at work. I put the overseas and domestic businesses and application architectures together and found that they only differ in the business stage they are in; their architectural evolution is consistent.

At first the business volume was small, and many small Kubernetes clusters were quickly deployed to bring business online; as operations capability improved, the cluster scale grew larger and larger; but growing infinitely is also impossible, and in the end it returns to a scalable, unitized cluster solution.