In cloud environments, provisioning a readily available network load balancer with Emissary-ingress is the best option for handling ingress into your Kubernetes cluster. When running Kubernetes on a bare metal setup, where network load balancers are not available by default, we need to consider different options for exposing Emissary-ingress.
The simplest way to expose an application in Kubernetes is via a
NodePort service. In this configuration, we create the Emissary-ingress service] and identify
type: NodePort instead of
LoadBalancer. Kubernetes will then create a service and assign that service a port to be exposed externally and direct traffic to Emissary-ingress via the defined
NodePort leaves Emissary-ingress isolated from the host network, allowing the Kubernetes service to handle routing to Emissary-ingress pods. You can drop-in this YAML to replace the
LoadBalancer service in the YAML installation guide and use
http://<External-Node-IP>:<NodePort>/ as the host for requests.
When running Emissary-ingress on a bare metal install of Kubernetes, you have the option to configure Emissary-ingress pods to use the network of the host they are running on. This method allows you to bind Emissary-ingress directly to port 80 or 443 so you won't need to identify the port in requests.
This can be configured by setting
hostNetwork: true in the Emissary-ingress deployment.
dnsPolicy: ClusterFirstWithHostNet will also need to set to tell Emissary-ingress to use KubeDNS when attempting to resolve mappings.
This configuration does not require a defined Emissary-ingress service, so you can remove that service if you have defined one.
Note: Before configuring Emissary-ingress with this method, consider some of the functionality that is lost by bypassing the Kubernetes service including only having one Emissary-ingress able to bind to port 8080 or 8443 per node and losing any load balancing that is typically performed by Kubernetes services.