Breaking change introduced: Gateway API CRD installation fails on Kubernetes v1.30 with CEL rule isIP (cloud-provider-kind fails to start)

[anshulkumar-tmf]

We are encountering a failure when running cloud-provider-kind on a Kind cluster using Kubernetes v1.30.0.

During startup, cloud-provider-kind attempts to install Gateway API CRDs from the standard channel. However, installation fails when creating the CRD:

tlsroutes.gateway.networking.k8s.io

The failure is caused by a CEL validation rule referencing isIP, which the Kubernetes API server rejects.

As a result:
• cloud-provider-kind exits during startup
• the LoadBalancer controller never starts
• LoadBalancer services in the cluster never receive an external IP

This effectively breaks CI environments that rely on cloud-provider-kind to provide LoadBalancer functionality in Kind clusters.

Error Logs

`Failed to install Gateway API CRDs

error processing embedded CRDs from crds/standard: failed to create CRD "tlsroutes.gateway.networking.k8s.io"

CustomResourceDefinition.apiextensions.k8s.io "tlsroutes.gateway.networking.k8s.io" is invalid:

spec.versions[0].schema.openAPIV3Schema.properties[spec].properties[hostnames].x-kubernetes-validations[0].rule:
Invalid value: apiextensions.ValidationRule{Rule:"self.all(h, !isIP(h))"}

compilation failed: ERROR: :1:18: undeclared reference to 'isIP'
| self.all(h, !isIP(h))
| .................^`

After this error:

Failed to start cloud controller Unable to sync caches Shutting down service controller

Environment

Kind cluster:
kind v0.xx.x
node image: kindest/node:v1.30.0

Kubernetes:
Client Version: v1.30.0
Server Version: v1.30.0

cloud-provider-kind:
built from repository (main branch)

Workaround

Running cloud-provider-kind with Gateway API disabled works:
bin/cloud-provider-kind --gateway-channel=disabled

[BenTheElder]

We are encountering a failure when running cloud-provider-kind on a Kind cluster using Kubernetes v1.30.0.

node image: kindest/node:v1.30.0

Unless that is a custom built image, please see:
https://kind.sigs.k8s.io/docs/user/quick-start/#:~:text=This%20will%20bootstrap,a%20kind%20release.

https://github.com/kubernetes-sigs/kind/releases/tag/v0.31.0#:~:text=NOTE%3A%20You%20must%20use%20the%20%40sha256%20digest%20to%20guarantee%20an%20image%20built%20for%20this%20release%2C%20until%20such%20a%20time%20as%20we%20switch%20to%20a%20different%20tagging%20scheme.%20Even%20then%20we%20will%20highly%20encourage%20digest%20pinning%20for%20security%20and%20reproducibility%20reasons.

1.30.0 would be a super old image from https://github.com/kubernetes-sigs/kind/releases/tag/v0.23.0, and in no way guaranteed to work with current tooling, every release's release note for many years now has had a clear warning about this.

kind v0.29.0 was the last release with a prebuilt v1.30 image, which was kindest/node:v1.30.13@sha256:397209b3d947d154f6641f2d0ce8d473732bd91c87d9575ade99049aa33cd648
kind v0.31.0 is current, but it only ships pre-built images back to 1.31

Further, the Kubernetes project only supports 1.33+ currently: https://kubernetes.io/releases/
Though kind offers limited support for older releases where possible.

EDIT: you can build your own images, but usually people would give them a name other than kindest/node, see: https://kind.sigs.k8s.io/docs/user/quick-start/#building-images
but again, keep in mind that support for releases kubernetes itself doesn't support is best-effort and cannot realistically be guaranteed, as an upstream project we have no way to patch EOL releases

[aojea]

or just disable gateway in cloud provider kind, we have a flag for that