5.0 Introduction to Container Management Capabilities¶

Since Docker was open-sourced in 2013, the container technology represented by Docker has brought disruptive changes to the software industry. The digital economy has become an important driving force for contemporary economic development. Cloudification of infrastructure and cloud native software have become an inevitable trend in the development of technology in the entire society. All walks of life, represented by the financial industry and based on traditional manufacturing, are actively embracing and exploring this new trend of technological development. Cloud native technology abstracts the underlying infrastructure, enabling developers to focus on the development of the application itself without worrying about the underlying system architecture and other O&M issues, making the application more flexible and efficient. The fifth generation of Daocloud Container Management (Kpanda) is a cloud native workload-oriented container management platform built on the basis of Kubernetes open source technology. It is based on the native multicloud architecture and completely decouples the underlying foundation facility platform, Realize the unified management of multicloud and multicluster, further simplify the application cloud process of enterprises, and reduce operation and maintenance management and labor costs. Supports one-click creation of Kubernetes clusters, helping enterprises quickly build enterprise-level container cloud platforms.

The main features of container management are as follows:

Container management function

Cluster Management

Unified management of multicloud and multiclusters, supporting any Kubernetes cluster within a specific version range to be included in the scope of container management, realizing unified management of multicloud and hybrid cloud container cloud platforms on and off the cloud.
Rapid cluster deployment, quickly deploy enterprise-level Kubernetes clusters through the web interface, quickly build enterprise-level container platforms, and adapt to the underlying environment of physical machines and virtual machines.
Cluster one-click upgrade, supports one-click upgrade of cluster Kubernetes version.
The cluster is highly available, with built-in cluster disaster recovery and backup capabilities, supporting rapid recovery of the business system in the event of host failure, computer room interruption, and natural disasters, further improving the stability of the production environment and reducing the risk of business interruption.

node management

Supports full lifecycle management of nodes in the management cluster and the worker cluster created based on the management cluster.
Real-time monitoring of node status. Supports real-time monitoring of the status of nodes and pods running on nodes.
Support logging in and managing nodes through the interface CloudShell.
Provides basic cloud native capabilities for managing node scheduling policies, labels, stains, and annotations.

Workload management

One-stop deployment, decoupling the underlying Kubernetes platform, one-stop deployment and operation and maintenance of business applications, and realizing the full lifecycle management of workloads.
Scaling and shrinking of workloads. Manual/automatic scaling of workloads can be realized through the interface, and custom scaling policies can be used to cope with traffic peaks.
The full lifecycle of workloads supports full lifecycle management such as workload viewing, updating, deleting, rolling back, time viewing, and upgrading.
Unified management capability across cluster loads.

Plugin Management

Built-in DaoCloud self-developed core plug-in library, supports the introduction of Helm official library and private plug-in registry, and provides users with a large number of plug-ins.
Provides full lifecycle management capabilities for adding, deleting, modifying and querying plug-ins.
Record operations such as plug-in installation, update, and deletion, and display them in console logs that are easier for O&M personnel to understand, making plug-in O&M more cloud native.

Internet access

Provides cloud native load balancing capabilities, accessed through fixed IP addresses and ports. Currently supported network access modes include:

Intra-cluster access (ClusterIP): Access services only within the cluster.
Node access (NodePort): Use node IP for access.
Load Balance (LoadBlance): access based on the external load of the public cloud vendor.

Storage Management

Data volume management: supports local storage, file storage, and block storage, accessed through CSI capabilities, and provided for workload workloads.
Dynamic creation of data volumes: support StorageClass to dynamically create data volumes
StorageClass management: Compatible with various mainstream storage technologies in the industry and storage plug-ins that conform to the standard Kubernetes CNI architecture.

authority management

Supports unified management of multicluster permissions, combines Kubernetes' native RBAC role access control and user authentication of the global management module, and provides permission control at the workspace level, cluster level, and namespace level. Based on previous experience in production operation and maintenance management in multiple industries such as finance, banking, and traditional manufacturing, it provides a variety of out-of-the-box enterprise authority control solutions to help enterprises with different organizational structures quickly authorize users/groups.

Cluster operation and maintenance

Supports all-round metric monitoring and alerting at the cluster level, node level, load level, and container level, and integrates various resource status unified monitoring dashboards. Provides cluster automatic/manual inspection capabilities to help O&M and developers understand the status of cluster resources in real time and ensure business continuity.

openAPI

Provide cloud native Kubernetes OpenAPI capabilities, break through the boundaries between container management and different systems, and quickly empower users to migrate their business to the cloud.

Kubernetes friendly web terminal CloudTTY

When many enterprises use the cloud platform to manage Kubernetes, for security reasons, they do not support the use of SSH to directly connect to the business host, so the Cloud Shell capability is required. The fifth-generation container management module of Daocloud introduces the self-developed open source component CloudTTY, which supports direct connection to the cluster through CloudShell. And provide the ability to operate and maintain the cluster through the Kubectl tool.

Graphical user interaction¶

The container management module is an aggregation platform for multicluster management, which supports users to manage clusters from different vendors and regions in a unified manner. Help enterprises to quickly migrate to the cloud and meet the use cases of multicloud and multicluster management for users. In terms of hierarchical structure, a three-level architecture is adopted. The top layer abstracts the use cases commonly used by users, and extracts several modules such as cluster list, namespace, workload, and authority management.

Through the Clusters interface, users can clearly perceive real-time information such as the running status, resource usage, and number of nodes/pods of each cluster. And it can enter the details of the cluster based on the cluster name, and perform fine-grained management of the cluster's nodes, workload, service and routing, operation and maintenance management and other features. At the same time, if users want to use kubectl to manage the cluster, they can also use the CloudTTY desktop console tool on the interface.
On the namespace interface, users can perceive the status of namespaces under all clusters with permissions, and can set quotas and bind/unbind workspaces for different namespaces.
On the Workload interface, users can perceive the global overview information of workloads such as workload status and resource usage under all clusters with permissions.
On the Privilege Management interface, users can view and authorize the permissions of users/groups based on the two levels of cluster and namespace.
On the Cluster Details interface, users can view detailed cluster overview information and manage the full life cycle of resources in the cluster. Features including node management, service and routing management, workload and pod management, namespace management, Helm plug-in management, storage management, operation and maintenance management can all be operated in the cluster details interface.

Best Practice Exploration¶

After building the first global service cluster (Kpanda) locally, you can manage the container cluster through the Web UI. You can use the container management module to implement functional operations such as accessing clusters, creating clusters, and deploying applications with one click.

Access to cluster

First go to the control node of the target cluster to obtain its KubeConfig file, then click the button to access the cluster at the Clusters of the container management, and copy and paste the content of the KubeConfig file as a parameter to the Access Parameters In the form, the access operation to a cluster is completed.

Create cluster

The container management module supports the creation of two types of clusters: worker cluster and management cluster. Users can choose the corresponding cluster mode according to their own business needs. The difference between the management cluster and the worker cluster is that the management cluster only runs system components and does not deploy services to ensure high availability of the cluster. The worker cluster only runs business-related loads. At the same time, the management cluster supports the management of the worker cluster. It can create a worker cluster based on the management cluster, and configure the network, nodes, plug-ins and other operations for the worker cluster during the creation process.

Deploy workload

The container management module supports deployment and management capabilities based on Kubernetes-native workload types, including: creation, configuration, monitoring, expansion, upgrade, rollback, deletion, and other full lifecycle management.

Elastic Scaling: Through the interface, the manual/automatic scaling capability of the workload can be realized, and the scaling policy can be customized to cope with traffic peaks.
Container life cycle settings: Support setting callback function, parameters after startup, and parameters before stopping when creating workloads to meet the needs of specific cases.
Container readiness check, liveness check settings: support setting workload readiness check and liveness check when deploying workload:
Workload Readiness Check: It is used to detect whether the user business is ready. If not, the traffic will not be forwarded to the current instance.
Workload Survival Check: The user checks whether the container is normal. If there is an exception, the cluster will run the container restart operation
Environment variable settings for containers: You can specify environment variables for business container operating environment settings.
Automatic scheduling of containers: Support workload service scheduling management, automatically schedule containers according to host resource usage, specify specific deployment hosts, and schedule containers through label policies.
Affinity and anti-affinity: Supports the definition of affinity and anti-affinity for scheduling between pods; and affinity and anti-affinity between pods and nodes to meet business customization Scheduling needs.
Container security user settings: Support setting the container running user, if running with Root privileges, fill in Root user ID 0.
Custom Resource (CRD) Support: Support the creation, configuration, deletion of custom resources and other full life cycle management and the ability to create instances (CR) based on custom resources.

Who Needs Container Management¶

Large-scale financial, banking, aerospace, and traditional manufacturing companies with large businesses, or cross-regional or cross-departmental operations that require unified operation and maintenance management.

Solve what problem¶

While it is generally best practice to use as few clusters as possible in the software generation process of the modern enterprise, enterprises choose to deploy multiple clusters for a variety of reasons to achieve various technical and business goals. Most enterprises place at least various services in separate clusters, separating non-production services from production services. In more complex cases, enterprises may choose multiple clusters to separate services across tiers, locales, teams, or infrastructure providers.
Ultra-large-scale projects are deployed on a cluster. In order to ensure the availability of workloads, nodes can only be manually added to the cluster. However, the maximum number of Pods in Kubernetes has a limit. Simply adding physical nodes cannot solve the fundamental problem. And the difficulty and cost of operation and maintenance are increasing rapidly.
In hybrid cloud cases, the types of clusters are complex. There are remote edge fusion clusters, local self-built computer room clusters, Xinchuang clusters, and public cloud clusters. There may be differences in the Kubernetes versions of the clusters. How to manage these clusters with different architectures in a unified manner question.
As enterprises look to adopt application modernization practices in more traditional work environments (such as registrys, factory floors, retail stores, etc.), this requires managing more workloads on more infrastructure components.
When enterprises are concerned about potential in-place upgrade issues (i.e. upgrade automation failures, application instability, or rollback functionality), they can choose to deploy copies of their services into new clusters. Upgrading in this way requires planning or automation to enable, ensuring that traffic management and state replication are handled during the upgrade process.

Use cases¶

Explore a multi-room, cross-regional container scheduling method to achieve unified management of clusters in different regions, reduce manpower and material resource consumption, and reduce costs.
Explore elastic scaling at the cluster level, support the creation of clusters, open up the boundaries between clusters, and explore the way of deploying workloads across clusters.
Explore the compatibility and unified management of different cluster types to form a unified management plane for resources.

FAQ¶

Q: Which vendors' clusters are container management compatible with?

A: The fifth-generation container management is compatible with any distribution container cluster based on the standard Kubeneters ApiServer, including AWS, Google Cloud, Xinchuang Architecture, and Edge-Cloud Integration.
Q: How to deal with cross-cluster network outages?

A: In order to ensure high service availability, the business is deployed on multiple cloud container platforms in different regions at the same time to help applications realize multi-region traffic distribution, and realize cross-cloud application management on the same platform, reducing operation and maintenance costs. In addition, when a cloud container platform fails, business traffic is automatically switched to other cloud container platforms through a unified traffic distribution mechanism.
Q: How to realize the management of clusters of other vendors?

Answer: By obtaining the KubeConfig file of other vendors' clusters, run thePerform the cluster access operation, fill in the KubeConfig file of the target cluster, and complete the access management of a container cluster.
Q: How to get the real-time status of multicluster resources?

Answer: With the help of the self-developed open source component ClusterPedia, by installing the Agent component on the target cluster, combined with the Watch mechanism, the resource change information of the target cluster can be synchronized to the ETCD of the container management cluster in real time.
Q: What is the positioning of container management in the fifth generation of products?

A: In the fifth generation of products, the container management module is at the core of connecting the past and the future. Right above: docking with DCE 5.0 product modules and future customized modules. For the upper-level scenario management module, the container management module can expose any standard Kubernetes API, whether it is a product center, Karmada, or an application store, as long as you need to call the Kubernetes API, you can manage this module through the container To call the underlying Kubernetes API of any platform. To the next: docking with Any Kubernetes, such as the edge K3S undefined Xinchuang environment, DCE, DKG, DKE, and external Openshift, Tanzu, CCE, etc. are all based on the container management module.
Q: Who can create a cluster?

Answer: Users with Global Admin and Kpanda Owner roles can create clusters.
Q: Who can manage the cluster?

Answer: It depends on the access control solution adopted by the user. Generally speaking, in addition to users with the roles of Global Admin, Kpanda Owner, Cluster Admin, and Cluster Admin, users with the role of Cluster Edit and users with strong binding Floder Admin and WorkerSpace Users with the Admin role can also add, delete, modify, and query resources in the cluster, and authorize users.

Learn about container management

Download DCE 5.0 Install DCE 5.0 Free Trial