With Ingress NGINX retiring in March 2026(Ingress NGINX Retirement: What You Need to Know | Kubernetes), we’re evaluating alternatives like Istio with Envoy, but Starburst doesn’t support service mesh which we heard from the customer succes team of starburst and thier partners like kubrics team. Starburst advises not use service mesh (istio/openmesh) against them due to slowness in query performance, yet as an enterprise platform, this limits adoption in orgs requiring standardized meshes for security/observability. Why no Istio support for starburst ? Can’t we use Envoy without full Istio? Any benchmarks or workarounds for Kubernetes deployments?
@lester any thoughts here?
We’re running Starburst Enterprise Platform (SEP) on AKS and actively planning for the Ingress NGINX retirement (announced Nov 2025, EOL March 2026). While your docs still reference NGINX Ingress examples (e.g., kubernetes.io/ingress.class: "nginx" for web UI exposure), no public updates address deprecation, migration paths, or Helm chart changes.
We are exploring to follow the below mentioned approach and would like to understand if there are any recommendations from the Starburst official team. We couldn’t find documentation or reference architectures covering this scenario, so any guidance from Starburst would help us align with supported best practices
-
Phase 1: Exit Ingress NGINX safely before EOL via interim alternatives
-
Phase 2: Evaluate/timeline migration to Gateway API (not immediate—requires enterprise validation for stability, tooling, policy integration).
Gateway API is promising but too nascent for direct adoption for us.
Hey @Thara, I chatted with a few folks on this and ultimately it seems that options (such as Gateway API) do exist for you to choose from and we aren’t currently pushing one or another.
The best answer I can offer is below and was taken directly from the Ingress NGINX Retirement: What You Need to Know | Kubernetes write-up…
" SIG Network and the Security Response Committee recommend that all Ingress NGINX users begin migration to Gateway API or another Ingress controller immediately. Many options are listed in the Kubernetes documentation: Gateway API, Ingress. Additional options may be available from vendors you work with."