Using Traffic Distribution to Implement Traffic Switchover

Application Scenarios

Distributed clusters are often deployed on the clouds or regions nearest to users for low latency. However, if a cluster in a region is faulty, service access in that region will be affected. UCS allows you to manage application traffic and data for traffic switchover, scheduling, and migration across clouds and clusters. Figure 1 shows how UCS switches traffic from a faulty cluster to ensure service continuity.

Figure 1 Traffic switchover in multi-cloud clusters

Constraints

• You have two available clusters of version 1.19 or later, and each cluster must have at least one available node.
• You have added a public zone to Huawei Cloud DNS. For details, see Routing Internet Traffic to a Website.

Setting Up the Environment

1. Register clusters to UCS and configure cluster access. For details, see Registering a Cluster.

   For example, register ccecluster01 and ccecluster02 to UCS and check whether they are running normally.

2. Create a workload in each connected cluster.
   

   In this example, container images with different tags are used to create workloads, aiming to show you more clearly how application traffic is switched.

   • ccecluster01: Image tag 1.0.0 is used.
   • ccecluster02: Image tag 2.0.0 is used.

3. Create a LoadBalancer Service for the workloads in each cluster.
   

   Only LoadBalancer Services are supported and displayed.

4. Use a browser to access the IP of the LoadBalancer Service to check the deployment result.

Verifying Traffic Switchover

You have deployed applications in clusters ccecluster01 and ccecluster02 and allowed external access via LoadBalancer Services.

The following describes how to distribute application traffic to realize traffic switchover and ensure high availability.

In this example, example clusters and workloads are not limited in terms of service providers, regions, and quantity.

1. Log in to the UCS console. In the navigation pane, choose Traffic Distribution.
2. Click Create Traffic Policy. In the window that slides from the right, enter the domain name (use demo.example.com here).
   Figure 2 Creating a traffic policy
   

3. Add scheduling policies for the two clusters and click OK.

   In this example, three scheduling policies are added to simulate cluster application deployment in different regions:

   • For ccecluster01, set Line Type to Region line - Global/Asia-Pacific/Singapore.
   • For ccecluster02, set Line Type to Region line - Chinese Mainland/South China/Guangdong.
   • Add a default line for the domain name. For ccecluster01, set Line Type to Default. If no default line is added for the domain name, users in regions beyond the specified lines cannot access the applications.

4. View the scheduling policies. Three policies have been added for demo.example.com. User traffic can access applications in the two clusters based on the configured line type and weight.
   • Users in Singapore will access application 1.0.0 in ccecluster01.
   • Users in Guangdong will access application 2.0.0 in ccecluster02.
   • Users in other regions will access application 1.0.0 in ccecluster01 by default.

5. A user in Guangdong visits demo.example.com to access the application. The response shows that the user is accessing application 2.0.0 in ccecluster02.
   Figure 3 Checking the access result
   

6. Manually stop the application in ccecluster02 and change the number of pods to 0 to simulate a fault.
   Figure 4 Adjusting the pod quantity
   

7. When a user in Guangdong accesses the application, the request is still sent to ccecluster02 and an error is returned.

   In this case, click Suspend for the corresponding scheduling policy of ccecluster02 on the Traffic Distribution page to perform traffic switchover.

   After that, the subsequent access requests of this user will be sent to ccecluster01 through the default line, and the access becomes normal. After the faulty cluster is recovered, you can click Enable to enable the policy again.