Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to identify an application #12095

Open
lahabana opened this issue Nov 25, 2024 · 1 comment
Open

Add a way to identify an application #12095

lahabana opened this issue Nov 25, 2024 · 1 comment
Labels
kind/feature New feature triage/accepted The issue was reviewed and is complete enough to start working on it

Comments

@lahabana
Copy link
Contributor

Description

With the coming up of MeshService we have a separation between workload (pods) and service (service). This is a very good thing because that's how Kubernetes see things.

One issue we have now is that it's hard to relate services and workloads, a common way in kubernetes is to use the app label and its newer alternative app.kubernetes.io/name.

From the top of my head I think this would be useful to:

  • Get rid of kuma.io/service in Dataplane
  • In dashboards be able to relate and differentiate between outbound and inbound metrics.
  • Auto reachable services?
  • Building a service Map
  • Group multiple deployments in different zones

To me implementation should be:

  • In mesh object define what labels should be used in order e.g:
type: Mesh
name: default
spec:
  constraints:
    dataplaneProxy:
       appLabels: [app.kubernetes.io/name, app] # the order is priority (if one is set the others are ignored)

This would then add kuma.io/service: app to all entities by translating labels.

xrefs:

@lahabana lahabana added triage/pending This issue will be looked at on the next triage meeting kind/feature New feature labels Nov 25, 2024
@lukidzi
Copy link
Contributor

lukidzi commented Nov 25, 2024

triage: Let's figure out it

@lukidzi lukidzi added triage/accepted The issue was reviewed and is complete enough to start working on it and removed triage/pending This issue will be looked at on the next triage meeting labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
Development

No branches or pull requests

2 participants