Planning Container Tunnel Deployments
Summary
Tunnel origins must have their ports exposed through a load balancer, node port, host port mapping, or some other configuration for external accessibility.
Information
All tunnels must have an origin (the point where traffic enters the tunnel) and a destination (the IP/hostname and port where traffic is routed to). Using tunnels in a container environment requires some prior planning to ensure the origins function when the container is launched.
If the tunnel origin uses loopback (127.0.0.1), no port mappings or additional configuration is necessary for the tunnel to work in a Kubernetes or Docker container. If the tunnel origin needs to be accessible from outside the container or pod, there is some additional configuration required for Kubernetes and Docker.
Docker
Docker requires that all necessary ports are mapped to the host at runtime. This means that you need to know which ports you want to use for the tunnel origin(s) before you launch the container.
See the Creating a Container with Tunnel Origins or Updating Port Mappings for Containers KB articles for instructions on mapping ports for new or existing containers, respectively.
Kubernetes
Kubernetes allows you to add, modify, and delete services after a container is launched. This frees you to add and remove tunnel origins as needed: you only need to add or update your service definitions to allow traffic to the origin port. For more information about Kubernetes services, see Kubernetes documentation. An example load balancer configuration for a tunnel origin is provided below.
#Example load balancer service
apiVersion: v1
kind: Service
metadata:
name: tunnel-app-origin
spec:
type: LoadBalancer
selector:
app: tunnel-app
ports:
- name: example-origin
protocol: TCP
port: 32456
targetPort: 32456
#Remote management port for DxEnterprise and DxOdyssey
- name: management
protocol: TCP
port: 7979
targetPort: 7979