×
Community Blog Lossless Migration of Business Traffic with Cloud Controller Manager for Kubernetes

Lossless Migration of Business Traffic with Cloud Controller Manager for Kubernetes

This article introduces Cloud Controller Manager (CCM), a core component of Alibaba Cloud Kubernetes (ACK), and explains its importance in migration.

By Gu Jing (Zibai)

1

Containerized application deployment can reduce enterprise costs, improve R&D efficiency, and free up O&M personnel. According to Gartner, the world's leading research and advisory company, 75% of enterprises will run containerized applications in production by 2022. Kubernetes is the first choice in this field. However, due to the complexity of its deployment and O&M, more customers choose to migrate their business from Elastic Compute Service (ECS) or self-built Kubernetes to Alibaba Cloud Managed Kubernetes (ACK). Thus, ensuring smooth business traffic migration becomes a major challenge.

Cloud Controller Manager (CCM) is a core component of ACK, which connects Kubernetes to other basic services, such as CLB, VPC, and DNS. When the service is set to Type = LoadBalancer, CCM creates or configures a CLB instance for the service. When the Endpoint or cluster nodes corresponding to the service are changed, CCM updates the backend VServer groups of the CLB instance automatically. In addition, CCM provides a number of annotations to implement various load balancing capabilities.

Recently, CCM released a new feature. It adds support for mounting nodes in the cluster and ECS outside the cluster to the backend of the same CLB instance. This facilitates smooth migration during business containerization.

Scenario 1: Containerized Application Transformation (Smooth Traffic Migration)

For a CLB cluster, traffic can be forwarded to the internal and external nodes of the cluster.

2

Operating Instructions

  • Log on to the CLB console and create a CLB instance. Record the CLB ID ("lb-xxxxx").
  • Create a Service

Set "service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners" to "false" to turn off the information listening

CCM will create a corresponding VServer group automatically.

cat <<EOF |kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "lb-xxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners: "false"
  labels:
    app: nginx
  name: my-nginx-svc
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
EOF
  • Log on to the CLB console. Create a listener and associate it with the VServer group
  • Log on to the CLB console. Add ECS instances outside the cluster to the VServer group manually and set the weight

Expected Outcomes

When the configuration is set, the nodes in the cluster and the ECS instances outside the cluster are available on the VServer page of CLB. The ECS nodes outside the cluster will not be affected by the expansion or shrinking of the applications in the cluster.

3

Scenario 2: Canary Release

Canary release is supported to forward traffic to nodes within and outside the cluster in proportion.

During the migration, traffic needs to be migrated from existing ECS instances to Kubernetes clusters step by step. CCM allows weight settings for Kubernetes clusters using "annotationservice.beta.kubernetes.io/alicloud-loadbalancer-weight" to implement traffic migration step by step.

4

Precautions

  • VServer group multiplexing across CLB instances is not supported.
  • A VServer group can only be associated with one port.
  • The weight of nodes in a cluster is set by the CCM component. The weight of ECS instances outside the cluster needs to be set manually.

Operating Instructions

  • Log on to the CLB console to create a CLB instance, a listener, and a VServer group. Record the CLB ID ("lb-xxxx") and the VServer group Id ("rsp-xxx") of the CLB instance.
  • Add ECS instances outside the cluster to the VServer group manually and set weights
  • Create a Service
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    # The internal weight of the cluster is 20%
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: nginx-svc
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

Expected Outcomes

When the configuration is set, the nodes in the cluster and the ECS instances outside the cluster are available on the VServer page of CLB. The weights of the nodes in the cluster are configured according to the annotations. The ECS nodes outside the cluster will not be affected by the expansion or shrinking of the applications in the cluster.

Scenario 3: Multi-Cluster Traffic and Disaster Recovery

Forwarding traffic of one CLB instance among multiple Kubernetes clusters is supported.

Enterprises will take multiple measures to ensure the high availability of their applications, for example, creating multiple clusters for data backup and disaster recovery. In this scenario, business traffic can be connected to multiple Kubernetes clusters through one CLB, and different weights can be set for the Kubernetes clusters, as shown in the following figure:

5

Precautions

  • VServer group multiplexing across CLB instances is not supported.
  • A VServer group can be associated with only one port.
  • Cluster Ids have been configured for the two clusters. Otherwise, services in the two clusters must be named differently.

Operating Instructions

  • Log on to the CLB console to create a CLB instance, a listener, and a VServer group. Record the CLB ID ("lb-xxxx") and the VServer group Id ("rsp-xxx") of the CLB instance.
  • Create Service-A in Cluster A with the weight set to 20%
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: service-A
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

Expected Outcomes

When the configuration is set, the nodes in Cluster A and Cluster B are available in the CLB VServer group. The weights of the nodes in the cluster are configured according to the annotations. The CLB backend VServer will update automatically on the expansion or shrinking of the applications in the cluster.

Summary

More enterprises deploy applications in a containerized manner to reduce costs and improve efficiency. During business migration, ensuring normal business traffic poses a great challenge. For e-commerce applications, the decline in business traffic often results in a decline in the transaction volume, bringing major losses. Gaming applications are also very sensitive to business traffic; the user experience will be affected significantly by any short-term traffic interruptions. The business traffic decline in traffic applications will affect traffic flow control and the efficiency of traffic failure troubleshooting. Therefore, preventing the loss of business traffic still remains the bottom line for a normal user operation.

CCM's released support for attaching internal and external ECS instances to the same CLB instance resolves the traffic interruption during migration. It also supports forwarding business traffic to nodes in multiple Kubernetes clusters to meet requirements, such as backup and disaster recovery, ensuring high availability.

0 0 0
Share on

You may also like

Comments