Conversation
amuraru
force-pushed
the
istio
branch
3 times, most recently
from
September 27, 2025 09:37
0b05088 to
e520182
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
amuraru
force-pushed
the
istio
branch
2 times, most recently
from
September 27, 2025 16:38
ad885c0 to
11ccd59
Compare
amuraru
changed the title
amuraru
marked this pull request as draft
September 28, 2025 10:39
amuraru
force-pushed
the
master
branch
3 times, most recently
from
September 29, 2025 07:02
04d55a5 to
432ff85
Compare
amuraru
force-pushed
the
master
branch
2 times, most recently
from
September 29, 2025 11:00
939d351 to
b1caf52
Compare
amuraru
force-pushed
the
istio
branch
14 times, most recently
from
October 3, 2025 18:26
4c7d095 to
1fa2195
Compare
amuraru
force-pushed
the
istio
branch
8 times, most recently
from
November 4, 2025 06:03
b5fd1af to
ba9ea8f
Compare
amuraru
changed the title
amuraru
force-pushed
the
istio
branch
3 times, most recently
from
November 4, 2025 14:06
bb3e82c to
f17e79e
Compare
amuraru
marked this pull request as ready for review
November 4, 2025 14:28
amuraru
force-pushed
the
istio
branch
6 times, most recently
from
November 7, 2025 19:39
c7133f0 to
99522b7
Compare
|
@amuraru i think we have enough ingress methods: envoy and contour. EnvoyGateway is just another envoy based ingress that adds the same external CRD dependency like the Contour one. Is there a specific request for this ingress method? |
Author
|
that's a fair feedback @dobrerazvan - I don't have an immediate usecase for this new ingress type - it was me researching a replacement for the old istio ingress (which was removed as it's not maintained anymore). We can keep the PR open and revisit if the need from us or the community arisees. |
…steners Adds a new "envoygateway" ingress controller for exposing Kafka external listeners, built on the Kubernetes Gateway API (https://gateway.envoyproxy.io/). Enable it per external listener with `spec.ingressController: envoygateway` and configure it via the new `envoyGatewayConfig` field. The `ingressController` enum is now `envoy;contour;envoygateway`. The previous istio-based ingress relied on banzaicloud/istio-operator, which is EOL/unmaintained (already removed on master); Envoy Gateway is a CNCF-backed, actively maintained Gateway API implementation. Changes: - New envoygateway resource reconciler (pkg/resources/envoygateway): generates Gateway + TCPRoute, with optional TLS. - New EnvoyGatewayIngressConfig API type + `ingressController: envoygateway`. - Refactor external listener status handling into a per-listener dispatcher (createListenerStatuses) so ingress types plug in cleanly. - Sample manifests for ZooKeeper and KRaft modes. - Additional unit tests (envoy resource, k8sutil, nodeport external access) and e2e coverage (install/produce/consume/uninstall with Envoy Gateway ingress in both ZooKeeper and KRaft modes, Envoy Gateway Helm chart v1.5.4). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
testInstallKafkaCluster no longer exists after test_install_cluster.go was renamed to test_install_kafka_cluster.go; this call site was missed.
testInstallNoIngressKafkaCluster, testInstallEnvoyKafkaCluster, and testInstallEnvoyGatewayKafkaCluster were byte-identical bodies; the ingress type is already encoded in the manifest path, not the Go code, so the split added no behavior and let one call site drift out of sync (the 5-broker bug). Collapsed into testInstallKafkaCluster and reverted the file rename from test_install_cluster.go.
simplekafkacluster_with_envoy.yaml, simplekafkacluster_with_envoygateway.yaml, and their kraft counterparts were added without the CC warmup tuning that b7be337 (#291) applied to the other e2e-exercised samples (15s sampling, shrunk metric/sample-store windows, min.valid.partition.ratio, etc), so they carried the old flaky defaults. Brought all 4 in line with the reference samples, verified word-for-word identical against the fixed simplekafkacluster.yaml/simplekafkacluster_kraft.yaml.
cloud-provider-kind installs the standard-channel Gateway API CRDs by default (gateway-channel=standard). Those collide via server-side-apply with the CRDs Envoy Gateway's Helm chart installs in the same cluster (different field manager, differing bundle-version/channel annotations and .spec.versions), failing "helm install eg oci://.../gateway-helm" with an SSA conflict during the e2e "Installing infrastructure components in parallel" step. cloud-provider-kind is only needed here for LoadBalancer Service IP allocation, not its own Gateway controller.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a new Envoy Gateway ingress controller for exposing Kafka external
listeners, built on the Kubernetes Gateway API (https://gateway.envoyproxy.io/).
Enable it per external listener with
spec.ingressController: envoygatewayandconfigure it via the new
envoyGatewayConfigfield. TheingressControllerenum is now
envoy;contour;envoygateway.Why
The previous istio-based ingress relied on
banzaicloud/istio-operator, which isEOL/unmaintained (already removed on master). Envoy Gateway is a CNCF-backed,
actively maintained Gateway API implementation.
Changes
envoygatewayresource reconciler (pkg/resources/envoygateway):generates Gateway + TCPRoute, with optional TLS.
EnvoyGatewayIngressConfigAPI type +ingressController: envoygateway.Testing
webhook port-collision validation.
ingress in both ZooKeeper and KRaft modes (Envoy Gateway Helm chart v1.5.4).