Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 15. Configuring ingress cluster traffic

15.1. Configuring ingress cluster traffic overview
Copy link

OpenShift Container Platform provides the following methods for communicating from outside the cluster with services running in the cluster.

The methods are recommended, in order or preference:

  • If you have HTTP/HTTPS, use an Ingress Controller.
  • If you have a TLS-encrypted protocol other than HTTPS. For example, for TLS with the SNI header, use an Ingress Controller.
  • Otherwise, use a Load Balancer, an External IP, or a NodePort.
Expand
MethodPurpose

Use an Ingress Controller

Allows access to HTTP/HTTPS traffic and TLS-encrypted protocols other than HTTPS (for example, TLS with the SNI header).

Automatically assign an external IP using a load balancer service

Allows traffic to non-standard ports through an IP address assigned from a pool.

Manually assign an external IP to a service

Allows traffic to non-standard ports through a specific IP address.

Configure a NodePort

Expose a service on all nodes in the cluster.

15.2. Configuring ExternalIPs for services
Copy link

As a cluster administrator, you can designate an IP address block that is external to the cluster that can send traffic to services in the cluster.

This functionality is generally most useful for clusters installed on bare-metal hardware.

15.2.1. Prerequisites
Copy link

  • Your network infrastructure must route traffic for the external IP addresses to your cluster.

15.2.2. About ExternalIP
Copy link

For non-cloud environments, OpenShift Container Platform supports the assignment of external IP addresses to a Service object spec.externalIPs[] field through the ExternalIP facility. By setting this field, OpenShift Container Platform assigns an additional virtual IP address to the service. The IP address can be outside the service network defined for the cluster. A service configured with an ExternalIP functions similarly to a service with type=NodePort, allowing you to direct traffic to a local node for load balancing.

You must configure your networking infrastructure to ensure that the external IP address blocks that you define are routed to the cluster.

OpenShift Container Platform extends the ExternalIP functionality in Kubernetes by adding the following capabilities:

  • Restrictions on the use of external IP addresses by users through a configurable policy
  • Allocation of an external IP address automatically to a service upon request
Warning

Disabled by default, use of ExternalIP functionality can be a security risk, because in-cluster traffic to an external IP address is directed to that service. This could allow cluster users to intercept sensitive traffic destined for external resources.

Important

This feature is supported only in non-cloud deployments. For cloud deployments, use the load balancer services for automatic deployment of a cloud load balancer to target the endpoints of a service.

You can assign an external IP address in the following ways:

Automatic assignment of an external IP
OpenShift Container Platform automatically assigns an IP address from the autoAssignCIDRs CIDR block to the spec.externalIPs[] array when you create a Service object with spec.type=LoadBalancer set. In this case, OpenShift Container Platform implements a non-cloud version of the load balancer service type and assigns IP addresses to the services. Automatic assignment is disabled by default and must be configured by a cluster administrator as described in the following section.
Manual assignment of an external IP
OpenShift Container Platform uses the IP addresses assigned to the spec.externalIPs[] array when you create a Service object. You cannot specify an IP address that is already in use by another service.

15.2.2.1. Configuration for ExternalIP
Copy link

Use of an external IP address in OpenShift Container Platform is governed by the following fields in the Network.config.openshift.io CR named cluster:

  • spec.externalIP.autoAssignCIDRs defines an IP address block used by the load balancer when choosing an external IP address for the service. OpenShift Container Platform supports only a single IP address block for automatic assignment. This can be simpler than having to manage the port space of a limited number of shared IP addresses when manually assigning ExternalIPs to services. If automatic assignment is enabled, a Service object with spec.type=LoadBalancer is allocated an external IP address.
  • spec.externalIP.policy defines the permissible IP address blocks when manually specifying an IP address. OpenShift Container Platform does not apply policy rules to IP address blocks defined by spec.externalIP.autoAssignCIDRs.

If routed correctly, external traffic from the configured external IP address block can reach service endpoints through any TCP or UDP port that the service exposes.

Important

You must ensure that the IP address block you assign terminates at one or more nodes in your cluster.

OpenShift Container Platform supports both the 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 expose its chosen ports regardless of the ports exposed by other services.

Note

To use IP address blocks defined by autoAssignCIDRs in OpenShift Container Platform, you must configure the necessary IP address assignment and routing for your host network.

The following YAML describes a service with an external IP address configured:

Example Service object with spec.externalIPs[] set

apiVersion: v1
kind: Service
metadata:
  name: http-service
spec:
  clusterIP: 172.30.163.110
  externalIPs:
  - 192.168.132.253
  externalTrafficPolicy: Cluster
  ports:
  - name: highport
    nodePort: 31903
    port: 30102
    protocol: TCP
    targetPort: 30102
  selector:
    app: web
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.168.132.253
Copy to Clipboard Toggle word wrap

As a cluster administrator, you can specify IP address blocks to allow and to reject.

Restrictions apply only to users without cluster-admin privileges. A cluster administrator can always set the service spec.externalIPs[] field to any IP address.

You configure IP address policy with a policy object defined by specifying the spec.ExternalIP.policy field. The policy object has the following shape: 

{
  "policy": {
    "allowedCIDRs": [],
    "rejectedCIDRs": []
  }
}
Copy to Clipboard Toggle word wrap

When configuring policy restrictions, the following rules apply:

  • If policy={} is set, then creating a Service object with spec.ExternalIPs[] set will fail. This is the default for OpenShift Container Platform.
  • If policy=null is set, then creating a Service object with spec.ExternalIPs[] set to any IP address is allowed.

  • If policy is set and either policy.allowedCIDRs[] or policy.rejectedCIDRs[] is set, the following rules apply:

    • If allowedCIDRs[] and rejectedCIDRs[] are both set, then rejectedCIDRs[] has precedence over allowedCIDRs[].
    • If allowedCIDRs[] is set, creating a Service object with spec.ExternalIPs[] will succeed only if the specified IP addresses are allowed.
    • If rejectedCIDRs[] is set, creating a Service object with spec.ExternalIPs[] will succeed only if the specified IP addresses are not rejected.

15.2.2.3. Example policy objects
Copy link

The examples that follow demonstrate several different policy configurations.

  • In the following example, the policy prevents OpenShift Container Platform from creating any service with an external IP address specified:

    Example policy to reject any value specified for Service object spec.externalIPs[]

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy: {}
  ...
    Copy to Clipboard Toggle word wrap

  • In the following example, both the allowedCIDRs and rejectedCIDRs fields are set.

    Example policy that includes both allowed and rejected CIDR blocks

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy:
      allowedCIDRs:
      - 172.16.66.10/23
      rejectedCIDRs:
      - 172.16.66.10/24
  ...
    Copy to Clipboard Toggle word wrap

  • In the following example, policy is set to null. If set to null, when inspecting the configuration object by entering oc get networks.config.openshift.io -o yaml, the policy field will not appear in the output.

    Example policy to allow any value specified for Service object spec.externalIPs[]

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    policy: null
  ...
    Copy to Clipboard Toggle word wrap

15.2.3. ExternalIP address block configuration
Copy link

The configuration for ExternalIP address blocks is defined by a Network custom resource (CR) named cluster. The Network CR is part of the config.openshift.io API group.

Important

During cluster installation, the Cluster Version Operator (CVO) automatically creates a Network CR named cluster. Creating any other CR objects of this type is not supported.

The following YAML describes the ExternalIP configuration:

Network.config.openshift.io CR named cluster

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    autoAssignCIDRs: []
1 

    policy:
2 

      ...
Copy to Clipboard Toggle word wrap

1
Defines the IP address block in CIDR format that is available for automatic assignment of external IP addresses to a service. Only a single IP address range is allowed.
2
Defines restrictions on manual assignment of an IP address to a service. If no restrictions are defined, specifying the spec.externalIP field in a Service object is not allowed. By default, no restrictions are defined.

The following YAML describes the fields for the policy stanza:

Network.config.openshift.io policy stanza

policy:
  allowedCIDRs: []
1 

  rejectedCIDRs: []
2
Copy to Clipboard Toggle word wrap

1
A list of allowed IP address ranges in CIDR format.
2
A list of rejected IP address ranges in CIDR format.
Example external IP configurations

Several possible configurations for external IP address pools are displayed in the following examples:

  • The following YAML describes a configuration that enables automatically assigned external IP addresses:

    Example configuration with spec.externalIP.autoAssignCIDRs set

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    autoAssignCIDRs:
    - 192.168.132.254/29
    Copy to Clipboard Toggle word wrap

  • The following YAML configures policy rules for the allowed and rejected CIDR ranges:

    Example configuration with spec.externalIP.policy set

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    policy:
      allowedCIDRs:
      - 192.168.132.0/29
      - 192.168.132.8/29
      rejectedCIDRs:
      - 192.168.132.7/32
    Copy to Clipboard Toggle word wrap

As a cluster administrator, you can configure the following ExternalIP settings:

  • An ExternalIP address block used by OpenShift Container Platform to automatically populate the spec.clusterIP field for a Service object.
  • A policy object to restrict what IP addresses may be manually assigned to the spec.clusterIP array of a Service object.

Prerequisites

  • Install the OpenShift CLI (oc).
  • Access to the cluster as a user with the cluster-admin role.

Procedure

  1. Optional: To display the current external IP configuration, enter the following command: 

    $ oc describe networks.config cluster
    Copy to Clipboard Toggle word wrap

  2. To edit the configuration, enter the following command: 

    $ oc edit networks.config cluster
    Copy to Clipboard Toggle word wrap

  3. Modify the ExternalIP configuration, as in the following example: 

    apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  externalIP:
    1 
    
  ...
    Copy to Clipboard Toggle word wrap
    1
    Specify the configuration for the externalIP stanza.

  4. To confirm the updated ExternalIP configuration, enter the following command: 

    $ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

15.2.5. Next steps
Copy link

OpenShift Container Platform provides methods for communicating from outside the cluster with services running in the cluster. This method uses an Ingress Controller.

15.3.1. Using Ingress Controllers and routes
Copy link

The Ingress Operator manages Ingress Controllers and wildcard DNS.

Using an Ingress Controller is the most common way to allow external access to an OpenShift Container Platform cluster.

An Ingress Controller is configured to accept external requests and proxy them based on the configured routes. This is limited to HTTP, HTTPS using SNI, and TLS using SNI, which is sufficient for web applications and services that work over TLS with SNI.

Work with your administrator to configure an Ingress Controller to accept external requests and proxy them based on the configured routes.

The administrator can create a wildcard DNS entry and then set up an Ingress Controller. Then, you can work with the edge Ingress Controller without having to contact the administrators.

By default, every ingress controller in the cluster can admit any route created in any project in the cluster.

The Ingress Controller:

  • Has two replicas by default, which means it should be running on two worker nodes.
  • Can be scaled up to have more replicas on more nodes.
Note

The procedures in this section require prerequisites performed by the cluster administrator.

15.3.2. Prerequisites
Copy link

Before starting the following procedures, the administrator must:

  • Set up the external port to the cluster networking environment so that requests can reach the cluster.

  • 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
    Copy to Clipboard Toggle word wrap
  • 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.

15.3.3. Creating a project and service
Copy link

If the project and service that you want to expose do not exist, first create the project, then the service.

If the project and service already exist, skip to the procedure on exposing the service to create a route.

Prerequisites

  • Install the oc CLI and log in as a cluster administrator.

Procedure

  1. Create a new project for your service: 

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc new-project myproject
    Copy to Clipboard Toggle word wrap

  2. Use the oc new-app command to create a service. For example: 

    $ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.redhat.io/rhscl/mysql-80-rhel7
    Copy to Clipboard Toggle word wrap

  3. Run the following command to see that the new service is created: 

    $ oc get svc -n myproject
    Copy to Clipboard Toggle word wrap

    Example output

    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s
    Copy to Clipboard Toggle word wrap

    By default, the new service does not have an external IP address.

15.3.4. Exposing the service by creating a route
Copy link

You can expose the service as a route by using the oc expose command.

Procedure

To expose the service:

  1. Log in to OpenShift Container Platform.

  2. Log in to the project where the service you want to expose is located: 

    $ oc project myproject
    Copy to Clipboard Toggle word wrap

  3. Run the following command to expose the route: 

    $ oc expose service <service_name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc expose service mysql-80-rhel7
    Copy to Clipboard Toggle word wrap

    Example output

    route "mysql-80-rhel7" exposed
    Copy to Clipboard Toggle word wrap

  4. Use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service: 

    $ curl <pod_ip>:<port>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ curl 172.30.131.89:3306
    Copy to Clipboard Toggle word wrap

    The examples in this section uses a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

    If you have a MySQL client, log in with the standard CLI command: 

    $ mysql -h 172.30.131.89 -u admin -p
    Copy to Clipboard Toggle word wrap

    Example output

    Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
    Copy to Clipboard Toggle word wrap

Ingress Controller sharding by using route labels means that the Ingress Controller serves any route in any namespace that is selected by the route selector.

Ingress Controller sharding is useful when balancing incoming traffic load among a set of Ingress Controllers and when isolating traffic to a specific Ingress Controller. For example, company A goes to one Ingress Controller and company B to another.

Procedure

  1. Edit the router-internal.yaml file: 

    # cat router-internal.yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net>
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    routeSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
    Copy to Clipboard Toggle word wrap

  2. Apply the Ingress Controller router-internal.yaml file: 

    # oc apply -f router-internal.yaml
    Copy to Clipboard Toggle word wrap

    The Ingress Controller selects routes in any namespace that have the label type: sharded.

Ingress Controller sharding by using namespace labels means that the Ingress Controller serves any route in any namespace that is selected by the namespace selector.

Ingress Controller sharding is useful when balancing incoming traffic load among a set of Ingress Controllers and when isolating traffic to a specific Ingress Controller. For example, company A goes to one Ingress Controller and company B to another.

Procedure

  1. Edit the router-internal.yaml file: 

    # cat router-internal.yaml
    Copy to Clipboard Toggle word wrap

    Example output

    apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net>
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    namespaceSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
    Copy to Clipboard Toggle word wrap

  2. Apply the Ingress Controller router-internal.yaml file: 

    # oc apply -f router-internal.yaml
    Copy to Clipboard Toggle word wrap

    The Ingress Controller selects routes in any namespace that is selected by the namespace selector that have the label type: sharded.

15.3.7. Additional resources
Copy link

OpenShift Container Platform provides methods for communicating from outside the cluster with services running in the cluster. This method uses a load balancer.

If you do not need a specific external IP address, you can configure a load balancer service to allow external access to an OpenShift Container Platform cluster.

A load balancer service allocates a unique IP. The load balancer has a single edge router IP, which can be a virtual IP (VIP), but is still a single machine for initial load balancing.

Note

If a pool is configured, it is done at the infrastructure level, not by a cluster administrator.

Note

The procedures in this section require prerequisites performed by the cluster administrator.

15.4.2. Prerequisites
Copy link

Before starting the following procedures, the administrator must:

  • Set up the external port to the cluster networking environment so that requests can reach the cluster.

  • 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
    Copy to Clipboard Toggle word wrap
  • 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.

15.4.3. Creating a project and service
Copy link

If the project and service that you want to expose do not exist, first create the project, then the service.

If the project and service already exist, skip to the procedure on exposing the service to create a route.

Prerequisites

  • Install the oc CLI and log in as a cluster administrator.

Procedure

  1. Create a new project for your service: 

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc new-project myproject
    Copy to Clipboard Toggle word wrap

  2. Use the oc new-app command to create a service. For example: 

    $ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.redhat.io/rhscl/mysql-80-rhel7
    Copy to Clipboard Toggle word wrap

  3. Run the following command to see that the new service is created: 

    $ oc get svc -n myproject
    Copy to Clipboard Toggle word wrap

    Example output

    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s
    Copy to Clipboard Toggle word wrap

    By default, the new service does not have an external IP address.

15.4.4. Exposing the service by creating a route
Copy link

You can expose the service as a route by using the oc expose command.

Procedure

To expose the service:

  1. Log in to OpenShift Container Platform.

  2. Log in to the project where the service you want to expose is located: 

    $ oc project myproject
    Copy to Clipboard Toggle word wrap

  3. Run the following command to expose the route: 

    $ oc expose service <service_name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc expose service mysql-80-rhel7
    Copy to Clipboard Toggle word wrap

    Example output

    route "mysql-80-rhel7" exposed
    Copy to Clipboard Toggle word wrap

  4. Use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service: 

    $ curl <pod_ip>:<port>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ curl 172.30.131.89:3306
    Copy to Clipboard Toggle word wrap

    The examples in this section uses a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

    If you have a MySQL client, log in with the standard CLI command: 

    $ mysql -h 172.30.131.89 -u admin -p
    Copy to Clipboard Toggle word wrap

    Example output

    Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
    Copy to Clipboard Toggle word wrap

15.4.5. Creating a load balancer service
Copy link

Use the following procedure to create a load balancer service.

Prerequisites

  • Make sure that the project and service you want to expose exist.

Procedure

To create a load balancer service:

  1. Log in to OpenShift Container Platform.

  2. Load the project where the service you want to expose is located. 

    $ oc project project1
    Copy to Clipboard Toggle word wrap

  3. Open a text file on the master node and paste the following text, editing the file as needed:

    Sample load balancer configuration file

    apiVersion: v1
kind: Service
metadata:
  name: egress-2
    1 
    
spec:
  ports:
  - name: db
    port: 3306
    2 
    
  loadBalancerIP:
  type: LoadBalancer
    3 
    
  selector:
    name: mysql
    4
    Copy to Clipboard Toggle word wrap

    1
    Enter a descriptive name for the load balancer service.
    2
    Enter the same port that the service you want to expose is listening on.
    3
    Enter loadbalancer as the type.
    4
    Enter the name of the service.
  4. Save and exit the file.

  5. Run the following command to create the service: 

    $ oc create -f <file-name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc create -f mysql-lb.yaml
    Copy to Clipboard Toggle word wrap

  6. Execute the following command to view the new service: 

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    Example output

    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m
    Copy to Clipboard Toggle word wrap

    The service has an external IP address automatically assigned if there is a cloud provider enabled.

  7. On the master, use a tool, such as cURL, to make sure you can reach the service using the public IP address: 

    $ curl <public-ip>:<port>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ curl 172.29.121.74:3306
    Copy to Clipboard Toggle word wrap

    The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connecting with the service:

    If you have a MySQL client, log in with the standard CLI command: 

    $ mysql -h 172.30.131.89 -u admin -p
    Copy to Clipboard Toggle word wrap

    Example output

    Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
    Copy to Clipboard Toggle word wrap

You can attach an external IP address to a service so that it is available to traffic outside the cluster. This is generally useful only for a cluster installed on bare metal hardware. The external network infrastructure must be configured correctly to route traffic to the service.

15.5.1. Prerequisites
Copy link

15.5.2. Attaching an ExternalIP to a service
Copy link

You can attach an ExternalIP to a service. If your cluster is configured to allocate an ExternalIP automatically, you might not need to manually attach an ExternalIP to the service.

Procedure

  1. Optional: To confirm what IP address ranges are configured for use with ExternalIP, enter the following command: 

    $ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'
    Copy to Clipboard Toggle word wrap

    If autoAssignCIDRs is set, OpenShift Container Platform automatically assigns an ExternalIP to a new Service object if the spec.externalIPs field is not specified.

  2. Attach an ExternalIP to the service.

    1. If you are creating a new service, specify the spec.externalIPs field and provide an array of one or more valid IP addresses. For example: 

      apiVersion: v1
kind: Service
metadata:
  name: svc-with-externalip
spec:
  ...
  externalIPs:
  - 192.174.120.10
      Copy to Clipboard Toggle word wrap

    2. If you are attaching an ExternalIP to an existing service, enter the following command. Replace <name> with the service name. Replace <ip_address> with a valid ExternalIP address. You can provide multiple IP addresses separated by commas. 

      $ oc patch svc <name> -p \
  '{
    "spec": {
      "externalIPs": [ "<ip_address>" ]
    }
  }'
      Copy to Clipboard Toggle word wrap

      For example: 

      $ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'
      Copy to Clipboard Toggle word wrap

      Example output

      "mysql-55-rhel7" patched
      Copy to Clipboard Toggle word wrap

  3. To confirm that an ExternalIP address is attached to the service, enter the following command. If you specified an ExternalIP for a new service, you must create the service first. 

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    Example output

    NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m
    Copy to Clipboard Toggle word wrap

15.5.3. Additional resources
Copy link

OpenShift Container Platform provides methods for communicating from outside the cluster with services running in the cluster. This method uses a NodePort.

Use a NodePort-type Service resource to expose a service on a specific port on all nodes in the cluster. The port is specified in the Service resource’s .spec.ports[*].nodePort field.

Important

Using a node port requires additional port resources.

A NodePort exposes the service on a static port on the node’s IP address. NodePorts are in the 30000 to 32767 range by default, which means a NodePort is unlikely to match a service’s intended port. For example, port 8080 may be exposed as port 31020 on the node.

The administrator must ensure the external IP addresses are routed to the nodes.

NodePorts and external IPs are independent and both can be used concurrently.

Note

The procedures in this section require prerequisites performed by the cluster administrator.

15.6.2. Prerequisites
Copy link

Before starting the following procedures, the administrator must:

  • Set up the external port to the cluster networking environment so that requests can reach the cluster.

  • 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 <user_name>
    Copy to Clipboard Toggle word wrap
  • 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.

15.6.3. Creating a project and service
Copy link

If the project and service that you want to expose do not exist, first create the project, then the service.

If the project and service already exist, skip to the procedure on exposing the service to create a route.

Prerequisites

  • Install the oc CLI and log in as a cluster administrator.

Procedure

  1. Create a new project for your service: 

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc new-project myproject
    Copy to Clipboard Toggle word wrap

  2. Use the oc new-app command to create a service. For example: 

    $ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.redhat.io/rhscl/mysql-80-rhel7
    Copy to Clipboard Toggle word wrap

  3. Run the following command to see that the new service is created: 

    $ oc get svc -n myproject
    Copy to Clipboard Toggle word wrap

    Example output

    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s
    Copy to Clipboard Toggle word wrap

    By default, the new service does not have an external IP address.

15.6.4. Exposing the service by creating a route
Copy link

You can expose the service as a route by using the oc expose command.

Procedure

To expose the service:

  1. Log in to OpenShift Container Platform.

  2. Log in to the project where the service you want to expose is located: 

    $ oc project myproject
    Copy to Clipboard Toggle word wrap

  3. To expose a node port for the application, enter the following command. OpenShift Container Platform automatically selects an available port in the 30000-32767 range. 

    $ oc expose dc mysql-80-rhel7 --type=NodePort --name=mysql-ingress
    Copy to Clipboard Toggle word wrap

  4. Optional: To confirm the service is available with a node port exposed, enter the following command: 

    $ oc get svc -n myproject
    Copy to Clipboard Toggle word wrap

    Example output

    NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
mysql-80-rhel7   ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
mysql-ingress    NodePort    172.30.107.72    <none>        3306:31345/TCP   39s
    Copy to Clipboard Toggle word wrap

  5. Optional: To remove the service created automatically by the oc new-app command, enter the following command: 

    $ oc delete svc mysql-80-rhel7
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat