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?
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, 18081to avoid port conflicts.
- Second, make sure that
kato-operatoruses 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.
Finally, modify the
rbd-gateway in the Kato custom resource
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:
- Apply the resolved address of the bound domain name. Change the resolution address of the domain name from the domain name resolution service provider.
- 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
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.