Using NAT with Static IP Addresses for Outbound Connections for Kubernetes-Based Deployments
Outbound connections are required when event broker services initiate the connections for the following scenarios:
- using REST destination points (RDPs) to deliver REST requests to a remote server, for example, for outbound RDPs by subscribing applications (consumers)
- linking to a replication mate (for disaster recovery)
- creating Dynamic Message Routing (DMR) links to another node
- creating VPN bridges made to other brokers
- spawning new connections to an LDAP database
For Dedicated Region and Public Region deployments, the availability of static IPs depends on the deployment type and cloud provider you choose. For more information, see Static IP Availability for Messaging Connectivity in Public Regions and Dedicated Regions. If static IPs are available, you can contact Solace to request the static IP address of the network address translation (NAT).
For Customer-Controlled Regions, Solace recommends that customers create a Network Address Translation (NAT) in each Kubernetes cluster where the event broker services are deployed to handle outbound connections. Each NAT can be configured to have its own public static IP address. When a event broker service connects to an external host, the source IP address of the connections is the NAT's public static IP address. Because external hosts must know the IP addresses to allow for their firewalls to permit secure connections, it is useful to use a static IP address.
Solace also recommends that the customer deploys at least two NATs for better resilience and redundancy. Access for the inbound connections for external clients continues through a public load balancer.
Using public static IP addresses via NAT for outbound connections has these advantages:
- external hosts can modify their allow lists to use static IP address through their firewalls; the same IP address is used when multiple event broker service come from the same datacenter
- improved security because the worker nodes are no longer exposed to public IP addresses
- improved reliability and resilience because when an event broker service is upgraded or restarted, its IP address may change and the renewed, private IP addresses can be quickly remapped to the static IP address of the NAT