Skip to content

OSDOCS-14879: add enablement procedure #94480

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
214 changes: 214 additions & 0 deletions modules/nw-ingress-gateway-api-enable.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,214 @@
// Modules included in the following assemblies:
//
// * networking/configuring_ingress_cluster_traffic/ingress-gateway-api.adoc

:_mod-docs-content-type: PROCEDURE
[id="nw-ingress-gateway-api-enable_{context}"]
= Getting started with Gateway API for the Ingress Operator

When you enable Gateway API, it installs the subscription, the Istio operator, the custom resource definitions (CRDs), and creates the Istio resources.

.Procedure

. Create a `GatewayClass` object that contains the following information:
+
.Example `GatewayClass` CR
[source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: openshift-default
spec:
controllerName: openshift.io/gateway-controller/v1 <1>
----
Comment on lines +16 to +24
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of just the manifest, you could also add the command:

Suggested change
[source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: openshift-default
spec:
controllerName: openshift.io/gateway-controller/v1 <1>
----
oc create -f -<<'EOF'
[source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: openshift-default
spec:
controllerName: openshift.io/gateway-controller/v1 <1>
----
EOF
Output:
$ gatewayclass.gateway.networking.k8s.io/openshift-default created

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, i added it as a separate step, PTAL

<1> The controller name.
+
[IMPORTANT]
====
The controller name must be exactly as shown for the Ingress Operator to manage it. If you set this field to anything else, the Ingress Operator ignores the `GatewayClass` object and all associated `Gateway`, `GRPCRoute`, and `HTTPRoute` objects. The controller name is tied to the implementation of Gateway API in {product-title}, and `openshift.io/gateway-controller/v1` is the only controller name allowed.
====

. Run the following command to create the `GatewayClass` resource:
+
[source,terminal]
----
$ oc create -f <gatewayclass_resource>.yaml
Copy link

@candita candita Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<gatewayclass_resource>.yaml isn't defined anywhere. You could mention creating a file instead of manifest in line 15

----
+
.Example output
[source,terminal]
----
gatewayclass.gateway.networking.k8s.io/openshift-default created
----

Copy link

@candita candita Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add the following to be a bit more helpful:

Behind the scenes, the Ingress Operator installs a pared-down OSSM, an Istio custom resource, and a new deployment in the openshift-ingress namespace, called istio-ingressgateway. Check to ensure it is ready and available:

$ oc get deployment -n openshift-ingress

NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
istiod-openshift-gateway   1/1     1            1           55s
router-default             2/2     2            2           6h4m

If it is ready and available, Gateway API and OSSM have been installed successfully and are ready to use. See the following sections for the next steps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i can add this optional step. does it sit between steps one and two, or is this something a user would do before performing any of the steps in the procedure?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually this seems like it happens after creating the GatewayClass resource, is that right? so maybe it's more like a verification step

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it verifies that the behind-the-scenes activities took place.

. Create a secret by using the default certificate by running the following command:
+
[source,terminal]
----
$ oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it tell them anywhere how to create the wildcard.crt and wildcard.key?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have a lot of existing docs on creating certificates. do you mean something like this? https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/security_and_compliance/configuring-certificates i can link it

----

. Get the domain of the Ingress Operator by running the following command:
+
[source,terminal]
----
$ DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
----

. Create a `Gateway` object with the following information:
+
Copy link

@candita candita Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One extra step here, and including the command to get the correct domain:

$ DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
$ oc apply -f - <<EOF

.Example `Gateway` CR
[source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
namespace: openshift-ingress <1>
spec:
gatewayClassName: openshift-default <2>
listeners:
- name: https <3>
hostname: "*.gwapi.${DOMAIN}" <4>
port: 443
protocol: HTTPS
tls:
mode: Terminate
certificateRefs:
- name: gwapi-wildcard <5>
allowedRoutes:
namespaces:
from: All
----
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
----
----
EOF

<1> The `Gateway` object must be created in the `openshift-ingress` namespace.
<2> The `Gateway` object must reference the name of the previously created `GatewayClass` object.
<3> The HTTPS listener listens for HTTPS requests that match a subdomain of the cluster domain. You use this listener to configure ingress to your applications by using Gateway API `HTTPRoute` resources.
<4> The hostname must be a subdomain of the Ingress Operator domain. If you use a domain, the listener tries to serve all traffic in that domain.
<5> The name of the previously created secret using the default certificate.

. Apply the resource by running the following command:
+
[source,terminal]
----
$ oc apply -f <gateway_resource>.yaml
----

. Optional: When you create a `Gateway` object, {SMProductName} automatically provisions a deployment and service with the same name. Verify this by running the following commands:
+
[source,terminal]
----
$ oc get deployment -n openshift-ingress example-gateway
----
+
.Example output
[source,terminal]
----
NAME READY UP-TO-DATE AVAILABLE AGE
example-gateway 1/1 1 1 25s
----
+
[source,terminal]
----
$ oc get service -n openshift-ingress example-gateway
----
+
.Example output
[source,terminal]
----
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
example-gateway LoadBalancer 10.1.2.3 <external ipname> <port-info> 47s
----

. Optional: The Ingress Operator automatically creates a `DNSRecord` CR using the hostname from the listeners, and adds the label `istio.io/gateway-name=example-gateway`. Verify the status of the DNS record by running the following command:
+
[source,terminal]
----
$ oc get dnsrecord -n openshift-ingress -l istio.io/gateway-name=example-gateway -o yaml
----
+
.Example output
[source,yaml]
----
kind: DNSRecord
...
status:
...
zones:
- conditions:
- message: The DNS provider succeeded in ensuring the record
reason: ProviderSuccess
status: "True"
type: Published
dnsZone:
tags:
...
- conditions:
- message: The DNS provider succeeded in ensuring the record
reason: ProviderSuccess
status: "True"
type: Published
dnsZone:
id: ...
----

. Create an `HTTPRoute` resource that directs requests to your application:
+
.Example `HTTPRoute` CR
[source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-route
namespace: example-app-ns <1>
spec:
parentRefs: <2>
- name: example-gateway
namespace: openshift-ingress
hostnames: ["example.gwapi.${DOMAIN}"] <3>
rules: <4>
- backendRefs:
- name: example-app <5>
port: 8443
----
<1> The namespace you are deploying your application.
<2> This field must point to the `Gateway` object you previously configured.
<3> The hostname must match the one specified in the `Gateway` object. In this case, the listeners use a wildcard hostname.
<4> This field specifies the backend references that point to your service.
<5> The name of your application.

. Apply the resource by running the following command:
+
[source,terminal]
----
$ oc apply -f <http_resource>.yaml
----
+
.Example output
[source,terminal]
----
httproute.gateway.networking.k8s.io/http created
----

.Verification

. Verify that the `Gateway` object is deployed and has the condition `Programmed` by running the following command:
+
[source,terminal]
----
$ oc wait -n openshift-ingress --for=condition=Programmed gateways.gateway.networking.k8s.io example-gateway
----
+
.Example output
[source,terminal]
----
gateway.gateway.networking.k8s.io/example-gateway condition met
----

. Send a request to the configured `HTTPRoute` object hostname:
+
[source,terminal]
----
$ curl -I -cacert <local cert file> https://example.gwapi.${DOMAIN}:443
----
4 changes: 2 additions & 2 deletions modules/nw-ingress-gateway-api-implementation.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@

The Ingress Operator manages the lifecycle of Gateway API CRDs in a way that enables other vendor implementations to make use of CRDs defined in an {product-title} cluster.

In some situations, the Gateway API provides one or more fields that a vendor implementation does not support, but that implementation is otherwise compatible in schema with the rest of the fields. These "dead fields" can result in disrupted Ingress workloads, improperly provisioned applications and services, and security related issues. Because {product-title} uses a specific version of Gateway API CRDs, any use of third-party implementations of Gateway API must conform to the {product-title} implementation to ensure that all fields work as expected.
In some situations, Gateway API provides one or more fields that a vendor implementation does not support, but that implementation is otherwise compatible in schema with the rest of the fields. These "dead fields" can result in disrupted Ingress workloads, improperly provisioned applications and services, and security related issues. Because {product-title} uses a specific version of Gateway API CRDs, any use of third-party implementations of Gateway API must conform to the {product-title} implementation to ensure that all fields work as expected.

Any CRDs created within an {product-title} {product-version} cluster are compatibly versioned and maintained by the Ingress Operator. If CRDs are already present but were not previously managed by the Ingress Operator, the Ingress Operator checks whether these configurations are compatible with the Gateway API version supported by {product-title}, and creates an admin-gate that requires your acknowledgment of CRD succession.
Any CRDs created within an {product-title} {product-version} cluster are compatibly versioned and maintained by the Ingress Operator. If CRDs are already present but were not previously managed by the Ingress Operator, the Ingress Operator checks whether these configurations are compatible with Gateway API version supported by {product-title}, and creates an admin-gate that requires your acknowledgment of CRD succession.

[IMPORTANT]
====
Expand Down
18 changes: 9 additions & 9 deletions modules/nw-ingress-gateway-api-overview.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,33 +4,33 @@

:_mod-docs-content-type: CONCEPT
[id="nw-ingress-gateway-api-overview_{context}"]
= Overview of the Gateway API
= Overview of Gateway API

The Gateway API is an open source, community-managed, Kubernetes networking mechanism. It focuses on routing within the transport layer, L4, and the application layer, L7, for clusters. A variety of vendors offer many link:https://gateway-api.sigs.k8s.io/implementations/[implementations of Gateway API].
Gateway API is an open source, community-managed, Kubernetes networking mechanism. It focuses on routing within the transport layer, L4, and the application layer, L7, for clusters. A variety of vendors offer many link:https://gateway-api.sigs.k8s.io/implementations/[implementations of Gateway API].

The project is an effort to provide a standardized ecosystem by using a portable API with broad community support. By integrating Gateway API functionality into the Ingress Operator, it enables a networking solution that aligns with existing community and upstream development efforts.

The Gateway API extends the functionality of the Ingress Operator to handle more granular cluster traffic and routing configurations. With these capabilities, you can create instances of Gateway APIs custom resource definitions (CRDs). For {product-title} clusters, the Ingress Operator creates the following resources:
Gateway API extends the functionality of the Ingress Operator to handle more granular cluster traffic and routing configurations. With these capabilities, you can create instances of Gateway APIs custom resource definitions (CRDs). For {product-title} clusters, the Ingress Operator creates the following resources:

Gateway:: This resource describes how traffic can be translated to services within the cluster. For example, a specific load balancer configuration.
GatewayClass:: This resource defines a set of `Gateway` objects that share a common configuration and behavior. For example, two separate `GatewayClass` objects might be created to distinguish a set of `Gateway` resources used for public or private applications.
HTTPRoute:: This resource specifies the routing behavior of HTTP requests from a Gateway to a service, and is especially useful for multiplexing HTTP or terminated HTTPS connections.
GRPCRoute:: This resource specifies the routing behavior of gRPC requests.
ReferenceGrant:: This resource enables cross-namespace references. For example, it enables routes to forward traffic to backends that are in a different namespace.

In {product-title}, the implementation of the Gateway API is based on `gateway.networking.k8s.io/v1`, and all fields in this version are supported.
In {product-title}, the implementation of Gateway API is based on `gateway.networking.k8s.io/v1`, and all fields in this version are supported.

[id="gateway-api-benefits_{context}"]
== Benefits of the Gateway API
The Gateway API provides the following benefits:
== Benefits of Gateway API
Gateway API provides the following benefits:

* Portability: While {product-title} uses HAProxy to improve Ingress performance, Gateway API does not rely on vendor-specific annotations to provide certain behavior. To get comparable performance as HAProxy, the `Gateway` objects need to be horizontally scaled or their associated nodes need to be vertically scaled.
* Separation of concerns: Gateway API uses a role-based approach to its resources, and more neatly fits into how a large organization structures its responsibilities and teams. Platform engineers might focus on `GatewayClass` resources, cluster admins might focus on configuring `Gateway` resources, and application developers might focus on routing their services with `HTTPRoute` resources.
* Extensibility: Additional functionality is developed as a standardized CRD.

[id="gateway-api-limitations_{context}"]
== Limitations of the Gateway API
The Gateway API has the following limitations:
== Limitations of Gateway API
Gateway API has the following limitations:

* Version incompatibilites: The Gateway API ecosystem changes rapidly, and some implementations do not work with others because their featureset is based on differing versions of Gateway API.
* Version incompatibilites: Gateway API ecosystem changes rapidly, and some implementations do not work with others because their featureset is based on differing versions of Gateway API.
* Resource overhead: While more flexible, Gateway API uses multiple resource types to achieve an outcome. For smaller applications, the simplicity of traditional Ingress might be a better fit.
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,8 @@ include::modules/nw-ingress-gateway-api-overview.adoc[leveloffset=+1]

include::modules/nw-ingress-gateway-api-implementation.adoc[leveloffset=+1]

include::modules/nw-ingress-gateway-api-enable.adoc[leveloffset=+1]

include::modules/nw-ingress-gateway-api-deployment-topologies.adoc[leveloffset=+1]

.Additional resources
Expand Down