kiali/kiali

Kiali project, observability for the Istio service mesh

kiali's Issues

Indication for the status of Kiali in the masthead

more details and proposals here:
https://issues.jboss.org/browse/KIALI-1118

Service "box" is not shown correctly

I have deployed https://github.com/redhat-developer-demos/istio-tutorial with istio 0.7.1.

Deploy all servies - customer, preference, recommendation - in both versions. Do not create requests to customer! Go to kiali console to show the service graph. The box for the recommendation service is not shown correctly.

If you fail to reproduce, try to remove p8s pod and go to Kiali UI. The error should be present.

cluster-openshift.sh should default to "darwin" for Mac users

The hack script https://github.com/kiali/kiali/blob/master/hack/cluster-openshift.sh assumes you want the Linux binary of istiooc. See: https://github.com/kiali/kiali/blob/master/hack/cluster-openshift.sh#L176

Mac users are required to override this by always passing in the --istiooc-platform darwin command line option.

Would be nice for Mac users to have cluster-openshift.sh default to darwin without requiring them to explicitly declare that option.

KIALI-1065 Redesign the link to view yaml and the main entities display as a table

There is an issue describing that the link to edit the yaml is not clear what it will do: https://issues.jboss.org/browse/KIALI-731

And also a lot of discussion in the PR over what change should be done (if any) here: kiali/kiali-ui#417

It comes down to the link in the screenshot below and if its clear that clicking this link will take you to the yaml view:

Should we have something to indicate that this takes you to a yaml view? or is the link enough (with perhaps some hover tooltip to let you know what it is).

I would say go the OpenShift way of doing things, but even OpenShift doesn't provide this functionality (you can click on an 'action' button to edit the yaml, but there is no view option in OpenShift)

Feature request: Kiali logo

Kiali deserves a logo!

Node Health versus Selected Node Indication

This is an issue for the longer-term issue of how to visualize Node Health versus showing the selected node (right now a light blue). Which trumps which? Can we come up with a way to easily show both without confusion?

The issue that started this is:

• no way to distinguish selected or unselected nodes with health warnings: https://issues.jboss.org/browse/KIALI-1000

• We proceeded with a temporary solution: kiali/kiali-ui#465

How to configure kiali-ui for the isio installed by minikube?

How to configure kiali-ui for the isio installed by minikube?

UI: Keep selection of namespaces active

I would like to select namespaces by arrows on keyboard. At the moment when I select a namespace the focus goes away and I have to click back on namespace to activate the dropdown.

The duration dropdown behaves fine. I can use arrows to select durations and the focus stays on the dropdown.

How to include the user documentation in the console

How to include the user documentation in the console.
Ex: a "?" icon that opens a popup explaning the graph in more details that just the legend?

Credential exposure in error responses

Prior to setting the appropriate ClusterRoles, I was receiving permission denied to some of the dashboard views. In debugging this, I found that Kiali appears to be leaking the userid/password to the client. Probably need to scrub/cleanse error responses in this case.

ServiceListComponent.tsx:237 {"config":{"transformRequest":{},"transformResponse":{},"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"headers":{"Accept":"application/json, text/plain, /","Content-Type":"application/json;charset=utf-8","Authorization":"Basic YWRtaW46YWRtaW4="},"method":"get","url":"/api/namespaces/default/services","data":"{}","params":{},"auth":{"username":"admin","password":"admin"}},"request":{},"response":{"data":{"error":"deployments.apps is forbidden: User "system:serviceaccount:istio-system:kiali" cannot list deployments.apps in the namespace "default""},"status":500,"statusText":"Internal Server Error","headers":{"date":"Fri, 18 May 2018 19:03:56 GMT","content-length":"150","content-type":"application/json"},"config":{"transformRequest":{},"transformResponse":{},"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"headers":{"Accept":"application/json, text/plain, /","Content-Type":"application/json;charset=utf-8","Authorization":"Basic YWRtaW46YWRtaW4="},"method":"get","url":"/api/namespaces/default/services","data":"{}","params":{},"auth":{"username":"admin","password":"admin"}},"request":{}}}

add helm chart to kubernetes/charts

Would be really nice to be able to deploy Kiali off-the-shelf without having to run make k8s-deploy

Feature Request: Support for animated visual representation of traffic.

As discussed here. It makes it much easier to see the amount of traffic vs line thickness.

Something in the vain of Visceral. It is possible with Visceral but is a lot of effort to make it Istio friendly. A Visceral demo can be found here.

I really like the idea of having a dashboard for all observability in the service mesh. Keep up the good work!

Empty Service Graph

unable to see service graph data for any namespace except istio-system. not much help in kiali pod logs. i can see data in istio service graph and as well as grafana.

Any clues where to check?

Curious why /vendor/* is not ignored in .gitignore?

Feature request: Real time graphs

Maybe adding a switch to show real time graphs (not the default view), but I think having something similar as http://logstalgia.io/ does would be impressive (and fun!)

Landing page card view

This is an issue to replace kiali/kiali-design#5 that was closed.
Summarizing our discussion on the topic:

1. there will be a new landing page (not graph, not services list) that will be in a form of a cards view.
2. Each card represents a namespace (aka openshift project)
3. In a card there will be several parts of information:
   a. namespace/project name
   b. number of services in a namespace
   c. if there are X services in error/warning - an indication with icon next to number of affected services (2 error, 3 warning, etc)
   if all services are green - a green V mark indicating all are good.
4. User can stand on "X services in error.warning" and see in tooltip their names.
5. User can click on "X services in error/warning" and navigate to services list filtered by this status (error/warning) and namespace name.

Advanced/next steps:
6. potential navigation to graph, if yes - how?
7. potential 2 landing pages - one with services health, one with workloads (or one page which is configurable by user selection)
8. alternative views for cases where there are too many cards (grid/list view instead of cards)

@cshinn @serenamarie125 have I missed anything? please add if so :)

services "jaeger-query" not found

using istio helm installer with --set tracing.enabled=true

Bug in error route checking

It seems that error checking does not work properly. See attached image. The route definition is from https://github.com/redhat-developer-demos/istio-tutorial/blob/master/istiofiles/route-rule-safari-recommendation-v2.yml.

istio 0.7.1
OC 3.9

Left bar too wide

Currently, the left bar only shows 4 options and there is too much blank space. AFAIK in patternfly (bear with me, I barely know patternfly) you can squeeze it to show only the icons (I think is this visual element http://www.patternfly.org/pattern-library/application-framework/masthead/ ), so I think it should be the default to avoid having too much blank space.

readme is missing instructions how to open the app

• accessing the sws route from oc get routes, it outputs "unable to connect"
• accessing the sws service (host and port) outpus "forbidden"

Accessibility

Hi, I'm not from the development team and I was looking at the project kiali/kiali-ui in general, I realized that there is nothing relevant in the project regarding accessibility, like HTML attributes (aria-label, aria-required), if the HTML is really semantic, accessibility tests, anyway, is something will be seen in the future?

Services/versions are not removed from service graph if they don't exist

I have deployed https://github.com/redhat-developer-demos/istio-tutorial and Istio 0.7.1.

I followed the readme and deployed recommendation:v2 then I removed it but it was still shown on the service graph screen, even though the duration was last minute.

Could not fetch Istio objects list.

istioConfig report error
Could not fetch Istio objects list. Error: [ gateways.networking.istio.io is forbidden: User "system:serviceaccount:istio-system:kiali" cannot list gateways.networking.istio.io in the namespace "default" ]

Add more elements to the graph's legend

A design is needed for

1. adding shapes to the legend
   https://issues.jboss.org/browse/KIALI-1078
2. there's a traffic animation available on the graph, the circles are currently same size and always black regardless if it's ok/error, perhaps we need some sort of indication for the traffic animation in the legend.
   @kiali/ux-reviewers

Design Workload related UI

There would be a new concept of a Workload in Kiali, following some new concepts in Istio 1.0
So, several new screens need to be designed and added, as well as some existing screens should be modified (like the service details page)
Relevant JIRAs:
https://issues.jboss.org/browse/KIALI-1216
https://issues.jboss.org/browse/KIALI-1217
https://issues.jboss.org/browse/KIALI-1218

Don't hardcode istio namespace

"istio-system" is hardcoded in several places and prevents using anything else.

Allow user to setup istio namespace by environment variable.

Also i will suggest that by default Kiali uses the namespace in which it is installed to get Istio services instead of "istio-system".

Feature request: Configurable Context Root

Hi,

I'm deploying Istio together with various addons like Grafana/Jager .. and Kiali . Because I didn't want to host all those addons on different hostnames on context root, I tried to deploy Kiali behind an Ingress controller (in this case Traefik) under /kiali. Obviously, because Kiali is listening on context root, I only get 404s.

Is there any way to configure the context root on which Kiali is listening on?

kiali api not returning any data

when i'm accessing the productpage-v1 metrics using the api calls the data is not getting populated.
command : curl -u admin:admin http://169.53.36.106:31632/api/namespaces/istio-system/services/productpage-v1/metrics

output:
{"metrics":{"request_count_in":{"matrix":[]},"request_count_out":{"matrix":[]},"request_error_count_in":{"matrix":[]},"request_error_count_out":{"matrix":[]}},"histograms":{"request_duration_in":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}},"request_duration_out":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}},"request_size_in":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}},"request_size_out":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}},"response_size_in":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}},"response_size_out":{"average":{"matrix":[]},"median":{"matrix":[]},"percentile95":{"matrix":[]},"percentile99":{"matrix":[]}}}}

Does anyone have documentation related to api calls?

Dropdowns or Button Groups?

There doesn't seem to be a consensus in the group over when to use Dropdowns and when to use Button Groups.

DropDowns

ButtonGroup

One factor here being that Button Groups require one click and show all their options while Drop Downs Require Two clicks - one to display the options and one to select.

Alignment and layout redesign for the graphs in metrics page

related JIRAs:
https://issues.jboss.org/browse/KIALI-1160
https://issues.jboss.org/browse/KIALI-741

The metrics page has several graphs, and having different data amounts and different data and legend types influences the graph size.
So with a lot of data grouping we get the issue that the legend is becoming too big and takes room of the graph.
And when some graphs have little data/no data, and others have data, the graphs next to each other stop being aligned.
I'm attaching 2 examples to illustrate both issues, but there's more info and screenshots in the JIRAs.
We need a design that solves the above issues and makes the metrics page graphs well aligned and balanced with the different legend sizes.

Dialog Box for handling Service Graph Visibility Layers

We are adding more and more visibility layers for the service graph. So perhaps a dialog box is warranted now. With a button on the toolbar to pull it up.

This is related to Jira Issue: https://issues.jboss.org/browse/KIALI-589

Provide an overall overview of the namespace health

Provide some concepts for an overall overview of the namespace health

Support for Istio prelim 1.0

The docs state that kiali supports Istio version 0.8+. I'm using a daily build of Istio.

https://gcsweb.istio.io/gcs/istio-prerelease/daily-build/release-1.0-20180716-12-45/

I see the following error in the kiali UI.

Istio version [email protected]/istio-release-1.0-20180716-12-45-6a7623f34d960de1e74f0cb1868abe73ee635ee7-dirty-Modified is not recognized, thus not supported.

How can I test kiali against istio prelim 1.0?

Istio Mixer Rules design

We are in the process of align some UX changes and the Istio Rules present some questions about how to render them.

Today we have this provisional/preliminar raw design:

A Istio Rule model is an entity having:

• A "match" field, which is a string that can be an expression, it is optional.
• A list of "actions" (1 to N).

Each "action" has also:

• A "handler" field, with a string as value.
• A list of "instances", each "instances" is also a string as value (1 to N).

Clicking on each handler or instance will navigate to a new page showing the content in an AceEditor.

I don't have a clear picture about how to model in UX terms.

A first approach could be to iterate each "action" as a list item, and inside of the list item, to map the "instances" as a table.

I'm going to start with that approach, but I would like to get some suggestions or recommendation.

No additional fields/columns, just the info described but with the cardinality on "actions" and "instances".

kiali failed to load graph if it was not installed in istio-system

I installed istio in the namespace of istio-system and installed kiali in the namespace of default, and found that the kiali failed to load graph, the following is log from kiali pod, seems kiali failed to lookup prometheus via kube-dns.

I0530 02:18:04.393334       1 graph.go:87] DEBUG: Build graph for namespace [kube-public]
I0530 02:18:04.393443       1 graph.go:597] DEBUG: Executing query round(sum(rate(istio_request_count{source_service!~".*\\.kube-public\\..*",destination_service=~".*\\.kube-public\\..*",response_code=~"[2345][0-9][0-9]"} [60s])) by (source_service),0.001)&time=2018-05-30 02:18:04 (now=2018-05-30 02:18:04, 1527646684)
E0530 02:18:04.427628       1 graph.go:631] Get http://prometheus:9090/api/v1/query?query=round%28sum%28rate%28istio_request_count%7Bsource_service%21~%22.%2A%5C%5C.kube-public%5C%5C..%2A%22%2Cdestination_service%3D~%22.%2A%5C%5C.kube-public%5C%5C..%2A%22%2Cresponse_code%3D~%22%5B2345%5D%5B0-9%5D%5B0-9%5D%22%7D+%5B60s%5D%29%29+by+%28source_service%29%2C0.001%29&time=2018-05-30T02%3A18%3A04Z: dial tcp: lookup prometheus on 40.0.0.10:53: no such host: goroutine 88 [running]:
runtime/debug.Stack(0xc4205421a0, 0x198, 0xc4200d28e0)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/runtime/debug/stack.go:24 +0xa7
github.com/kiali/kiali/handlers.handlePanic(0x186fdc0, 0xc4201222a0)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:631 +0xa6
panic(0xfa64a0, 0xc4200d28e0)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/runtime/panic.go:491 +0x283
github.com/kiali/kiali/handlers.checkError(0x185a180, 0xc4202fa540)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:614 +0xaa
github.com/kiali/kiali/handlers.promQuery(0xc42053e000, 0xbd, 0x0, 0xed2a000dc, 0x18e5ee0, 0x1866a40, 0xc4202c27d0, 0x0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:600 +0x457
github.com/kiali/kiali/handlers.buildNamespaceTrees(0xc4200f1214, 0xb, 0xc42017e400, 0x5, 0x8, 0xdf8475800, 0x1143bef, 0x13, 0xc4202c2800, 0x1, ...)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:185 +0x3b8
github.com/kiali/kiali/handlers.graphNamespaces(0xc42017e400, 0x5, 0x8, 0xdf8475800, 0x1143bef, 0x13, 0xc4202c2800, 0x1, 0x1, 0x5b0e09dc, ...)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:88 +0x2b4
github.com/kiali/kiali/handlers.graphNamespace(0x186fdc0, 0xc4201222a0, 0xc4204c3400, 0xc420337830)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:72 +0x96
github.com/kiali/kiali/handlers.GraphNamespace(0x186fdc0, 0xc4201222a0, 0xc4204c3400)
	/home/travis/gopath/src/github.com/kiali/kiali/handlers/graph.go:66 +0xa3
net/http.HandlerFunc.ServeHTTP(0x11af868, 0x186fdc0, 0xc4201222a0, 0xc4204c3400)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:1918 +0x44
github.com/kiali/kiali/vendor/github.com/gorilla/mux.(*Router).ServeHTTP(0xc42028f260, 0x186fdc0, 0xc4201222a0, 0xc4204c3400)
	/home/travis/gopath/src/github.com/kiali/kiali/vendor/github.com/gorilla/mux/mux.go:159 +0xed
github.com/kiali/kiali/server.(*serverAuthProxyHandler).handler(0xc4204017c0, 0x186fdc0, 0xc4201222a0, 0xc4204c4f00)
	/home/travis/gopath/src/github.com/kiali/kiali/server/server.go:98 +0x390
github.com/kiali/kiali/server.(*serverAuthProxyHandler).(github.com/kiali/kiali/server.handler)-fm(0x186fdc0, 0xc4201222a0, 0xc4204c4f00)
	/home/travis/gopath/src/github.com/kiali/kiali/server/server.go:37 +0x48
net/http.HandlerFunc.ServeHTTP(0xc420365570, 0x186fdc0, 0xc4201222a0, 0xc4204c4f00)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:1918 +0x44
net/http.(*ServeMux).ServeHTTP(0x18e5740, 0x186fdc0, 0xc4201222a0, 0xc4204c4f00)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:2254 +0x130
net/http.serverHandler.ServeHTTP(0xc4204daa90, 0x186fdc0, 0xc4201222a0, 0xc4204c4f00)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:2619 +0xb4
net/http.(*conn).serve(0xc42039a640, 0x1870ac0, 0xc42004c3c0)
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:1801 +0x71d
created by net/http.(*Server).Serve
	/home/travis/.gimme/versions/go1.9.4.linux.amd64/src/net/http/server.go:2720 +0x288

I deployed kiali with YAML templates from https://github.com/gyliu513/work/tree/master/k8s/charts/kiali , kiali works fine if it was installed in the namespace of istio-system but does not work for other namespaces.

Tracing and metrics fail to resolve

I have istio 0.7.1 installed with all of the add-ons (includes jaeger). However when I follow the instructions to install kiali I see errors to resolve grafana and jaeger services in the kiali UI. I don't see a configuration map that allows me to set the service URL. Are there built-in assumptions about the istio installation that kiali has baked in that I must use the istio install from the kiali project (I wouldn't think this would be the case).

Note, everything is installed in the istio-system namespace. I am using a 1.10.1 kubernetes install in IKS. Istio with grafana and jaeger are working fine.

add security visualization

Add security details' visualization to:
a) the service itself
b) the pipe between 2 services
If not secured, mark as such.

Feature request: support istio multi clusters

Support for istio multi clusters would be a nice feature to have :)

https://istio.io/docs/setup/kubernetes/multicluster-install/

multi tenant support

is there a plan to support multi-tenant features ? Also use openshift authentication proxy in future?

Move away from ingress and use Istio Gateway

We should use Istio Gateway instead of ingress.

Error from server (AlreadyExists): error when creating "STDIN": services "kiali" already exists

make k8s-deploy:
Error from server (AlreadyExists): error when creating "STDIN": services "kiali" already exists

How to solve？

Thank you

zoom component changes

The zoom component in the top left of the graph takes up space. Is it useful as-is?

I understand the usefulness of the re-fit button (which, IMO, is awesome and the best feature of this component). I understand the zoom bar is needed for those users without a mouse-with-wheel, otherwise, they have no way of zooming.

But the large pan circle - is that useful enough to take up valuable real estate on the graph? A simple mouse drag (or, a tablet tap/drag) can pan just as easily. And using the pan-circle pans slowly (perhaps we should speed that up?).

Can we think about how we can re-design (or remove) the large pan circle OR can we provide a button to show/hide the entire component (this has the added benefit of freeing up the real estate that the entire component uses).

Remove layout options dropdown to simple button.

https://issues.jboss.org/browse/KIALI-1172

Currently we have the layout options as a drop down (eg 'breadthfirst', 'cose', 'cola', 'dagre', 'klay'). Most users are probably not going to be familiar with these different options or the differences between them.

We are going to be simplifying the number of layouts to around 3 and want an easy way to allow a user to switch the layout type (without exposing to them what the layout type being used is).

An option which was brought up was to remove the dropdown and use a button on the toolbar instead. Something like 'switch layout'.

We are looking for input from UXD to see what is the best way to handle this.

Goals:

• make things easier to for users, they are mostly not going to know the different names or what they mean
• make it easier to switch layouts if there is a problem. Certain service graphs will only work with one type of layout and not another. If we detect there is a problem we would like to automatically switch to a layout that works
• provide an option to the users so that if they don't like one layout they can try another.

Question: istio 0.8 support?

does kiali work with istio 0.8 as there are major breaking changes in 0.8 with its previous version.?

Embed kiali in openshift console using webgui customizations

AFAIK this can be done by modifying the ocp webgui using this https://docs.openshift.com/container-platform/3.9/install_config/web_console_customization.html#web-console-project-left-navigation

Switching between app and workload graph views

The graph currently has two options for how its displayed: an app view and a workload view.

If all the workloads have the app label applied, then we show the app graph. A user in this situation may want to display the workload graph directly as well.

If any of the workloads is missing the app label, then we display the workload graph. A user in this situation would not be able to view the app graph.

We need to be able to visualise to the user what graph type they are currently using. And if they can display both provide an option to switch graph types.

make openshift-deploy fails due to namespaces "istio-system" not found

make openshift-deploy
Undeploying from OpenShift
oc delete all,secrets,sa,templates,configmaps,daemonsets,clusterroles,clusterrolebindings --selector=app=sws -n istio-system
No resources found
Deploying to OpenShift
oc create -f deploy/openshift/sws-configmap.yaml -n istio-system
Error from server (NotFound): error when creating "deploy/openshift/sws-configmap.yaml": namespaces "istio-system" not found
make: *** [Makefile:89: openshift-deploy] Error 1

Enable me create Gateway, VirtualServices etc from Kiali Dashboard

Most of the open source projects are doing visualisation for istio, but seems no one is creating a dashboard which can do write operations for istio, such as creating gateway, virtualservices etc. Hope istio can have such feature.

@jmazzitelli

Redesign navigation and breadcrumbs for Kiali

We have several different approaches for navigating between different screens and how breadcrumbs behave.
(see also https://github.com/kiali/kiali-design/issues/4#issuecomment-400154688)
We need a consistent navigation and breadcrumbs through the application

Badges

We need to formally discuss the badges on the cy graph. What badges do we want to display? Today, there are three types of badges:

1. The "lightning bolt" badge to indicate a circuit breaker has been defined (note: this does not denote if the CB is open or closed - it only denotes there is a CB definition that exists).

2. The "git branch" badge to indicate a route rule is defined.

3. The "dotted-line-cube" badge to indicate there is no istio sidecar.

Our cy graph will now be app/workload based (due to changes in Istio 1.0 telemetry). Read the pdf document and the thread I started found here for details: https://groups.google.com/d/msg/kiali-dev/zVVxLtkj_uo/n0o_Q9-qBQAJ

Since we are not service based now, we need to re-think the badges. For example:

1. A "no sidecar" badge is only relevant for workload nodes (if a workload node has a "no-sidecar" badge, it means that workload is missing the istio proxy). Since an "app" node could represent multiple workloads, what does a "no-sidecar" badge mean when its on an app node? The only thing it could mean is that "one or more of the workloads belonging to this app is missing a side car". Is the badge OK if that is the meaning we give it? Or do we say, "only put no-sidecar badges on workload nodes".

2. Since destination rules (circuit breakers, route rules, etc) are only on services, what does it mean to have a circuit breaker badge or route rule badge on an app or workload node? Since apps/workloads could have multiple services in front, seeing a circuit breaker badge on an app/workload node can only mean "one or more services associated with this app (or workload) has a circuit breaker." Do we still want to have these kinds of badges when these concepts belong to services, not really to apps or workloads?

3. Perhaps we want to re-think the entire badging concept - maybe we only want a single badge (say, a yellow-triangle to indicate "warning") and if a node has such a badge it indicates some kind of error condition (what error it is could be displayed elsewhere - perhaps in the side panel.). Such conditions that could cause a warning badge to show up could be things like "incoming requests are failing at a rate higher than 10%", "there is no side-car on the workload (or one of the workloads in the app)", etc.

In short, WHAT badges do we really want to show, and on what nodes should they be applicable (app or workload node, or both kinds?).