kiali: Why my istio configuration below gets warning and error?
Hi Guys, I have problem on Istio Config menu found at Kiali web. My Kiali version is:
kiali-ui 0.11.0 (f0a8d441e763e62d7a39682eb60bb9b2c12d4609)
kiali v0.11.0 (bff6219618030a012c2ead4c361c6db97bbb5433)
Components
Istio 1.0.0
Subset is not found on the host

But in fact, i have 2 deployment stable and canary both has correct track label on it.
$ kubectl get deploy -n data-devops -l track=stable
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
corn-app-stable 1 1 1 1 47m
$ kubectl get deploy -n data-devops -l track=canary
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
corn-app-canary 1 1 1 1 21m
$ kubectl get svc -n data-devops corn-app-global -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: 2019-01-23T08:25:01Z
name: corn-app-global
namespace: data-devops
resourceVersion: "148223782"
selfLink: /api/v1/namespaces/data-devops/services/corn-app-global
uid: 60af40cc-1ee8-11e9-af67-42010a9401fd
spec:
clusterIP: 10.32.77.78
ports:
- name: http-corn-app
port: 3000
protocol: TCP
targetPort: 3000
selector:
app: corn-app
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
And as much as I can tell, I can access both deployment just fine through Istio Ingress Gateway (using traffic splitting for example). So I am not sure why the Kiali indicates that error above.
More than 1 gateways with the same host port combinaton

i’ve checked it multiple times, but the corn-app-stg.tvlk-data.com only listed on corn-app-gateway gateway.
$ kubectl get gateway --all-namespaces -o yaml | grep -i corn-app-stg.tvlk-data.com -B10
name: corn-app-gateway
namespace: data-devops
resourceVersion: "148223785"
selfLink: /apis/networking.istio.io/v1alpha3/namespaces/data-devops/gateways/corn-app-gateway
uid: 60b1529c-1ee8-11e9-af67-42010a9401fd
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- corn-app-stg.tvlk-data.com
--
port:
name: http-corn-app
number: 80
protocol: HTTP
tls:
httpsRedirect: true
- hosts:
- corn-app-stg.tvlk-data.com
So, I believe there is an error on Kiali on doing istio config validation.
Anyway, the public url can’t be resolved in public, since I hardcoded that in my /etc/hosts for testing.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 36 (20 by maintainers)
Commits related to this issue
- Fix issue #800 by checking labels from a correct service — committed to burmanm/kiali by deleted user 5 years ago
- KIALI-2521 Fix issue #800 by checking subset labels from the correct service — committed to burmanm/kiali by deleted user 5 years ago
- KIALI-2521 Fix issue #800 by checking subset labels from the correct service (#895) — committed to kiali/kiali by burmanm 5 years ago
Good catch. The point is since we are not implementing cross-ns validation (for security reasons and soft multi-tenancy support), we can’t check whether the workloads are present or not.
I just published a PR (https://github.com/kiali/kiali/pull/3800) slightly modifying the validation: if the host is not found (or in other namespace) then it won’t check for the workload+label matching.
I’ll re-open it to investigate.
@gadiener thanks for the comment @xeviknal perhaps the validation is skipping the egress host here.
Hello,
I’m facing the same issue with Kiali version v1.32.0-snapshot.1 and with the v1.31.0 too.
This is an example of the destination rule I’m using:
In the validation section in Kiali I see the warning
KIA0203 - This subset's labels are not found in any matching host. The destination rule is pointing to the Istio egress gateway and the labels are in place. The traffic seems to use the destination rule correctly so seems to be only a validation problem.@markmssd If you can share the yaml files, then that would be great (so that I don’t accidentially miss the real reason by making assumptions from the UI screenshots). You can mail them to miburman@redhat.com
Thanks @burmanm for creating the JIRAs. I add here the links for easy browsing. https://issues.jboss.org/browse/KIALI-2371 https://issues.jboss.org/browse/KIALI-2372
It’s something that technically should be there always - but your situation isn’t unique. I’m currently investigating (KIALI-2288) a suitable mid-way, since certain istio-system configs have the same issue.