Overview

One approach to getting external traffic into the cluster is by using ExternalIP or IngressIP addresses.

This feature is only supported in non-cloud deployments. For cloud (GCE, AWS, and OpenStack) deployments, load Balancer services can be used to automatically deploy a cloud load balancer to target the service’s endpoints.

Cluster administrators can assign a unique external IP address to a service. If routed correctly, external traffic can reach that service’s endpoints via any TCP/UDP port the service exposes. This can be simpler than having to manage the port space of a limited number of shared IP addresses when manually assigning external IPs to services.

There is support for both automatic and manual assignment of IP addresses, and each address is guaranteed to be assigned to a maximum of one service. This ensures that each service can simply expose its chosen ports regardless of the ports exposed by other services.

Restrictions

To use an ExternalIP, you can:

  • Select an IP address from the ExternalIPNetworkCIDRs range.

  • Have an IP address assigned from a pool. In this case, OpenShift Container Platform implements a non-cloud version of the LoadBalancer service type and assigns IP addresses to the services.

    You must ensure that the IP address pool you assign terminates at one or more nodes in your cluster. You can use the existing oadm ipfailover to ensure that the external IPs are highly available.

For manually-configured external IPs, potential port clashes are handled on a first-come, first-served basis. If you request a port, it is only available if it has not yet been assigned for that IP address. For example:

Example 1. Port clash example for manually-configured external IPs

Two services have been manually configured with the same external IP address of 172.7.7.7.

MongoDB service A requests port 27017, and then MongoDB service B requests the same port; the first request gets the port.

However, port clashes are not an issue for external IPs assigned by the ingress controller, because the controller assigns each service a unique address.

Ingress IPs can only be assigned if the cluster is not running in the cloud. In cloud environments, LoadBalancer-type services configure cloud-specific load balancers.

Configuring the Cluster to Use Unique External IPs

In non-cloud clusters, ingressIPNetworkCIDR is set by default to 172.29.0.0/16. If your cluster environment is not already using this private range, you can use the default. However, if you want to use a different range, then you must set ingressIPNetworkCIDR in the /etc/origin/master/master-config.yaml file before you assign an ingress IP. Then, restart the master service.

External IPs assigned to services of type LoadBalancer will always be in the range of ingressIPNetworkCIDR. If ingressIPNetworkCIDR is changed such that the assigned external IPs are no longer in range, the affected services will be assigned new external IPs compatible with the new range.

Example 2. Sample /etc/origin/master/master-config.yaml
networkConfig:
  ingressIPNetworkCIDR: 172.29.0.0/16

Configuring an Ingress IP for a Service

To assign an ingress IP:

  1. Create a YAML file for a LoadBalancer service that requests a specific IP via the loadBalancerIP setting:

    Example 3. Sample LoadBalancer Configuration
    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: db
        port: 3306
      loadBalancerIP: 172.29.0.1
      type: LoadBalancer
      selector:
        name: my-db-selector
  2. Create a LoadBalancer service on your pod:

    $ oc create -f loadbalancer.yaml
  3. Check the service for an external IP. For example, for a service named myservice:

    $ oc get svc myservice

    When your LoadBalancer-type service has an external IP assigned, the output displays the IP:

    NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    myservice    172.30.74.106   172.29.0.1    3306/TCP    30s

Routing the Ingress CIDR for Development or Testing

Add a static route directing traffic for the ingress CIDR to a node in the cluster. For example:

# route add -net 172.29.0.0/16 gw 10.66.140.17 eth0

In the example above, 172.29.0.0/16 is the ingressIPNetworkCIDR, and 10.66.140.17 is the node IP.