CRD Lifecycle Management

[robscott]

As the project has reached GA, we've started to get some questions about if cluster provisioning tools and providers should start including Gateway API CRDs. As a project, we need to develop some guidelines for this approach. Note that even if we suggest that cluster provisioning tools include Gateway API CRDs, that will never be the exclusive way for these CRDs to be managed. I'll add my own proposal below to avoid confusing the overall topic with my opinion.

[robscott]

I think that it would be beneficial for cluster provisioning tools and providers to include optional Gateway API CRD management with the following guidelines:

• Only standard channel CRDs should be installed
• The latest version of standard channel CRDs should be included as soon as they are available and rolled out to all Kubernetes versions supported by Gateway API
• This automation layer should never uninstall CRDs

One of the major pain points in adopting Gateway API is CRD management. I think that providing more managed options will help with this. Of course we need to be clear that this will never be the only way to install Gateway API, and that experimentation in non-prod environments with Experimental Channel CRDs is very much encouraged.

From the perspective of cluster provisioning tools and providers, this would mean that several times a year (3-6), they would need to pick up the latest Gateway API CRD definitions and make the latest version available via upgrade.

[tao12345666333]

Since CRD is cluster-level, does this mean that the Gateway API also needs to have periodic releases similar to Kubernetes?

In addition, do we need to provide tools like conftest to assist users in CRD upgrades? (Check whether some changed fields are used in the cluster, and prompt the user whether it can be safely upgraded.

[robscott]

Although we are trying to work towards a more predictable release cadence, that does not need to be aligned with Kubernetes. An important goal of Gateway API is that each release will be compatible with the 5 most recent Kubernetes minor versions. When combined with a recommendation of only automating the installation of "standard channel" (GA) CRDs, this would mean that each new set of CRDs in a standard channel release would also come with stringent backwards compatibility guarantees and the same API version (v1). I believe that means a tool like conftest would not be necessary.

Adding all of that up, the goal is for everyone to be able to safely install the latest version of standard channel Gateway API CRDs as soon as they're released, as long as they're running on one of the 5 most recent versions of Kubernetes.

[Rycieos]

Maybe this is a naive approach, but what if functionality was added to Kubernetes where CRD based APIs could be managed by a resource. For example:

apiVersion: extensions.k8s.io/v1
kind: CrdExtension
metadata:
  name: gateway-api
spec:
  source: https://github.com/kubernetes-sigs/gateway-api
  channel: experimental
  version: v1.0.0

Then the api server would handle installing the CRDs, and if needed, updating them.

Getting this merged into the api server would probably be difficult, so maybe it would need to be an extension server that managed Kubernetes providers would need to offer.