Looks as 2x rps and 2 hosts in the traffic graph when calling to the same namespace in the same cluster via serviceentry

[zodiac12k]

Describe the bug

It looks as the 2x rps and 2 hosts in traffic graph when calling to the same namespace in the same cluster via serviceentry.

I unselect Service Nodes in Display selection.

• recipe-api(in mesh-elsa namespace) --> external-superdeal-api(mesh-mocks) : 26.44rps
• core-api(mesh-elsa) --> recipe-api(mesh-elsa) : 26.44rps x 2 = 53.16rps

core-api(mesh-elsa) --> recipe-api(mesh-elsa) in the detail view has 2 hosts

• recipe-api-mesh-elsa.d4.clouz.io : outbound host in core-api app
• recipe-api.mesh-elsa.svc.cluster.local : inbound host in recipe-api app

But, it looks correct when calling to the different namespace.

facade-api --> core-api or recipe-api --> superdeal-api

Expected Behavior

Of the 2 hosts, I think it should be shown excluding the in-cluster service(recipe-api.mesh-elsa.svc.cluster.local)

What are the steps to reproduce this bug?

1. ServiceEntry, Service

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-elsa-recipe-api
  namespace: mesh-elsa
spec:
  hosts:
  - recipe-api-mesh-elsa.d4.clouz.io
  location: MESH_EXTERNAL
  ports:
  - name: http
    number: 80
    protocol: HTTP
  resolution: DNS

apiVersion: v1
kind: Service
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftWebConsole
  labels:
    app: recipe-api
  name: recipe-api
  namespace: mesh-elsa
spec:
  clusterIP: 172.130.209.79
  clusterIPs:
  - 172.130.209.79
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    port: 8080
    protocol: TCP
    targetPort: 8080
  - name: tcp-management
    port: 8081
    protocol: TCP
    targetPort: 8081
  - name: tcp-jmx
    port: 1099
    protocol: TCP
    targetPort: 1099
  selector:
    app: recipe-api
    name: recipe-api
  sessionAffinity: None
  type: ClusterIP

2. Api call test with fortio

fortio load -c 1 -t 30m -qps 10 -X "POST" -httpbufferkb 5600 -H "Content-Type: application/json" -H "Accept: application/json" -payload "{ \"sectionPageApiData\": \" {\\\"pageTypeSeq\\\":12001,\\\"pagingNumber\\\":2,\\\"lastModuleAsn\\\":2,\\\"arendelleRankType\\\":\\\"None\\\",\\\"stateParams\\\":null}\"}" -allow-initial-errors=true http://mesh-hermes-api-dev.d3.clouz.io/api/v1/home/mesh/section/pagination/12001\?sa_latency=0\&sa_failRate=0\&sa_resCode=500

Environment

Learn about how to determine versions here.

• Kiali version: v1.82
• Istio version: 1.21.1
• Kubernetes impl: Openshift
• Kubernetes version: v1.27.6+f67aeb3
• Other notable environmental factors: disable ingress/egress gateway

[jshaughn]

Hi @zodiac12k , thanks for the report. I'm not sure we've seen the use case where a service entry is used to call back into the cluster, and not just to reach an external endpoint. Are you sure that all requests from core-api to recipe-api in turn result in a request to the service entry?

[zodiac12k]

Hi @jshaughn, multi clusters and GSLB are used for high availability. When making API calls among applications, an external endpoint is used and the cluster to enter is eventually determined through GSLB. Therefore, the calling app and the callee app may be located in the same namespace in the same cluster.