About multi-cloud container management
Introduction
Multi-cloud container management is a solution that provides container multi-cloud and hybrid cloud services through the Multi-Cloud Container Platform (MCP). Users can deploy container applications on different cloud platforms or cloud platforms of different vendors. MCP performs unified deployment of containers and traffic distribution to different clouds, separating service data from management data and improving service reliability.
Concepts
MCP cluster
An MCP cluster is a Kubernetes cluster that manages other member clusters in multi-cloud container management. An MCP cluster can manage multiple member clusters, including unified deployment, release, and O&M of these member clusters.
Main cluster instance
A main cluster instance is an MCP cluster. All member clusters managed by an MCP cluster run on the main cluster instance corresponding to the MCP cluster. Different Pods of a container application can be deployed in different member clusters of a main cluster instance.
Member cluster
A member cluster is a Kubernetes cluster that is managed by an MCP cluster. A member cluster provides actual services in multi-cloud container management. Different Pods of a container application can be deployed in different member clusters of a main cluster instance. A member cluster can be a cluster created through the cloud container engine service provided by CloudOS or a cluster created through other platforms.
Namespace
Configure namespaces to implement logical isolation between applications (except for nodes and storage). Applications in different namespaces cannot access each other by default.
Workload
A workload is a stateless application running on the MCP cluster. A stateless application is a Kubernetes Deployment, which is the most commonly used controller. Different instances of a stateless application have no difference. After an instance is restarted, it cannot perceive the information and state of the previous instance. Stateless applications are suitable for services that do not require intermediate state data. Common microservices are stateless applications.
Configuration center
You can configure stateless ConfigMaps and secrets in the configuration center to set up the configuration system of Kubernetes. It decouples configuration from containers, so the configuration will not be removed or changed when the containers are destroyed or restarted. After being created, a container can directly load the configuration. The configuration center also enables you to perform unified configuration management and maintenance.
|
|
A Pod is the smallest unit of deployment and management for applications and services in a Kubernetes cluster. A Pod is a group of one or more containers (corresponding to applications). |
A ConfigMap stores non-confidential container service data in key-value pairs, such as log saving paths and Pod dependencies.
A secret stores sensitive Pod information, such as passwords and tokens.
By using ConfigMaps, you can mount the configuration file of a container application to the specified directory of the instance. For example, you can mount the YAML or properties file of a spring boot application to the directory where the jar package resides. When the instance starts, the jar package will use the configuration file in precedence.
As a best practice to facilitate configuration modification, do not add the application configuration to the JAR package directly. For container applications, you can configure ConfigMaps or use the configuration center.
Network access
Configure Kubernetes Service to implement network access. Kubernetes Service defines the policy of grouping Pods logically and the policy of accessing the Pods. When a member cluster is destroyed, the Pods running on the member cluster will also be destroyed, and then the system will create new Pods to run applications. Each Pod in the Kubernetes cluster has an independent IP address, so the change of a Pod will cause the change of its access IP address. You can configure Kubernetes Service to reduce the network access complexity. A Service can be defined by YAML or JSON. In the current software version, the system supports the following Service types:
ClusterIP—A ClusterIP Service can be accessed only within the cluster through an internal IP. It cannot be accessed outside of the cluster.