Closed brunda-bs closed 3 weeks ago
triage: our upgrade policy allows to upgrade 2 minor versions, so you should upgrade from
2.5.2
to2.7.6
and then from2.7.6
to2.8.2
. Also are you sure you upgraded global first?
@brunda-bs any news?
Hi @lukidzi / @slonka
Yes, We did upgrade the global first.
triage: did you also upgraded as suggested from 2.5.x to 2.7.x first and then from 2.7.x to 2.8.x?
I've tried to reproduce it but no luck: My steps:
Install kuma 2.5.2 on global
./kumactl install control-plane \
--set "controlPlane.mode=global" \
| kubectl apply -f -
Install kuma 2.5.2 on zone
./kumactl install control-plane \
--set "controlPlane.mode=zone" \
--set "controlPlane.zone=zone" \
--set "ingress.enabled=true" --set "egress.enabled=true" \
--set "controlPlane.kdsGlobalAddress=grpcs://<GLOBAL_IP>:5685" \
--set "controlPlane.tls.kdsZoneClient.skipVerify=true" \
| kubectl apply -f -
Create external services
apiVersion: kuma.io/v1alpha1
kind: ExternalService
mesh: default
metadata:
name: httbin
spec:
tags:
kuma.io/service: httbin
kuma.io/protocol: tcp
networking:
address: httpbin.org:443
tls: # optional
enabled: false
Install demo-app kumactl install demo | kubectl apply -f -
Check that there is only one externalservice kubectl get externalservices
on zone
NAME AGE
httpbin 10m
Upgrade global control-plane to 2.8.2 (the same command as in 1)
Upgrade zone control-plane to 2.8.2 (the same command as in 2 with global ip)
Check logs and externalservices, there is only one externalservice with hash, no errors @brunda-bs could you check if the reproduction steps are correct? I couldn't reproduce it
@brunda-bs could you take a look at the reproduction steps that Lukasz posted?
@brunda-bs Hi, have you had a chance to take a look?
triage: it's been more than a month without information
What happened?
We are trying to upgrade Kuma from 2.5.2 to 2.8.2. We see an issue with external service connectivity post-upgrade. We have 500+ external services in our current setup.
Kuma control plane error logs:
2024-08-06T04:34:30.568Z ERROR vips-outbound-view there are two external services with the same 'networking.address' or two headless services, to disable automatic DNS generation in external services set 'networking.disableHostDNSEntry=true' in at least one of these externalService {"error": "autogenerated DNS entry cpmsignal-training.xyz-digital.net:443 from external-service:cpmsignal-training-xyz-digital-net-443-4vvvf74fbw6w4vz6 conflicts with existing entry external-service:cpmsignal-training-xyz-digital-net-443"}
Looks like the above error is due to the metadata name changes for the external service in zone tenants post-upgrade. Although the error disappears after 10-15 minutes, the application container is failing to establish connectivity to the external service as it is failing with a connection refused error or failed to resolve the external DNS error.
The external services that were created in 2.5 were having the metadata.name -
cpmsignal-training-xyz-digital-net-443.
After the upgrade global cp still using the same but somehow the Zone cp is recreating a local copy of the external service configuration with a different metadata.name.cpmsignal-training-xyz-digital-net-443-4vvvf74fbw6w4vz6
Global CP external service:
Zone CP external service: