envoyproxy / gateway

Manages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway
https://gateway.envoyproxy.io
Apache License 2.0
1.44k stars 294 forks source link

make experimental gateway api crds optional so that gateway-api upgrade don't break envoy gateway #3387

Open networkhermit opened 1 month ago

networkhermit commented 1 month ago

Description:

What issue is being seen? Describe what should be happening instead of the bug, for example: Envoy should not crash, the expected value isn't returned, etc.

Recently I upgraded the gateway-api to v1.1.0 from the standard channel, but I found that envoy-gateway is in error due to missing some experimental gateway api crds, even though I have not directly used GRPCRoute gateway.networking.k8s.io/v1alpha2 at all.

Make these experimental crds optional could help users to upgrade newer gateway-api releases.

envoy-gateway log:

Error: failed to create provider Kubernetes: failted to create gatewayapi controller: no matches for kind "GRPCRoute" in version "gateway.networking.k
8s.io/v1alpha2"
Usage:
  envoy-gateway server [flags]

Aliases:
  server, serve

Flags:
  -c, --config-path string   The path to the configuration file.
  -h, --help                 help for server

failed to create provider Kubernetes: failted to create gatewayapi controller: no matches for kind "GRPCRoute" in version "gateway.networking.k8s.io/v
1alpha2"

More context: https://github.com/kubernetes-sigs/gateway-api/issues/3075 and the way istio handle it.

Repro steps:

Include sample requests, environment, etc. All data and inputs required to reproduce the bug.

Note: If there are privacy concerns, sanitize the data prior to sharing.

Environment:

Include the environment like gateway version, envoy version and so on.

Logs:

Include the access logs and the Envoy logs.

arkodg commented 1 month ago

we've implemented something similar for ServiceImport where we check if it exists before watching it. For this case we are not the CRD owners, so this decision was easy https://github.com/envoyproxy/gateway/blob/3bc7cf1d00635f602bc4731a904675d982d34317/internal/provider/kubernetes/controller.go#L1099

Do we need to the same for

  1. Gateway API CRDs - that are not installed from the EG Helm Chart, but pre-applied and managed by the cluster admin (e.g. GKE) (helm not updating CRDs just highlights this case even more )
  2. EG CRDs (BackendTrafficPolicy etc) - that are not installed in the cluster, where the user wants to run EG in minimal mode (Gateway API featureset) and pre install the Gateway API CRDs from the standard channel themselves.

cc @envoyproxy/gateway-maintainers

nezdolik commented 3 weeks ago

+1 on the issue