Component Dependent Port Conflict Handling

When we deploy a distributed business with multiple services, one thing that must be considered is how to deal with the communication between services. Then when we deploy the business to Kato, how do we deal with it?

Kato’s out-of-the-box ServiceMesh architecture transparently solves the communication problem between components in distributed scenarios through the sidecar proxy by default.

For example, component A needs to access component B, and component A can be dependent on component B, so that when component A starts, an envoy service will be started as a plug-in, and the envoy service will map the internal port of component B to the Pod network space of component A The same port of the local loopback address 127.0.0.1, which means that component B has opened the internal port 8080, then after the dependency relationship between A to B is established, accessing 127.0.0.1:8080 in component A will Envoy forwards related requests to port 8080 of component B.

However, there is often a situation in our actual business, that is, a component needs to communicate with multiple other components, and the service ports used by these components may be the same, which will lead to envoy at the local loopback address 127.0.0.1 A port conflict occurred while listening.

We can solve this problem in two ways:

Method 1: Port reuse through HTTP 7-layer network management

This type of component, through [Kato network management plug-in] (/docs/user-manual/plugin-manage/mesh-plugin/) set the domain name (Domain) and request path of downstream components , Request first and other routing conditions, envoy forwards the request for accessing the corresponding domain name to the corresponding back-end component port through port 80, and no longer monitors the corresponding port of the component network space that opens the plug-in. The specific configuration process is as follows:

Establish dependencies
Open the A component network management plug-in
Configure downstream service access domain name
Update components and test domain name access effects

Precautions

The network management plug-in will listen to the 127.0.0.1:80 of the service network, so if the A component itself listens to port 80, there will be an abnormal operation of the component state due to the fact that port 80 is occupied and the service cannot be started.

Method 2: Dynamically change the listening port of the component

The component running on Kato will automatically inject an environment variable PORT when it starts, which is the first port set by the component. You can set the listening port of the service by referring to the PORT variable when the component starts. Platform control, you can implement monitoring port changes without modifying the code. In this way, different services that depend on setting different ports can avoid conflicts. Taking the source code construction of the Java project as an example, the specific configuration process is as follows:

Set the start command of the build source to web: java -Dserver.port=$PORT $JAVA_OPTS -jar target/*.jar
Add component ports and build components.
Authentication service listening port

Different development languages ​​and middleware have different ways of setting the listening port, and developers need to develop and configure according to the actual setting method.

Method 3: Use Kubernetes native Service governance model

In Kato’s version 5.3, we support the direct use of the Kubernetes native Service mode and provide a friendly configuration method. In this network management mode, each internal port can be set with a custom access domain name, which will be generated after setting Corresponding Service resources, so that the components can be accessed directly through the internal domain name + port, and the port proxy is no longer performed by envoy, which fundamentally avoids the problem of port conflicts.

Method 4: Use Istio Network Management Mode

Istio Network Management Mode will also be supported in subsequent versions of Kato. In this network management mode, only monitoring The fixed Pod port configured by Istio, instead of listening to the component ports that need to be accessed, other components that need to be accessed will be set by Pilot to set traffic rules and configurations, and then handed over to Envoy for forwarding through 15001/15006.