Closed lobkovilya closed 1 week ago
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
@lobkovilya and @jakubdyszkiewicz is this still a thing with the recent changes to zoneEgress/zoneIngress?
As far as I know, it's still an issue. I don't think the EDS resolver or TLS termination part was changed recently.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
Not to be fixed we'll focused on MeshExternalService
There are 2 reasons why it doesn't work:
1. Mixing up hostnames and IPs in the Envoy cluster
If we have 2 external services:
For ZoneEgress in zone-1 Kuma creates EDS cluster
es
that contains 2 endpointszone-1.external.service:80
and<zone-ingress-in-zone-2-IP>
. Envoy can't resolve hostnames for EDS clusters, that's why configuration can't be applied on Envoy.2. Missing TLS termination before sending a request to ExternalService
Even if in the previous example we replace addresses with IPs:
For ZoneEgress in zone-1 Kuma creates FilterChain that doesn't terminate TLS:
But if we remove
es-2
then FilterChain fores-1
will be correct: