Jakub Warczarek

Spin-off issue - https://github.com/Kong/kubernetes-ingress-controller/issues/6749 has been created to cover stuff discovered during work on this. They're not spamming with redundant error logs thus it's not in the scope of this

/remove-lifecycle rotten

I'm in favor of changing the behavior to fulfill what OP described, because - CoreDNS that is popular does it - [GKE Autopilot](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview) uses [Cloud DNS](https://cloud.google.com/kubernetes-engine/docs/concepts/service-discovery#cloud_dns) which also behaves the...

I made tests and support for the availability of DNS resolution like e.g. `10-96-2-4.example-service.default.svc` for `Pod`s exposed by a `Service` depends on a DNS provider and it looks like that...

Probably the best approach for such CLI would be a [Kubernetes plugin](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) installed with [krew](https://krew.sigs.k8s.io/). For instance, [Datadog](https://github.com/DataDog/datadog-operator) and [Cillium](https://github.com/bmcustodio/kubectl-cilium) have such ones.

There is a Kong-wide command-line tool [kongctl](https://github.com/Kong/kongctl)

First of all, supporting WebSockets is an Enterprise feature. Could you let me know if you're using an Enterprise Kong Gateway with a valid license? Otherwise, it won't work. Also...

FYI @konsti the next release v3.4 will contain the fix

Thanks for the detailed info @tporeba I'll take a close look this week, and I'll update you

Now it's resolved 100%, see https://github.com/Kong/kubernetes-ingress-controller/pull/6781, thanks for cooperation @tporeba 🎉