Overview

Gateway API is the next generation of the Ingress API in upstream Kubernetes.

OpenShift Service Mesh (OSSM) and several other offering of ours like Kuadrant, Microshift and OpenShift AI all have critical dependencies on Gateway API's API resources. However, even though Gateway API is an official Kubernetes project its API resources are not available in the core API (like Ingress) and instead require the installation of Custom Resource Definitions (CRDs).

At present projects that are dependent on Gateway API provide some DIY mechanism for deploying the CRDs and therefore the deployment and life-cycle responsibilities for these CRDs end up pinned on the cluster operator. This is extremely problematic as all these different solutions (shown above, but also partner and vendor solutions) have a critical dependency on the CRDs, and these APIs are intended for use by end-users.

Note: The lack of guidance and tooling for "official CRDs" stems from upstream Kubernetes (particularly, SIG Network) recommending CRDs as the path for most new networking functionality, but not having made that a 1st class experience before hand. We are working on improving this in upstream as a separate work effort.

The purpose of this task is to provide full life-cycle management of the Gateway API CRDs. This should include a spike to enumerate all the problems that can arise and determine the best solution (which needs to coordinated with other teams).

Acceptance Criteria

• Gateway API CRDs should be deployed at the install-time of a cluster
• Changes to these CRDs (upgrades, e.t.c.) should be managed at the platform level, and not directly by users via the Kubernetes API
• Minimum and maximum version compatibility of Gateway API CRDs should be documented and enforced
  • Partner and 3rd party solutions which provide Gateway API support must have integrator documentation detailing how they can utilize Gateway API on any particular version of OpenShift.
• Existing clusters where Gateway API CRDs have already been manually deployed need a documented migration path
  • For clusters which have previously deployed Gateway API CRDs a "degraded" mode of some sort needs to exist to indicate a need for manual conflict management before full functionality will be available.
  • We may need to provide some sort of "degraded mode" for CIO to indicate to users that they wont be able to use all capabilities (e.g. Gateway API with OSSM) while they are managing the CRDs

Cross-Team Coordination

The organization as a whole needs to be made aware of this as new projects will continue to pop up with Gateway API support over the years. In the immediate we need this task to be collaborate with:

• OSSM Team
• Kuadrant Team
• MicroShift Team
• OpenShift AI Team

So that we can make sure the solution we come up with serves everyone.

Importantly our cluster infrastructure work with Cluster API (CAPI) is working through similar dilemmas for CAPI CRDs, and so we need to make sure to work directly with them as they've already broken a lot of ground here. Here are the relevant docs with the work they've done so far:

• lifecycling-cluster-api-crds-within-openshift - HackMD
• OCPCLOUD-2114 Investigate lifecycle of Cluster API APIs within OpenShift