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:
Open the A component network management plug-in
Configure downstream service access domain name
Update components and test domain name access effects
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.