1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/nw-ingress-gateway-api-implementation.adoc

21 lines
1.8 KiB
Plaintext

// Modules included in the following assemblies:
//
// * networking/gateway-api.adoc
:_mod-docs-content-type: CONCEPT
[id="nw-ingress-gateway-api-implementation_{context}"]
= Gateway API implementation for {product-title}
[role="_abstract"]
To ensure interoperability between external vendor implementations and your networking infrastructure in {product-title}, use the Ingress Operator to manage the lifecycle of Gateway API custom resource definitions (CRDs).
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 Gateway API version supported by {product-title}, and creates an admin-gate that requires your acknowledgment of CRD succession.
[IMPORTANT]
====
If you are updating your cluster from a previous {product-title} version that contains Gateway API CRDs change those resources so that they exactly match the version supported by {product-title}. Otherwise, you cannot update your cluster because those CRDs were not managed by {product-title}, and could contain functionality that is unsupported by Red{nbsp}Hat.
====