Configuring the Ingress Controller endpoint publishing strategy | Networking

Ingress Controller endpoint publishing strategy
- Configuring the Ingress Controller endpoint publishing scope to Internal
- Configuring the Ingress Controller endpoint publishing scope to External
Additional resources

Ingress Controller endpoint publishing strategy

nodeportService endpoint publishing strategy

The nodeportService endpoint publishing strategy publishes the Ingress Controller using a Kubernetes nodeport service.

In this configuration, the Ingress Controller deployment uses container networking. A nodeportService is created to publish the deployment. The specific node ports are dynamically allocated by OKD; however, to support static port allocations, your changes to the node port field of the managed nodeportService are preserved.

Figure 1. Diagram of nodeportService

The preceding graphic shows the following concepts pertaining to OKD Ingress nodeport endpoint publishing strategy:

All the available nodes in the cluster have their own, externally accessible IP addresses. The service running in the cluster is bound to the unique nodeport for all the nodes.
When the client connects to a node that is down, for example, by connecting the 10.0.128.4 IP address in the graphic, the node port directly connects the client to an available node that is running the service. In this scenario, no load balancing is required. As the image shows, the 10.0.128.4 address is down and another IP address must be used instead.

The Ingress Operator ignores any updates to .spec.ports[].nodeport fields of the service.

By default, ports are allocated automatically and you can access the port allocations for integrations. However, sometimes static port allocations are necessary to integrate with existing infrastructure which may not be easily reconfigured in response to dynamic ports. To achieve integrations with static node ports, you can update the managed service resource directly.

For more information, see the Kubernetes Services documentation on nodeport.

HostNetwork endpoint publishing strategy

The HostNetwork endpoint publishing strategy publishes the Ingress Controller on node ports where the Ingress Controller is deployed.

An Ingress Controller with the HostNetwork endpoint publishing strategy can have only one pod replica per node. If you want n replicas, you must use at least n nodes where those replicas can be scheduled. Because each pod replica requests ports 80 and 443 on the node host where it is scheduled, a replica cannot be scheduled to a node if another pod on the same node is using those ports.

Configuring the Ingress Controller endpoint publishing scope to Internal

When a cluster administrator installs a new cluster without specifying that the cluster is private, the default Ingress Controller is created with a scope set to External. Cluster administrators can change an External scoped Ingress Controller to Internal.

Prerequisites

You installed the oc CLI.

Procedure

To change an External scoped Ingress Controller to Internal, enter the following command:

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

To check the status of the Ingress Controller, enter the following command:
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
- The Progressing status condition indicates whether you must take further action. For example, the status condition can indicate that you need to delete the service by entering the following command:
  $ oc -n openshift-ingress delete services/router-default
  If you delete the service, the Ingress Operator recreates it as Internal.

Configuring the Ingress Controller endpoint publishing scope to External

When a cluster administrator installs a new cluster without specifying that the cluster is private, the default Ingress Controller is created with a scope set to External.

The Ingress Controller’s scope can be configured to be Internal during installation or after, and cluster administrators can change an Internal Ingress Controller to External.

On some platforms, it is necessary to delete and recreate the service.

Changing the scope can cause disruption to Ingress traffic, potentially for several minutes. This applies to platforms where it is necessary to delete and recreate the service, because the procedure can cause OKD to deprovision the existing service load balancer, provision a new one, and update DNS.

Prerequisites

You installed the oc CLI.

Procedure

To change an Internal scoped Ingress Controller to External, enter the following command:

$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

To check the status of the Ingress Controller, enter the following command:
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
- The Progressing status condition indicates whether you must take further action. For example, the status condition can indicate that you need to delete the service by entering the following command:
  $ oc -n openshift-ingress delete services/router-default
  If you delete the service, the Ingress Operator recreates it as External.

Additional resources

For more information, see Ingress Controller configuration parameters.