Load Balancer with Hostname

Exposing non-HTTP based services to the Internet

Release will automatically handle services that are HTTP based and generate hostnames for the backend services. But not all services are HTTP: there are many services that listen for other types of traffic, like TCP or even UDP traffic.

In order to expose a non-HTTP service to the Internet you will need to define a node_port. A node_port requires both a target_port and port number.

  • target_port: This is the port on the pod that the request gets sent to internally. Your application needs to be listening for network requests on this port for the service to work.

  • port: Expose the service externally on the specified port within the cluster. That is, the service becomes visible on this port, and other pods and services will send requests to this port to reach the service.

  • Release doesn't define a fixed nodeport in Kubernetes which allows Kubernetes to allocate a random port from the host node. However, for external communications the fixed port is applied to the load balancer. This allows services that run "on the same port number" to coexist with other applications on the same physical nodes without conflict.

Once you have defined a node_port for your service you can now define a hostname for this service. Release uses variable interpolation for env_id and domain just like the HTTP based hostnames for your services.

services:
- name: minecraft
image: dustyspace/docker-minecraft-server/minecraft
has_repo: true
ports:
- type: node_port
target_port: '25565'
port: '25565'
loadbalancer: true
hostname: minecraft-${env_id}-${domain}

Here is an example of exposing a Minecraft service to the internet. The Minecraft service listens on port 25565, creates a load balancer and generates a hostname.

services:
- name: db
image: postgres:9.4
ports:
- type: node_port
target_port: '5432'
port: '5432'
loadbalancer: true
hostname: postgres-db-${env_id}-${domain}

Here is an example of exposing a postgres database service to the internet