Using North-South MCS

Constraints

• Currently, MCS can be used only when CCE Turbo clusters 1.21 or later and other Kubernetes clusters whose network type is underlay are created.
• To ensure that the container networks of member clusters do not conflict and that the load balancer instance can connect to the pod IP address, you need to plan the network in advance. If the load balancer of MCS and the target cluster are in different VPCs, you need to enable the network between the VPCs in advance.

Preparations

• If no load balancer is available, create one first. For details, see Creating a Dedicated Load Balancer. The load balancer to be created must:
  • Be a dedicated load balancer.
  • Support TCP/UDP networking.
  • Have a private IP address associated.
  • Support cross-VPC access if the load balancer and the member cluster are not in the same VPC.
• MCS provides a unified entry and Layer-4 network access to cross-cluster backends. You need to deploy available workloads (Deployments) and Services in the federation in advance. If no workload or Service is available, create one by referring to Deployments and ClusterIP.
• Set the cluster network type to underlay. For details about the cluster types that support the underlay network, see Configuring the Cluster Network.

Creating an MCS Object of the LoadBalancer Type

1. Use kubectl to connect to the federation. For details, see Using kubectl to Connect to a Federation.
2. Create and edit the mcs.yaml file as follows. For details about the parameters in this file, see Table 1.

   In the example, the defined MCS object is associated with Service nginx. Register this Service with the listener of Huawei Cloud ELB.

   vi mcs.yaml

   apiVersion: networking.karmada.io/v1alpha1
   kind: MultiClusterService
   metadata:
     name: nginx
     namespace: default
     annotations:
       karmada.io/elb.id: 2050857a-45ff-4312-8fdb-4a4e2052e7dc
       karmada.io/elb.projectid: c6629a1623df4596a4e05bb6f0a2e166
       karmada.io/elb.port: "802"
       karmada.io/elb.health-check-flag: "on"
   spec:
     ports:
       - port: 80
     types:
       - LoadBalancer

   Table 1 Key parameters

   Parameter	Mandatory	Type	Description
   metadata.name	Yes	String	Name of the MCS object, which must be the same as that of the associated Service.
   etadata.namespace	No	String	Name of the namespace where the MCS object is located, which must be the same as that of the namespace where the associated Service is located. If this parameter is left blank, default is used.
   spec.types	Yes	String	Traffic direction. To enable service discovery between clusters, set this parameter to LoadBalancer.
   spec.ports.port	No	Integer	Service port that needs to be registered with the ELB listener.
   spec.consumerClusters.name	No	String	Name of the cluster that accesses the Service. Set this parameter to the name of the cluster that is expected to access the Service across clusters through MCS. If this parameter is left blank, all clusters in the federation can access the Service by default.
   karmada.io/elb.id	Yes	String	ID of the load balancer associated with MCS. This parameter cannot be left blank. The value ranges from 1 to 32.
   karmada.io/elb.projectid	Yes	String	ID of the project of the load balancer associated with MCS. For details about how to obtain the project ID, see Obtaining a Project ID. The value ranges from 1 to 32.
   karmada.io/elb.port	No	String	Port number of the load balancer associated with MCS. If this parameter is not specified, 80 is used by default. The value ranges from 1 to 65535.
   karmada.io/elb.health-check-flag	No	String	Whether to enable health check. The options are as follows: on: Enable off: Disable If this parameter is not specified, off is used by default.
   karmada.io/elb.health-check-option	No	HealthCheck Object	Health check parameters. For details, see HealthCheck parameters. Replace {service name} with the name of the federated Service. NOTE: The following is an example of health check parameter settings: karmada.io/elb.health-check-option: '{"protocol":"TCP","delay":"5","connect_port":"80","timeout":"1","max_retries":"1","path":"/wd"}' If health check is enabled for annotations, the Service name can contain a maximum of 39 characters.
   karmada.io/elb.lb-algorithm	No	String	Forwarding algorithms. The options are as follows: ROUND_ROBIN: weighted round robin LEAST_CONNECTIONS: weighted least connections SOURCE_IP: source IP hash The default value is ROUND_ROBIN. {service name}: name of the federated Service.

   Table 2 HealthCheck parameters

   Parameter	Mandatory	Type	Description
   protocol	No	String	Protocol used for health checks. The value can be TCP or HTTP.
   connect_port	No	Integer	Port used for health checks. The value ranges from 1 to 65535.
   elay	No	Integer	The interval between the time when the application is delivered and the time when a health check is started, in seconds. The value ranges from 1 to 50.
   timeout	No	Integer	Health check timeout duration, in seconds. The value ranges from 1 to 50.
   path	No	String	Health check request URL. This parameter is valid only when type is set to HTTP or HTTPS. The value must start with a slash (/), and the default value is /. Only letters, digits, hyphens (-), slashes (/), periods (.), percent signs (%), question marks (?), number signs (#), ampersands (&), and extended character sets are allowed. The value contains 1 to 80 characters.
   max_retries	No	Integer	Maximum number of retries. The value ranges from 1 to 10.

3. Create an MCS object.

   kubectl apply -f mcs.yaml

4. Run the following commands to operate the MCS object (named nginx):
   • kubectl get mcs nginx: obtains the MCS object.
   • kubectl edit mcs nginx: updates the MCS object.
   • kubectl delete mcs nginx: deletes the MCS object.

Accessing Services Through MCS

After the MCS object is created, the listener and health check policy are automatically created by the ELB side. You can access the backend workload at http://{IP:port}. {IP:port} indicates the IP address and port number of the load balancer associated with the MCS object.

If the access is abnormal, run the kubectl describe mcs nginx command to query events and check whether MCS runs normally.