By setting an external IP on the service, OpenShift Container Platform sets up IP table rules to allow traffic arriving at any cluster node that is targeting that IP address to be sent to one of the internal pods. This is similar to the internal service IP addresses, but the external IP tells OpenShift Container Platform that this service
should also be exposed externally at the given IP. The administrator must assign the IP address to a host (node) interface on one of the nodes in the cluster.
Alternatively, the address can be used as a virtual IP (VIP).

These IPs are not managed by OpenShift Container Platform and administrators are responsible for ensuring that traffic arrives at a node with this IP.

The following is a non-HA solution and does not configure IP failover. IP failover is required to make the service highly-available.

Administrator Prerequisites

Before starting this procedure, the administrator must:

Set up the external port to the cluster networking
environment so that requests can reach the cluster. For example, names can be
configured into DNS to point to
specific nodes or other IP addresses in the cluster. The DNS wildcard feature
can be used to configure a subset of names to an IP address in the cluster. This allows the users to set up routes
within the cluster without further administrator attention.

Make sure that the local firewall on each node permits the
request to reach the IP address.

Make sure there is at least one user with cluster admin role. To add this role to a user, run the following command:

oc adm policy add-cluster-role-to-user cluster-admin username

Have an OpenShift Container Platform cluster with at least one master and at least one node and a system outside the cluster that has network access to the cluster. This procedure assumes that the external system is on the same subnet as the cluster. The additional networking required for external systems on a different subnet is out-of-scope for this topic.

Defining the Public IP Range

The first step in allowing access to a service is to define an external IP address range in the master configuration file:

Log into OpenShift Container Platform as a user with the cluster admin role.

$ oc login
Authentication required (openshift)
Username: admin
Password:
Login successful.
You have access to the following projects and can switch between them with 'oc project <projectname>':
* default
Using project "default".

Configure the externalIPNetworkCIDRs parameter in the /etc/origin/master/master-config.yaml file as shown:

networkConfig:
externalIPNetworkCIDRs:
- <ip_address>/<cidr>

For example:

networkConfig:
externalIPNetworkCIDRs:
- 192.168.120.0/24

Restart the OpenShift Container Platform master service to apply the changes.

Configuring Networking

After the external IP address is assigned, you need to create routes to that IP.

The following steps are general guidelines for configuring the networking required to access the exposed service from other nodes. As network environments vary, consult your network administrator for specific configurations
that need to be made within your environment.

These steps assume that all of the systems are on the same subnet.

On the master:

Restart the network to make sure the network is up.

$ service network restart
Restarting network (via systemctl): [ OK ]

If the network is not up, you will receive error messages such as Network is unreachable when running the following commands.

Run the following command with the external IP address of the service you want to expose and device name associated with the host IP from the ifconfig command output:

$ ip address add <external-ip> dev <device>

For example:

$ ip address add 192.168.120.10 dev eth0

If you need to, run the following command to obtain the IP address of the host server where the master resides:

$ ifconfig

Look for the device that is listed similar to: UP,BROADCAST,RUNNING,MULTICAST.

Add a route between the IP address of the host where the master resides and the gateway IP address of the master host. If using a netmask for a networking route, use the netmask option, as well as the netmask to use:

Add a route between the IP address of the exposed service and the IP address of the master host:

$ route add -net 192.174.120.0/24 gw 10.16.41.22 eth0

On the Node:

Restart the network to make sure the network is up.

$ service network restart
Restarting network (via systemctl): [ OK ]

If the network is not up, you will receive error messages such as Network is unreachable when executing the following commands.

Add a route between IP address of the host where the node is located and the gateway IP of the node host. If using a netmask for a networking route, use the netmask option, as well as the netmask to use:

Add a route between the IP address of the exposed service on master and the IP address of the master host:

$ route add -net 192.174.120.0 netmask 255.255.248.0 gw 10.16.41.22

Use a tool, such as cURL, to make sure you can reach the service using the public IP address:

$ curl <public-ip>:<port>

For example:

curl 192.168.120.10:3306

If you get a string of characters with the Got packets out of order message,
your service is accessible outside the cluster.

Configure IP Failover using VIPs

Optionally, an administrator can configure IP failover.

IP failover manages a pool of Virtual IP (VIP) addresses on a set of nodes. Every VIP in the set is serviced by a node selected from the set. As long as a single node is available, the VIPs will be served. There is no way to explicitly distribute the VIPs over the nodes. As such, there may be nodes with no VIPs and other nodes with multiple VIPs. If there is only one node, all VIPs will be on it.

The VIPs must be routable from outside the cluster.

To configure IP failover:

On the master, make sure the ipfailover service account has sufficient security privileges: