Add Istio Gateway/VirtualService support as alternative to nginx Ingress #9167
Replies: 4 comments 5 replies
-
Beta Was this translation helpful? Give feedback.
-
|
Is there a Kiali issue created/assigned and a discussion had before PRs submitted? Please see community contribution page : https://github.com/kiali/kiali/blob/master/CONTRIBUTING.md#making-a-change |
Beta Was this translation helpful? Give feedback.
-
In my humble opinion, it's not an Issue, so I opened this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
This is not a helm chart only enhancement - the subject line is inaccurate. This will involve the operator, too. The operator must have feature parity with the server helm chart. |
Beta Was this translation helpful? Give feedback.
-
|
Apologise for the inaccuracy |
Beta Was this translation helpful? Give feedback.
-
|
I didn't realize the community process only involves creating a discussion. However, once PRs are submitted, they should have an issue associated with it. We'll create the issue after we get the feature enhancement defined. I'll take a look closer later today. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to first point out that the Kiali project long ago came to the conclusion that attempting to provide specific ingress config for specific ingress controllers is a difficult, if not impossible, thing to do, at least easily for users to grok. Hence the reason for the documentation that says, "Because an Ingress into a cluster can vary wildly in its desired configuration ..." We tried to make things open-ended and not require specific implementations of the ingress (as best that could be). This current new proposal is now asking to creating yet ANOTHER set of config settings in the Kiali CR and a second, separate one involving ingress. This involves additional complexity to the config that makes it even more difficult for users to understand, more complexity in the helm/operator implementation, and more complicated documentation that will be required. If we want to introduce yet another way to configure ingress (and right now I am not convinced we want to), we already have "spec.deployment.ingress" so we should first attempt to extend that. So think about re-using/extending the existing ingress section of the config: https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.deployment.ingress |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the detailed feedback. I understand the concerns about configuration complexity and the challenges of supporting various ingress controllers. I'd like to highlight a few points in favor of the Istio Gateway approach: Cost efficiency at scale In environments with many infrastructure services (Kiali, Prometheus, Grafana, Jaeger, etc.), each Ingress resource with an ALB controller (in case if we just replace nginx with ALB) creates a separate AWS ALB (~$20-30/month each). With Istio Gateway, all services share a single load balancer, significantly reducing infrastructure costs. Consistency with existing patterns Organizations already using Istio for service mesh typically route all traffic through a shared Gateway. Adding a separate Ingress for Kiali breaks this pattern and creates an inconsistent traffic flow. Not a replacement, but an option I'm not proposing to replace the existing spec.deployment.ingress configuration. The idea is to add an optional alternative alongside it. Users who prefer the current Ingress approach would continue using it unchanged. Those who want Istio-native routing would have that option available. |
Beta Was this translation helpful? Give feedback.
-
|
For some history behind my hesitancy, years ago we tried to have a nice "ingress" feature where the Kiali Operator would create a Ingress object for users to use to easily gain access to Kiali without having to configure the ingress themselves. However, it ended up that people would complain the yaml it produced wasn't "exactly" what they wanted and it didn't fit in with their network requirements (this new enhancement request is just one more in the line of complaints that the Kiali ingress install feature isn't giving them what they want :-) We considered just getting rid of the ingress feature entirely because of the difficulty of creating an ingress in a way that would be satisfactory for all possible network configs, but eventually compromised and said, "The Kiali Operator can create one, but you can provide your own yaml in the override section so you can fully customize it to your liking". As for this current request, I'm of the opinion users should create their own Istio gateways along with the rest of their Istio mesh components using their own currently-existing Istio mesh installation mechanisms. Having the Kiali Operator (or Kiali server helm chart) create Istio mesh components that are managed by Kiali (thus separately and independently from the user's own Istio mesh installation and all the CI/validation/security they may have surrounding their own Istio install mechanisms) seems to be the wrong approach. In the past, we have purposefully avoided the Kiali install mechanism from creating any Istio-specific resource. If the community wants this feature, then we should try to extend the existing spec.deployment.ingress feature to include installing Istio's own gateways. I don't know how at the moment, I haven't thought about it. Maybe something like: ingress:
additional_labels: ... same as before...
class_name: "istio-gateway" <<<---- HAVE SOME KIND OF SPECIAL KEY HERE TO DENOTE "install a Istio gateway"
enabled: ...same as before...
override_yaml:
metadata:
annotations: ... applies to the created istio gateway resource...
spec:
... custom Istio gateway spec ....The Kiali Operator and the Kiali server helm chart could key off of "spec.deployment.ingress.class_name" and if it is a special value like "istio-gateway" that will tell it to create a Gateway and not an Ingress (or Route if on OpenShift). I'm not crazy about that idea either, but it's better than creating a SECOND ingress configuration section (when I think we really want Kiali to go down to having 0 :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
Add native Istio Gateway/VirtualService support to the kiali-server helm chart as an alternative to the current nginx Ingress.
Motivation
The Kubernetes SIG Network and Security Response Committee have announced the retirement of Ingress NGINX:
Given that Kiali is primarily used in Istio service mesh environments, it makes sense to provide native Istio ingress support via VirtualService. This allows users to:
Proposed Changes
Add
istioGatewaysection tokiali-server/values.yaml:When enabled, create a VirtualService resource that routes traffic to the Kiali service.
Beta Was this translation helpful? Give feedback.
All reactions