Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 8. Configuring the Ingress Controller endpoint publishing strategy

8.1. Ingress Controller endpoint publishing strategy
Copia collegamento

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 OpenShift Container Platform; however, to support static port allocations, your changes to the node port field of the managed 
NodePortService
are preserved.

Figure 8.1. Diagram of NodePortService

OpenShift Container Platform Ingress NodePort endpoint publishing strategy

The preceding graphic shows the following concepts pertaining to OpenShift Container Platform 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.
Note

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.

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
      .

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
.

Important

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 OpenShift Container Platform 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
      .

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima