-
Story
-
Resolution: Unresolved
-
Blocker
-
None
-
None
-
None
-
BU Product Work
-
False
-
None
-
True
-
OCPSTRAT-134 - Gateway API using Istio for Cluster Ingress - GA
-
-
-
NI&D Sprint 268
-
0
-
0
What?
On OCP 4.19 onward we will ensure the Gateway API CRDs are present a specific version with its own feature gate which will default to true. If we can not ensure the CRDs are present at the expected version we will mark the cluster degraded.
Why?
See the description of NE-1898.
How?
The Cluster Ingress Operator (CIO) currently provides some logic around handling the Gateway API CRDs, and a chunk of this work is simply updating that. The CIO should:
- deploy the CRDs with the current expected version
- at the time of writing this is v1.2.1, but is subject to change
- upgrade any present CRDs with the current expected version
- similar to NE-1952 ensure that ONLY the exact CRDs we expect are present:
- this means only GatewayClass, Gateway, HTTPRoute and Reference grant (and not older versions of them)
- if the wrong CRDs versions are present the CIO overwrites them to the correct version
- if unexpected CRDs become present (e.g. TCPRoute) the CIO deletes them
- for any of the above situations to occur, something has to be very broken (e.g. cluster admin destroyed the VAP). Provide an appropriate alert when these situations are encountered.
- similar to NE-1952 ensure that ONLY the exact CRDs we expect are present:
- Make the ControllerName for GatewayClass include a /v1 version suffix to indicate which implementation is provided (i.e. for now, OSSM)
- this opens up the door for DP, TP and potentially eventual GA releases of alternative Gateway API implementations other than OSSM, which can then be enabled via a new GatewayClass
Helpful Links
See some of the current CRD management logic here.
- clones
-
NE-1954 Implement GatewayAPI Controller featuregate
-
- Closed
-