Container engine service

This feature is not displayed on the Web interface if you do not request a container engine license for the management platform. To use this feature, purchase the related license as described in H3C Software Products Remote Licensing Guide.
The container engine service is available only when the container service is enabled. For more information about container configuration, see "Configure container settings."
The container engine service requires the role of operator admin. Do not disable this role.
ARM host do not support the container engine service.

The container engine consolidates compute, network, and storage, allowing you to create a highly available, scalable Kubernetes cluster. With disaster recovery and autoscaling, the container engine can manage the lifecycle of applications, simplifying cluster management and applications O&M.

The container engine service offers workloads and container clusters.

Clusters

A cluster is a set of compute, storage, and network resources that run containerized applications. Nodes in a cluster include controller nodes and worker nodes. A controller node determines where an application must run. A worker node runs containerized applications. It is managed by the controller node and monitors and reports application status, and manages the application as required by the controller node.

Figure-1 Cluster structure

Workloads

Workload is a concept in Kubernetes. Workloads provide automated and one-key container management capabilities. Workloads in Kubernetes include the following:

Pod—Smallest deployable unit that you can create or manage in Kubernetes. A pod is a group of one or more containers (applications). Containers in the same Pod share the storage volumes and network protocol stack.
Controller—Typically, Kubernetes does not create Pods directly. It manages Pods through controllers, which define the Pod deployment attributes, such as the number of copies, and on which nodes they are running. To meet the requirements of different services, Kubernetes provides the following types of controllers:
- Deployment—Manages multiple replicas of a Pod, and changes the actual state of the Pod to the desired state.
- StatefulSet—Ensures the ordering and uniqueness of Pods. The name of a Pod will not change after it is deleted or restarted.
- DaemonSet—Ensures that all or some nodes run a copy of a Pod. When nodes are added to the cluster, Pods are added to them. When nodes are removed from the cluster, these Pods are garbage collected. Deleting a DaemonSet will delete all Pods that it created.
- Job—Runs Pods that can be deleted after termination, while Pods in other controllers run continuously.
- CronJob—Creates Jobs on a schedule. Unlike a Job, a CronJob supports creating scheduled tasks, like scheduled backups and notifications.
  Figure-2 Workloads

Other cluster management capabilities

The container engine also provides namespace management, ConfigMap management, service configuration, storage configuration, and autoscaling functions for Kubernetes cluster management and maintenance.

Applications run in a Kubernetes cluster as containers. Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. A Pod has one or multiple containers running on it. Managing a Kubernetes cluster is actually managing the containers running in it.

Figure-3 Kubernetes capabilities

Service

A service exposes an application running on a set of Pods as a network service. In Kubernetes, each Pod gets its own IP address, but the IP address might change upon a Pod restart. Kubernetes assigns a service an IP address (the cluster IP) to map the service to Pods. To access a container, a user only needs to access the cluster IP, no matter whether Pods change or not.

The following are the service types:

Access from outside a cluster
- Load Balancer—The IP address and port of each node are registered to a load balancer. The load balancer selects a node when an application requests to access the cluster, and then the application can access a container through the service port and container port.
- Node port—Access a container through node IP, node port, service port, and container port.
Access from within a cluster (Cluster IP)—Access a container through cluster-internal IP, service port, and container port.
Figure-4 Service architecture

Storage

PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) in Kubernetes provide storage space for clusters.

PV—A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using storage classes.
PVC—A request for storage by a user. This request contains the capacity and access mode for the storage resource. Kubernetes searches for and provides matching PVs.

Configuration

In Kubernetes, the configuration system contains ConfigMaps and Secrets, allowing you to decouple configuration from your container images to keep containerized applications portable. Additionally, with this configuration system, you can manage and maintain configuration information in a unified manner.

ConfigMap—An API object used to store non-confidential data in key-value pairs, such as log saving paths and Pod dependencies.
Secrets—Allow you to store and manage sensitive information, such as passwords and certificates.

Namespace

Namespaces are a way to isolate applications. Applications in different namespaces cannot access each other.

Autoscaling

When the CPU or memory usage reaches the specified threshold, your cluster scales up automatically for the nodes in the cluster to share load until the number nodes in the cluster reaches the upper limit.