Background Introduction

In the edge computing scenario, it is necessary to manage multiple edge sites in the same cluster. Every edge site has one or more computing nodes. Meanwhile, it is necessary to run a set of services connected with business logic in every edge site. The services in every site are provided with a complete set of features to provide services to users. However, cross-site access between services with business connections is undesirable or impossible due to network restrictions. Native Kubernetes cannot control the location of nodes created by the Deployment Pod, and it will be done indirectly through the overall planning of the affinity of nodes. When there are too many edge sites and services to be deployed, it is extremely complicated to deploy and manage them, and even only theoretically possible. Furthermore, to limit the inter-service call within a certain range, the business party needs to create an exclusive service for each deployment. The management workload is heavy, and it is prone to errors and results in the online business exception.

For this reason, edge clusters provide unitized deployment capabilities. Hundreds of geographic service deployments can be easily implemented through unitized resource solutions. You do not need to configure or modify the application. Through the unitized deployment, you can easily deploy an individual set of services in different computer rooms or regions in the same cluster and make requests between services be completed within the local computer room or local domain, avoiding cross-regional access of services.

Core Concept