Gateway Hosts

Gateway hosts run the HAproxy service and are part of the HPE Ezmeral Runtime Enterprise control plane. You can access the web UI of a HPE Ezmeral Runtime Enterprise deployment through any Gateway host. For high availability and load balancing, configure multiple Gateway hosts.

Gateway hosts are part of the HPE Ezmeral Runtime Enterprise control plane. Gateway hosts must conform to the applicable requirements listed in Gateway Host Requirements and Limitations and in Host Requirements.

Gateway hosts do not run pods. Instead, they enable access to user-facing services such as Notebooks, Hue console, and SSH running on pods through an instance of the High Availability Proxy service (HAproxy service). The management Web UI is accessible through any Gateway host in the HPE Ezmeral Runtime Enterprise deployment.

Gateway hosts allow for clear separation of network zones by providing the following:

  • A simple, secure, and fully-managed control path for end users and admins alike to access Kubernetes API servers (such as when handling kubectl commands) as well as the service endpoints of multiple Kubernetes clusters. HPE Ezmeral Runtime Enterprise dynamically manages endpoints, including kubeconfig contents, as clusters and services are created, deleted, or updated.
  • Automated load balancing for Kubernetes masters and services. Kube API traffic (via kubectl etc) is load-balanced to both multi-master highly-available Kubernetes clusters and multi-replica NodePort services.
  • SSL termination to container service access points.
  • Interoperability with any ingress controller and NodePort service definition for maximum flexibility.

You can configure multiple Gateway hosts one or more Gateway sets that have a common Fully Qualified Domain Name (FQDN) for round-robin load balancing and High Availability. You can also use a hardware load balancer in front of the multiple Gateway hosts, and you can also configure one or more custom port ranges between 10000 and 50000 for use as proxies.

All control traffic to the pods from end-user devices (browsers and command line), such as HTTPS, SSH, or AD/KDC, goes through the Gateway hosts, while all traffic from the pods is routed through the hosts on which those pods reside.

Support for multiple subnets increases Gateway host flexibility. For example, you can use "small" virtual machines that meet all Gateway host requirements located on different racks or in different areas of your network, instead of having to place these hosts on the same rack as Kubernetes cluster hosts. This configuration can help optimize resource usage.

Physical Architecture

This diagram displays the physical architecture of a deployment that has two Gateway hosts.


Physical architecture with two gateway hosts

Logical Architecture

You can access the web UI of a HPE Ezmeral Runtime Enterprise deployment through any Gateway host.

The following diagram displays the logical architecture of Kubernetes clusters and Gateway hosts within a deployment:


Logical architecture showing gateway connections in orange and pod connections in purple

Gateway Host Requirements and Limitations

A deployment of HPE Ezmeral Runtime Enterprise must include at least one Gateway host. For high availability and load balancing, a deployment can include multiple Gateway hosts in one or more Gateway sets.

Gateway hosts only run the HAproxy service and cannot be included in Kubernetes clusters. Gateway hosts must meet the following minimum requirements:

  • For information about the CPU, memory, and storage requirments for Gateway hosts, see the information about Gateway load balancer (Gateway LB) hosts in Host Requirements.
  • Gateway hosts need not be on the same subnet as the Controller, Shadow Controller, or other hosts.
  • Ports 10000-50000 on the Gateway hosts are used for port mapping. The sysctl utility is configured on the Gateway hosts to prevent misallocation of these port ranges. The HAproxy service binds to ports in this range.
  • The iptables service is automatically disabled on the Gateway hosts during the installation.
  • For both DataTap access and for Kerberos access from the containers, physical hosts must be on a routable network/standard corporate subnet.

Gateway Sets

A Gateway set is a set of Gateway hosts that share a common DNS server name. You create a Gateway set during Gateway host installation when you specify multiple IP addresses for the same hostname. You can create more than one Gateway set by performing multiple Gateway host installation operations, specifying a different hostname and a different list of IP addresses during each operation.

Multiple Gateway sets can be used to create a larger number of port mappings than are allowed for a single set.

Gateway sets have the following requirements and limitations:

  • All of the hosts in a Gateway set must have both an individual hostname and an externally-resolvable common hostname. The Gateway Hostname must be all lower case as per the Linux hostname naming convention. The DNS server must be configured to do this. For example, the following two Gateway hosts have the common hostname sample-lab-proxy.enterprise.com:
    • 10.32.2.94 hostname-1.enterprise.com sample-lab-proxy.enterprise.com
    • 10.32.2.96 hostname-2.enterprise.com sample-lab-proxy.enterprise.com
  • A new Gateway host can be added to an existing set at any time. The new Gateway host will automatically be configured with the port instance mappings for that set.
  • A new Gateway host can be added to start a new set at any time. However, the newly added Gateway host will be used only for future service mappings.
  • At the time of instance launch, all Gateway hosts in the set must be accessible to create mappings. If they are not available, then cluster creation will fail.
  • A Gateway host that belongs to a Gateway set can be decommissioned provided the following conditions are met:
    • No active pod port mappings are present.
    • Pod port mappings are present and there is at least one other Gateway host available in the set.

Proxy Mapping Management

Configuring one or more Gateway hosts enables users to access pods using a set of service endpoint proxy mappings, as shown in the following illustration:


Illustration showing proxy mapping to pods through a gateway set

Each Gateway set can consist of one or more Gateway hosts. When a cluster is created, information is collected about the service endpoints configured for that cluster. These service endpoints will be those defined for services being deployed within that cluster, and each service endpoint will be mapped to a specific port regardless of whether that service uses HTTP, HTTPS, or TCP.

The Controller uses a scheduling algorithm to decide which Gateway set to use for creating port mappings. This is simply based on which Gateway set has fewer port mappings and whether or not all of the hosts in the Gateway set are accessible. If the Controller cannot find an available Gateway set, then cluster launch will fail with an error message returned to the user.

Once the Controller identifies an available Gateway set, it allocates the necessary ports from the reserved range. A message is sent to the service running on each Gateway host to create the appropriate proxy mappings. Mappings will be automatically deleted when a cluster is deleted, and the ports will be freed up for use by the next cluster.

Gateway hosts within a Gateway set have failover ability. If a Gateway host is down, the other hosts provide the port mappings. However, all active hosts within a set must be available at the time of cluster creation. The user's DNS server determines which specific host will receive the traffic within a single set. Typically, a round-robin configuration on the DNS server serves this purpose.

Mappings between Gateway sets are not shared. If an entire Gateway set is disabled, those mappings will no longer function.