App Governance Mode Switch
Governance Mode Switch
Kato has added the application management mode switching function since V5.3 version. The application governance mode mainly refers to the governance of the communication mode between components, and currently supports the built-in ServiceMesh mode and the Kubernetes native Service mode.
Built-in ServiceMesh Mode (default)
The built-in ServiceMesh mode requires the dependencies between the configuration components displayed by the user. The platform will automatically inject sidecar containers into the downstream components to form the ServiceMesh microservice architecture, and the communication addresses between businesses are unified to the localhost (127.0.0.1) mode. As the default application management mode in Kato, the management functions such as A/B testing, intelligent routing, current limiting, and fusing between service components are realized through sidecar. For more information, please refer to Service Communication, A/B test based on Kato
Kubernetes Native Service Mode
Kubernetes service name domain names are used for communication between components in this mode. Users need to configure the service name registered on each component port, which has limited governance capabilities.
Impact of Switching
For users, switching to a different application management model, the most important thing to pay attention to is the change in the way of accessing each other between components. The new Kubernetes native Service mode means that users can access the corresponding service components using the Service name in native Kubernetes.
How to Switch
The entrance to application management mode switching is located in the application topology view. In Governance Mode, you can switch between the two application governance modes.
If you switch from the built-in ServiceMesh mode to the Kubernetes native Service mode, you need to define the internal domain name of all ports that open internal services under the current application.
Internal domain name is the address that can be accessed globally for the port.
To put it simply, the domain name defined here will be resolved to the CLUSTER-IP address of the Service in the entire cluster.
$ kubectl get service -A NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) 9dcf3ab241c445afad7a9a90b1b7c9a7 gr12238e-80-dbeb ClusterIP 10.43.234.35 <none> 80/TCP
Changes to Communication Variables
If you don’t understand what communication variables are, please read Communication Variable Injection first.
Compared with the default built-in ServiceMesh mode, communication variables still exist in the native Service mode of Kubernetes. The difference is that the value of the communication variable is no longer fixed to the local loopback address of 127.0.0.1, but has become the internal domain name mentioned above. This change is to facilitate users who use communication variables to determine dependencies. Without changing the configuration, communication variables can still be used to complete calls between components.
# The 80 port of APP2 component in the example, its communication variable becomes the following form NGINX_HOST=gr12238e-80-dbeb NGINX_PORT=80
Even though the Kubernetes native Service mode no longer needs dependencies to provide sidecar plug-ins to achieve communication between components, dependencies still have their own value.
The application topology diagram presented by the dependency relationship is very intuitive and beautiful.
Dependency can be used to transfer communication variables, so that users can use communication variables to complete calls between components without changing the configuration.