Merge pull request #44002 from Amrita42/Grammarnew

kalexand-rh · web-flow · commit 8e02e4de8bc8 · 2022-03-31T08:32:00.000-04:00
corrected wrong instances of Ingress Controller
diff --git a/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc b/installing/installing_gcp/installing-gcp-user-infra-vpc.adoc
@@ -127,7 +127,7 @@ include::modules/installation-gcp-user-infra-adding-ingress.adoc[leveloffset=+1]
 
 [id="installation-gcp-user-infra-vpc-adding-firewall-rules"]
 == Adding ingress firewall rules
-The cluster requires several firewall rules. If you do not use a shared VPC, these rules are created by the ingress controller via the GCP cloud provider. When you use a shared VPC, you can either create cluster-wide firewall rules for all services now or create each rule based on events, when the cluster requests access. By creating each rule when the cluster requests access, you know exactly which firewall rules are required. By creating cluster-wide firewall rules, you can apply the same rule set across multiple clusters.
+The cluster requires several firewall rules. If you do not use a shared VPC, these rules are created by the Ingress Controller via the GCP cloud provider. When you use a shared VPC, you can either create cluster-wide firewall rules for all services now or create each rule based on events, when the cluster requests access. By creating each rule when the cluster requests access, you know exactly which firewall rules are required. By creating cluster-wide firewall rules, you can apply the same rule set across multiple clusters.
 
 If you choose to create each rule based on events, you must create firewall rules after you provision the cluster and during the life of the cluster when the console notifies you that rules are missing. Events that are similar to the following event are displayed, and you must add the firewall rules that are required:
 
diff --git a/modules/ingress-operator.adoc b/modules/ingress-operator.adoc
@@ -46,9 +46,9 @@ The Ingress Operator sets up the router in the `openshift-ingress` project and c
 $ oc get deployment -n openshift-ingress
 ----
 
-The Ingress Operator uses the `clusterNetwork[].cidr` from the `network/cluster` status to determine what mode (IPv4, IPv6, or dual stack) the managed ingress controller (router) should operate in. For example, if `clusterNetwork` contains only a v6 `cidr`, then the ingress controller operate in IPv6-only mode.
+The Ingress Operator uses the `clusterNetwork[].cidr` from the `network/cluster` status to determine what mode (IPv4, IPv6, or dual stack) the managed Ingress Controller (router) should operate in. For example, if `clusterNetwork` contains only a v6 `cidr`, then the Ingress Controller operates in IPv6-only mode.
 
-In the following example, ingress controllers managed by the Ingress Operator will run in IPv4-only mode because only one cluster network exists and the network is an IPv4 `cidr`:
+In the following example, Ingress Controllers managed by the Ingress Operator will run in IPv4-only mode because only one cluster network exists and the network is an IPv4 `cidr`:
 
 [source,terminal]
 ----
diff --git a/modules/migration-setting-up-target-cluster-to-accept-source-dns-domain.adoc b/modules/migration-setting-up-target-cluster-to-accept-source-dns-domain.adoc
@@ -26,11 +26,11 @@ In addition, when you migrate the application, another route is created in the t
 
 . Create a DNS record with your DNS provider that points the application's FQDN in the source cluster to the IP address of the default load balancer of the target cluster. This will redirect traffic away from your source cluster to your target cluster.
 +
-The FQDN of the application resolves to the load balancer of the target cluster. The default ingress controller router accept requests for that FQDN because a route for that hostname is exposed.
+The FQDN of the application resolves to the load balancer of the target cluster. The default Ingress Controller router accept requests for that FQDN because a route for that hostname is exposed.
 
 For secure HTTPS access, perform the following additional step:
 
-. Replace the x509 certificate of the default ingress controller created during the installation process with a custom certificate.
+. Replace the x509 certificate of the default Ingress Controller created during the installation process with a custom certificate.
 . Configure this certificate to include the wildcard DNS domains for both the source and target clusters in the `subjectAltName` field.
 +
 The new certificate is valid for securing connections made using either DNS domain.
diff --git a/modules/nw-ingress-controller-configuration-parameters.adoc b/modules/nw-ingress-controller-configuration-parameters.adoc
@@ -115,7 +115,7 @@ The Ingress Operator converts the TLS `1.0` of an `Old` or `Custom` profile to `
 `clientTLS` has the required subfields, `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA`.
 
 The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. The `ClientCA` subfield specifies a config map that is in the openshift-config namespace. The config map should contain a CA certificate bundle.
-The `AllowedSubjectPatterns` is an optional value that specifies a list of regular expressions, which are matched against the distinguished name on a valid client certificate to filter requests. The regular expressions must use PCRE syntax. At least one pattern must match a client certificate's distinguished name; otherwise, the ingress controller rejects the certificate and denies the connection. If not specified, the ingress controller does not reject certificates based on the distinguished name.
+The `AllowedSubjectPatterns` is an optional value that specifies a list of regular expressions, which are matched against the distinguished name on a valid client certificate to filter requests. The regular expressions must use PCRE syntax. At least one pattern must match a client certificate's distinguished name; otherwise, the Ingress Controller rejects the certificate and denies the connection. If not specified, the Ingress Controller does not reject certificates based on the distinguished name.
 
 |`routeAdmission`
 |`routeAdmission` defines a policy for handling new route claims, such as allowing or denying claims across namespaces.
@@ -150,7 +150,7 @@ The `AllowedSubjectPatterns` is an optional value that specifies a list of regul
 |`httpHeaders`
 |`httpHeaders` defines the policy for HTTP headers.
 
-By setting the `forwardedHeaderPolicy` for the `IngressControllerHTTPHeaders`, you specify when and how the Ingress controller sets the `Forwarded`, `X-Forwarded-For`, `X-Forwarded-Host`, `X-Forwarded-Port`, `X-Forwarded-Proto`, and `X-Forwarded-Proto-Version` HTTP headers.
+By setting the `forwardedHeaderPolicy` for the `IngressControllerHTTPHeaders`, you specify when and how the Ingress Controller sets the `Forwarded`, `X-Forwarded-For`, `X-Forwarded-Host`, `X-Forwarded-Port`, `X-Forwarded-Proto`, and `X-Forwarded-Proto-Version` HTTP headers.
 
 By default, the policy is set to `Append`.
 
diff --git a/modules/nw-ingress-controller-endpoint-publishing-strategies.adoc b/modules/nw-ingress-controller-endpoint-publishing-strategies.adoc
@@ -32,4 +32,4 @@ For more information, see the link:https://kubernetes.io/docs/concepts/services-
 
 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.
+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.
diff --git a/modules/nw-ingress-controller-tls-profiles.adoc b/modules/nw-ingress-controller-tls-profiles.adoc
@@ -3,7 +3,7 @@
 // * ingress/configure-ingress-operator.adoc
 
 [id="nw-ingress-controller-tls-profiles_{context}"]
-= Ingress controller TLS profiles
+= Ingress Controller TLS profiles
 
 The `tlsSecurityProfile` parameter defines the schema for a TLS security profile. This object is used by operators to apply TLS security settings to operands.
 
diff --git a/modules/nw-ne-ways-to-manage-ingress-traffic.adoc b/modules/nw-ne-ways-to-manage-ingress-traffic.adoc
@@ -3,7 +3,7 @@
 // * networking/understanding-networking.adoc
 
 [id="nw-ne-ways-to-manage-ingress-traffic_{context}"]
-= Ways to manage ingress controller traffic
+= 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"]
 |===
diff --git a/modules/nw-using-ingress-and-routes.adoc b/modules/nw-using-ingress-and-routes.adoc
@@ -23,7 +23,7 @@ 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.
+By default, every Ingress Controller in the cluster can admit any route created in any project in the cluster.
 
 The Ingress Controller:
 
diff --git a/modules/ossm-architecture.adoc b/modules/ossm-architecture.adoc
@@ -20,7 +20,7 @@ The data plane is implemented in such a way that it intercepts all inbound (ingr
 
 ** *Gateways* are proxies operating as load balancers receiving incoming or outgoing HTTP/TCP connections. Gateway configurations are applied to standalone Envoy proxies that are running at the edge of the mesh, rather than sidecar Envoy proxies running alongside your service workloads. You use a Gateway to manage inbound and outbound traffic for your mesh, letting you specify which traffic you want to enter or leave the mesh.
 
-*** *Ingress-gateway* - Also known as an ingress controller, the Ingress Gateway is a dedicated Envoy proxy that receives and controls traffic entering the service mesh. An Ingress Gateway allows features such as monitoring and route rules to be applied to traffic entering the cluster.
+*** *Ingress-gateway* - Also known as an Ingress Controller, the Ingress Gateway is a dedicated Envoy proxy that receives and controls traffic entering the service mesh. An Ingress Gateway allows features such as monitoring and route rules to be applied to traffic entering the cluster.
 
 *** *Egress-gateway* - Also known as an egress controller, the Egress Gateway is a dedicated Envoy proxy that manages traffic leaving the service mesh. An Egress Gateway allows features such as monitoring and route rules to be applied to traffic exiting the mesh.
 
diff --git a/modules/security-network-policies.adoc b/modules/security-network-policies.adoc
@@ -7,5 +7,5 @@
 
 Using _network policies_, you can isolate pods from each other in the same project.
 Network policies can deny all network access to a pod,
-only allow connections for the ingress controller, reject connections from
+only allow connections for the Ingress Controller, reject connections from
 pods in other projects, or set similar rules for how networks behave.
diff --git a/networking/external_dns_operator/nw-control-dns-records-public-hosted-zone-aws.adoc b/networking/external_dns_operator/nw-control-dns-records-public-hosted-zone-aws.adoc
@@ -85,7 +85,7 @@ spec:
 <5> Defines the `AWS Route53` DNS provider.
 <6> Defines options for the source of DNS records.
 <7> Defines OpenShift `route` resource as the source for the DNS records which gets created in the previously specified DNS provider.
-<8> If the source is `OpenShiftRoute`, then you can pass the OpenShift ingress controller name. External DNS Operator selects the canonical hostname of that router as the target while creating CNAME record.
+<8> If the source is `OpenShiftRoute`, then you can pass the OpenShift Ingress Controller name. External DNS Operator selects the canonical hostname of that router as the target while creating CNAME record.
 
 . Check the records created for OCP routes using the following command:
 +
diff --git a/networking/external_dns_operator/nw-control-dns-records-public-hosted-zone-azure.adoc b/networking/external_dns_operator/nw-control-dns-records-public-hosted-zone-azure.adoc
@@ -84,7 +84,7 @@ spec:
 <2> Define the zone ID.
 <3> defines the Azure DNS provider.
 <4> You can define options for the source of DNS records.
-<5> If the source is `OpenShiftRoute` then you can pass the OpenShift ingress controller name. External DNS selects the canonical hostname of that router as the target while creating CNAME record.
+<5> If the source is `OpenShiftRoute` then you can pass the OpenShift Ingress Controller name. External DNS selects the canonical hostname of that router as the target while creating CNAME record.
 <6> Defines OpenShift `route` resource as the source for the DNS records which gets created in the previously specified DNS provider.
 
 . Check the records created for OCP routes using the following command:
diff --git a/networking/external_dns_operator/nw-control-dns-records-public-managed-zone-gcp.adoc b/networking/external_dns_operator/nw-control-dns-records-public-managed-zone-gcp.adoc
@@ -100,7 +100,7 @@ spec:
 <4> Specify the exact domain of the zone you want to update. The hostname of the routes must be subdomains of the specified domain.
 <5> Defines Google Cloud DNS provider.
 <6> You can define options for the source of DNS records.
-<7> If the source is `OpenShiftRoute` then you can pass the OpenShift ingress controller name. External DNS selects the canonical hostname of that router as the target while creating CNAME record.
+<7> If the source is `OpenShiftRoute` then you can pass the OpenShift Ingress Controller name. External DNS selects the canonical hostname of that router as the target while creating CNAME record.
 <8> Defines OpenShift `route` resource as the source for the DNS records which gets created in the previously specified DNS provider.
 
 . Check the records created for OCP routes using the following command:
diff --git a/networking/external_dns_operator/nw-external-dns-operator-configuration-parameters.adoc b/networking/external_dns_operator/nw-external-dns-operator-configuration-parameters.adoc
@@ -99,6 +99,6 @@ source:
 ----
 
 <1> ExternalDNS` uses type `route` as source for creating dns records.
-<2> If the source is `OpenShiftRoute`, then you can pass the ingress controller name. The `ExternalDNS` uses canonical name of ingress controller as the target for CNAME record.
+<2> If the source is `OpenShiftRoute`, then you can pass the Ingress Controller name. The `ExternalDNS` uses canonical name of Ingress Controller as the target for CNAME record.
 
 |===
diff --git a/welcome/oke_about.adoc b/welcome/oke_about.adoc
@@ -141,7 +141,7 @@ create microsegmentation between deployed application services on the cluster.
 
 You can also use the `Route` API objects that are found in {product-title},
 including its sophisticated integration with the HAproxy edge routing layer as an
-out of the box Kubernetes ingress controller.
+out of the box Kubernetes Ingress Controller.
 
 [[about_oke_core_user_experience]]
 === Core user experience
@@ -202,7 +202,7 @@ found in {product-title}. That ingress solution is supported in {oke}.
 {oke} users are supported for the Kubernetes ingress control object, which
 offers integrations with public cloud providers. Red Hat Service Mesh, which is
 derived from the istio.io open source project, is not supported in {oke}. Also,
-the Kourier ingress controller found in OpenShift Serverless is not supported
+the Kourier Ingress Controller found in OpenShift Serverless is not supported
 on {oke}.
 
 === Developer experience

Original file line number	Diff line number	Diff line change
`@@ -26,11 +26,11 @@ In addition, when you migrate the application, another route is created in the t`
`26`	`26`
`27`	`27`	`. Create a DNS record with your DNS provider that points the application's FQDN in the source cluster to the IP address of the default load balancer of the target cluster. This will redirect traffic away from your source cluster to your target cluster.`
`28`	`28`	`+`
`29`		`-The FQDN of the application resolves to the load balancer of the target cluster. The default ingress controller router accept requests for that FQDN because a route for that hostname is exposed.`
	`29`	`+The FQDN of the application resolves to the load balancer of the target cluster. The default Ingress Controller router accept requests for that FQDN because a route for that hostname is exposed.`
`30`	`30`
`31`	`31`	`For secure HTTPS access, perform the following additional step:`
`32`	`32`
`33`		`-. Replace the x509 certificate of the default ingress controller created during the installation process with a custom certificate.`
	`33`	`+. Replace the x509 certificate of the default Ingress Controller created during the installation process with a custom certificate.`
`34`	`34`	. Configure this certificate to include the wildcard DNS domains for both the source and target clusters in the `subjectAltName` field.
`35`	`35`	`+`
`36`	`36`	`The new certificate is valid for securing connections made using either DNS domain.`
Original file line number	Diff line number	Diff line change
`@@ -32,4 +32,4 @@ For more information, see the link:https://kubernetes.io/docs/concepts/services-`
`32`	`32`
`33`	`33`	The `HostNetwork` endpoint publishing strategy publishes the Ingress Controller on node ports where the Ingress Controller is deployed.
`34`	`34`
`35`		-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.
	`35`	+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.