Conversation
Previously ingress was required to use Kiali. With this change it is possible to use kiali using ingressgateway as per other telemetry-gateway behavior. I recognize this isn't the perfect organization - will get there over time with multiple PRs.
|
/assign @gyliu513 |
|
/assign @GregHanson |
| targetPort: 8060 | ||
| name: tcp-citadel-grpc-tls | ||
| # Addon ports for kiali are enabled in gateway - but will only redirect if | ||
| # the gateway focnfiguration for the various components are enabled. |
There was a problem hiding this comment.
s/focnfiguration/configuration
| namespace: {{ .Release.Namespace }} | ||
| spec: | ||
| selector: | ||
| istio: {{ .Values.gatewayName }} |
There was a problem hiding this comment.
It's not required that the selector be istio: <name>, it could be arbitrary labels. We should change values.yaml to take selector, and provide default value istio: ingressgateway.
There was a problem hiding this comment.
I prefer that we hardcode the selector here as istio: ingressgateway. As we can see the default ingress gateway in istio only has two labels as below:
labels:
app: istio-ingressgateway
istio: ingressgateway
If we allow end user to set arbitrary labels in values.yaml, the Gateway may not work if it cannot select an ingress gateway via the selector.
There was a problem hiding this comment.
@gyliu513 sure I can hardcode the selector and agree it would be better to do so. Less chance for an operator to crater their install. I'm not sure why @douglas-reid chose to make this configurable. Will remove that configurability across the install codebase in a followup PR.
There was a problem hiding this comment.
@ZackButcher sure - makes sense. I do agree with @gyliu513 's position that we should simplify this part by hardcoding. I don't see any good reason to make the selector here configurable given the nature of exposing services via ingressgateway. This saves on the expense of introducing another LoadBalancer service type, and the logistics of managing that IP.
There was a problem hiding this comment.
@sdake @ZackButcher It is configurable because that was what was asked for. At the time of the PR, the feeling was that while some deployments would want to expose it via "ingressgateway" others may only have wanted to make it exposed via "ilbgateway" or whatever. This was an explicit part of the negotiations around the telemetry-gateway PR. I don't think we should hard-code it. I'm fine with having the selector itself be part of the configuration, however.
Codecov Report
@@ Coverage Diff @@
## master #8971 +/- ##
=======================================
+ Coverage 69% 70% +1%
=======================================
Files 418 418
Lines 38551 38149 -402
=======================================
- Hits 26587 26448 -139
+ Misses 10715 10475 -240
+ Partials 1249 1226 -23
Continue to review full report at Codecov.
|
| replicaCount: 1 | ||
| hub: docker.io/kiali | ||
| tag: v0.6 | ||
| gatewayName: ingressgateway |
There was a problem hiding this comment.
Do we still need this variable in values.yaml?
| host: kiali.{{ .Release.Namespace }}.svc.cluster.local | ||
| port: | ||
| number: 20001 | ||
| --- |
There was a problem hiding this comment.
we need --- in the end of file?
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gyliu513 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…8971) * Make trace pod annotation warning more visible. * Update content/en/docs/tasks/observability/distributed-tracing/configurability/index.md Co-authored-by: Eric Van Norman <ericvn@us.ibm.com> Co-authored-by: Pengyuan Bian <bianpengyuan@google.com> Co-authored-by: Eric Van Norman <ericvn@us.ibm.com>
Previously ingress was required to use Kiali. With this change
it is possible to use kiali using ingressgateway as per other
telemetry-gateway behavior.
I recognize this isn't the perfect organization - will get there
over time with multiple PRs.