mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-2337:Adding graphics to Ingress, NodePort and LoadBalancer
This commit is contained in:
committed by
openshift-cherrypick-robot
parent
7abcb55156
commit
5525021454
BIN
images/202_OpenShift_Ingress_0222_load_balancer.png
Normal file
BIN
images/202_OpenShift_Ingress_0222_load_balancer.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
BIN
images/202_OpenShift_Ingress_0222_node_port.png
Normal file
BIN
images/202_OpenShift_Ingress_0222_node_port.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
@@ -11,6 +11,14 @@ The `NodePortService` endpoint publishing strategy publishes the Ingress Control
|
||||
|
||||
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 {product-title}; however, to support static port allocations, your changes to the node port field of the managed `NodePortService` are preserved.
|
||||
|
||||
.Diagram of NodePortService
|
||||
image::202_OpenShift_Ingress_0222_node_port.png[{product-title} Ingress NodePort endpoint publishing strategy]
|
||||
|
||||
The preceding graphic shows the following concepts pertaining to {product-title} 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 way of the `193.10.0.10` 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, `193.10.0.10` 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.
|
||||
|
||||
@@ -20,6 +20,14 @@ If you do not, all of your nodes will lose egress connectivity to the internet.
|
||||
If you want to change the `scope` for an `IngressController` object, you must delete and then recreate that `IngressController` object. You cannot change the `.spec.endpointPublishingStrategy.loadBalancer.scope` parameter after the custom resource (CR) is created.
|
||||
====
|
||||
|
||||
.Diagram of LoadBalancer
|
||||
image::202_OpenShift_Ingress_0222_load_balancer.png[{product-title} Ingress LoadBalancerService endpoint publishing strategy]
|
||||
|
||||
The preceding graphic shows the following concepts pertaining to {product-title} Ingress LoadBalancerService endpoint publishing strategy:
|
||||
|
||||
* You can load load balance externally, using the cloud provider load balancer, or internally, using the OpenShift Ingress Controller Load Balancer.
|
||||
* You can use the single IP address of the load balancer and more familiar ports, such as 8080 and 4200 as shown on the cluster depicted in the graphic.
|
||||
* Traffic from the external load balancer is directed at the pods, and managed by the load balancer, as depicted in the instance of a down node.
|
||||
See the link:https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer[Kubernetes Services documentation]
|
||||
for implementation details.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user