Help Center> Cloud Container Engine> Best Practices> Cluster> Implementing High Availability for Containers in CCE

Implementing High Availability for Containers in CCE

Basic Principles

To achieve high availability for your CCE containers, you can do as follows:

Deploy containers in a cluster.
When nodes are deployed across AZs, set custom scheduling policies based on site requirements to maximize resource utilization.
Create multiple node pools in different AZs and use them for node scaling.
When creating a workload, set the number of pods to be greater than 2.
Allow the workload pods to be randomly scheduled to different nodes in the cluster.

Procedure

Assume that there are four nodes in the cluster: demo-92634, demo-01208, demo-30509, and demo-27003. Demo-92634 and demo-01208 are in the same AZ (AZ 1), demo-30509 is in AZ 2, and demo-27003 is in AZ 3.

Log in to the CCE console. In the navigation pane, choose Workloads > Deployments. On the page displayed, click Create Deployment.
Configure the following parameters and retain the default values for other parameters.
- Workload Name: name of the workload. Set this parameter to nginx-demo.
- Instances: Set it to 1 in this example.
Figure 1 Creating a workload
Click Next. In the dialog box displayed, click Add Container. On the Open Source Images tab page, select the nginx image and then click OK.
Retain the default values for other parameters, and click Next and then Create.

For details about how to create a workload, see Creating a Deployment.
In the workload list, click the name of the created workload (nginx-demo in this example).
On the Pods tab page, click the IP address of the node where the pod resides. Choose Resource Management > Nodes and click the node name. You will see that the pod is scheduled to a node in AZ 1.

Figure 2 AZ information
Back to the Deployment details page, on the Scheduling Policies tab page, click Add Custom Scheduling Policy. In the Pod Anti-affinity area, click Add Rule next to Preferred.
Set the parameter as follows to create a preferred anti-affinity rule for the AZ. For details, see Affinity and anti-affinity.
- Weight: A larger weight value indicates a higher priority. In this example, set it to 50.
- Topology Key: a default or custom key for the node label that the system uses to denote a topology domain. A topology key determines the scope where the pod should be scheduled to. In this example, set this parameter to failure-domain.beta.kubernetes.io/zone.
- Label: pod label. You can use the default label app or a custom label. Set it to app in this example.
- Operator: Four operators are provided for you to configure label matching relationships: In, NotIn, Exists, and DoesNotExist. Operators In and NotIn allow one or more label values. Operators Exists and DoesNotExist are used to determine whether a label exists, and do not require a label value. Set it to In in this example.
- Value: Set it to nginx-demo in this example.
Figure 3 Adding a rule
Repeat 7 to create another preferred anti-affinity rule for the workload. Set the parameters as follows:
- Weight: 50
- Topology Key: kubernetes.io/hostname
- Label: app
- Operator: In
- Value: nginx-demo
Figure 4 Adding a rule
Click OK.

On the Scheduling Policies tab page, you will see the scheduling policies you added.
On the Scaling tab page, click under Manual Scaling to add a pod. You will see that the pod is preferentially scheduled to a node in AZ 3.

Figure 5 AZ information
On the Scaling tab page, click under Manual Scaling to add another pod. You will see that the pod is preferentially scheduled to a node in AZ 2.

Figure 6 AZ information
On the Scaling tab page, click under Manual Scaling. You will see that the new pod is preferentially scheduled to the remaining node in AZ 1.

Figure 7 AZ information