Re-specify the Gateway Node

rbd-gateway is a high-performance distributed cluster gateway developed by Gridworkz Technology. Service components deployed on the Kato platform can expose domain names or service addresses in the form of IP:Port through the gateway, and support Http protocol and Tcp protocol. When the Kato cluster is first installed and deployed, it will be required to specify the gateway node (rbd-gateway deployment node) to be deployed to some nodes in the cluster. So after the cluster is built, how to re-designate the gateway node and what should be done after switching the gateway?

Scene Description

The rbd-gateway gateway service is deployed in the Kato cluster as a daemon process through the Kubernetes DaemonSet controller. It has a distributed nature and can be deployed on any one or a batch of nodes in the cluster. The nodes deployed with the rbd-gateway gateway service are called gateway nodes.

At the beginning of Kato cluster deployment, certain nodes in the cluster will be required to be designated as gateway nodes. After the cluster is built, if you need to re-plan, you want to re-designate the gateway node.

Re-specify the Gateway Node

  • First of all, you need to ensure that the new gateway node does not listen to ports 80, 443, 6060, 7070, 8443, 10254, 18080, 18081 to avoid port conflicts.
  • Second, make sure that kato-operator uses the latest mirror:
kubectl edit statefulsets.apps kato-operator -n rbd-system

Make sure that the kato-operator in the spec.template.spec.containers.image field uses the v1.1.1 version (current latest version) image, if it is lower than this version, then modify it.

image: registry.gitlab.com/gridworkz/kato-operator:v1.1.1

Finally, modify the rbd-gateway in the Kato custom resource rbdcomponents.kato.io:

kubectl edit rbdcomponents.kato.io -n rbd-system rbd-gateway

Modify the description of the scheduling affinity paragraph:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        -matchExpressions:
          -key: kubernetes.io/hostname
            operator: In
            values:
            -172.24.206.41 # This list declares which nodes rbd-gateway will schedule to
            -172.24.206.40 

In the above description of scheduling affinity, values specifies the name of the node, which is obtained through the kubectl get node command

[root@iZhp38me3xgju205i5udfnZ ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
172.24.206.41 Ready master 38d v1.16.2

Modify the Address of the Traffic Entry

The previous section gave out how to specify the scheduling gateway service (rbd-gateway), so after the rbd-gateway service is migrated to the specified new node, what else needs to be done? According to different scenarios, what to do is different.

The first scenario: There is no load balancing at the outer layer of the gateway.

In this scenario, the server where the rbd-gateway service is located is the access portal of the running application on the platform. External access traffic flows in through the IP of this server. Then, you need to modify:

  1. Apply the resolved address of the bound domain name. Change the resolution address of the domain name from the domain name resolution service provider.
  2. After the application opens the external TCP protocol and exposes :, this IP should also be changed.

The operation method is to log in to the database used by Kato. The default is the rbd-db component. Update the contents of the console.region_info table:

update console.region_info set wsurl='ws://<new gateway IP>:6060',tcpdomain='<new gateway IP>';

The second scenario: the outer layer of the gateway has load balancing. For example, in the ACK Aliyun environment, if multiple gateway nodes are deployed, Ali’s SLB service is externally used for unified load balancing. Then after the rbd-gateway service is migrated to the specified new node, you only need to modify the back-end instance in the SLB load balancing, remove the old gateway IP, and add the new gateway IP.

For Other Components

All components of Kato are maintained and configured through the custom resource type of rbdcomponents.kato.io, that is to say, you can assign any Kato component to be scheduled to a certain or a certain type of node in this way.

For example, at the beginning of the installation of the Kato cluster, it will also be required to specify the node that the build service runs on, which is the node where the rbd-chaos service is deployed. It can also be reassigned by the method in this article.