Merge pull request #34657 from skrthomas/OSDOCS-2326

Author: Bob Furu

modules/nw-ne-comparing-ingress-route.adoc

@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+[id="nw-ne-comparing-ingress-route_{context}"]
+= Comparing routes and Ingress
+The Kubernetes Ingress resource in {product-title} implements the Ingress Controller with a shared router service that runs as a pod inside the cluster. The most common way to manage Ingress traffic is with the Ingress Controller. You can scale and replicate this pod like any other regular pod. This router service is based on link:http://www.haproxy.org/[HAProxy], which is an open source load balancer solution.
+
+The {product-title} route provides Ingress traffic to services in the cluster. Routes provide advanced features that might not be supported by standard Kubernetes Ingress Controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.
+
+Ingress traffic accesses services in the cluster through a route. Routes and Ingress are the main resources for handling Ingress traffic. Ingress provides features similar to a route, such as accepting external requests and delegating them based on the route. However, with Ingress you can only allow certain types of connections: HTTP/2, HTTPS and server name identification (SNI), and TLS with certificate. In {product-title}, routes are generated to meet the conditions specified by the Ingress resource.

modules/nw-ne-openshift-ingress.adoc

@@ -0,0 +1,10 @@
+// Module included in the following assemblies:
+// * understanding-networking.adoc
+
+
+[id="nw-ne-openshift-ingress_{context}"]
+= {product-title} Ingress Operator
+When you create your {product-title} cluster, pods and services running on the cluster are each allocated their own IP addresses. The IP addresses are accessible to other pods and services running nearby but are not accessible to outside clients. The Ingress Operator implements the `IngressController` API and is the component responsible for enabling external access to {product-title} cluster services.
+
+The Ingress Operator makes it possible for external clients to access your service by deploying and managing one or more HAProxy-based
+link:https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/[Ingress Controllers] to handle routing. You can use the Ingress Operator to route traffic by specifying {product-title} `Route` and Kubernetes `Ingress` resources. Configurations within the Ingress Controller, such as the ability to define `endpointPublishingStrategy` type and internal load balancing, provide ways to publish Ingress Controller endpoints.

modules/nw-ne-ways-to-manage-ingress-traffic.adoc

@@ -0,0 +1,27 @@
+// Module included in the following assemblies:
+//
+// * networking/understanding-networking.adoc
+
+[id="nw-ne-ways-to-manage-ingress-traffic_{context}"]
+= Ways to manage ingress controller traffic
+The following table provides an overview of ways that administrators can manage their Ingress traffic:
+[cols="1,2",options="header"]
+|===
+|Method |Description
+
+|Ingress
+|Ingress accept external requests and proxy them based on the route. An Ingress is a Kubernetes resource that provides some of the same features as routes (which is an {product-title} resource). You can only allow certain types of traffic: HTTP, HTTPS and server name identification (SNI), and TLS with SNI. In {product-title}, routes are generated to meet the conditions specified by the Ingress object.
+
+|Route
+|Routes provide Ingress traffic to services in the cluster. The concept of Routes in {product-title}  serve a similar purpose as Kubernetes Ingress objects and provide more features. Routes provide advanced features that may not be supported by Kubernetes Ingress Controllers through a standard interface, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.
+
+|External load balancer
+|This resource instructs {product-title} to create a load balancer in a cloud environment.
+
+|Service external IP
+|This method instructs {product-title} to set NAT rules to redirect traffic from one of the cluster IPs to the container.
+
+|Node Port
+|With this method, {product-title} exposes a service on a static port on the node IP address. You must ensure that the external IP addresses are properly routed to the nodes.
+
+|===

networking/ingress-operator.adoc

@@ -4,14 +4,7 @@ include::modules/common-attributes.adoc[]
 :context: configuring-ingress
 
 toc::[]
-
-The Ingress Operator implements the `ingresscontroller` API and is the
-component responsible for enabling external access to {product-title}
-cluster services. The Operator makes this possible by deploying and
-managing one or more HAProxy-based
-link:https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/[Ingress Controllers]
-to handle routing. You can use the Ingress Operator to route traffic by
-specifying {product-title} `Route` and Kubernetes `Ingress` resources.
+include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1]
 
 include::modules/nw-installation-ingress-config-asset.adoc[leveloffset=+1]
 

networking/understanding-networking.adoc

@@ -4,13 +4,12 @@ include::modules/common-attributes.adoc[]
 :context: understanding-networking
 
 toc::[]
+Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections:
+* Service types, such as node ports or load balancers
 
-Kubernetes ensures that pods are able to network with each other, and allocates
-each pod an IP address from an internal network. This ensures all containers
-within the pod behave as if they were on the same host. Giving each pod its own
-IP address means that pods can be treated like physical hosts or virtual
-machines in terms of port allocation, networking, naming, service discovery,
-load balancing, application configuration, and migration.
+* API resources, such as `Ingress` and `Route`
+
+By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can network, but clients outside the cluster do not have networking access. This ensures all containers within the pod behave as if they were on the same host. When you expose your application to external traffic, giving each pod its own IP address means that pods can be treated like physical hosts or virtual machines in terms of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
 
 [NOTE]
 ====
@@ -22,3 +21,5 @@ If you allow a pod host network access, you grant the pod privileged access to t
 ====
 
 include::modules/nw-ne-openshift-dns.adoc[leveloffset=+1]
+include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1]
+include::modules/nw-ne-comparing-ingress-route.adoc[leveloffset=+2]