Component Access via IP
This article applies to application developers and operation and maintenance personnel
How to access the external service components deployed to Kato is the focus of this article. For example, the deployed database is accessed by the external network, and the deployed IoT service is accessed by the external network. These components will use the access policy mode based on IP address and port.
- Deploy a Mysql component based on the application market Refer to Create Component Document
- Prepare a Mysql client locally to test the connection to the Mysql service
Confirm that the prerequisites are ready, a Mysql component already exists in the test application
Configure gateway strategy, enter the gateway strategy management page, switch to TCP/UDP strategy mode, and click Add strategy. Similar to configuring HTTP policies, TCP policies still include routing rules and access targets. The access target part is consistent with the HTTP policy. There is only one configuration item in the routing rules part that is the combination of IP and port. IP is an optional list, which includes all the IP addresses of the node where the Kato gateway service is located (excluding the docker0 network card and the container network network card). If the IP address you need to access is not in the options (for example, the EIP of Alibaba Cloud will not be mounted to Virtual machine, so it will not be displayed in the list) Please select 0.0.0.0 as the wildcard IP address. We will automatically recommend the port based on the used port data, of course you can change it to any available port number. Save after selection.
Note that if the prompt The component port is not open, whether to open automatically when saving. Selecting Yes, automatically opens the component’s port external service properties to complete the service registration.
- Test whether the strategy is effective, the strategy will take effect automatically after configuration. Click the newly added policy in the access policy list, and obtain the connection address and connection variable information (including Mysql account information) in the pop-up window. Use the local Mysql client to test the connection.
Understanding the Principle
The TCP/UDP protocol is a transport layer protocol, so supporting the TCP/UDP protocol means that almost all application layer communication protocols are currently supported. By listening on the node where the Kato gateway service is located, using the IP and port configured by the policy, the component container network at the back end of the request proxy is placed on the network. Using TCP/UDP means that the gateway will not parse the request packet and has better performance. At the same time, it means that you cannot do as many routing strategies as the HTTP protocol through the gateway.
The selected IP address is very particular. The Kato gateway service will automatically obtain the IP addresses bound to all network cards of the running node, and exclude docker0 and the IP addresses of the network cards related to the container network by default. This means that the IP address options include LAN IP and public IP. When the policy selects a clear IP address, the current policy will only take effect on the node where the IP is located, and only listen to the port corresponding to the IP. If the selected IP address is a virtual IP, it may drift when the node is abnormal. The Kato gateway can perceive the drift of the IP address in real time to achieve the drift of the gateway strategy. If the selected IP address is the wildcard address 0.0.0.0, it means that the policy will take effect on all Kato gateway service deployment nodes and directly occupy the configured port.
Through the above mechanism, Kato gateways can be deployed at the edge of the local area network and act as a bridge between multiple local area networks.
How to ensure that the ports do not conflict
Kato tries its best to ensure that the listening ports do not conflict between all strategies, but unfortunately the host port may be occupied by other software and cause conflicts. Therefore, it is recommended that users ensure the independence of Kato gateway nodes as much as possible.
Can the external IP be used without binding to the cluster?
It is recommended to use the wildcard 0.0.0.0 as the IP address, and then directly access the external network IP address + port. But the premise is that the traffic of the external network IP has been mapped to a certain Kato gateway node.
How does the gateway isolate the internal and external networks
The deployment mode of the gateway is flexible. When a gateway node only has an intranet IP, the strategy configured with this IP can only be accessed through the intranet. Deploy the Kato gateway to different subnets (provided that it can communicate with the subnet where the cluster is located), so that different subnets can access the applications in the cluster.
Can TCP policies access HTTP applications?
Of course you can, and in some special cases you must also use the TCP strategy. For example, the application itself has a server certificate configured to establish TLS monitoring, or the application hopes to have higher performance.