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
Sidecar CRD is ignored when pod rebalance from one Istiod to another and is endpoint in a ServiceEnrty #50968
Comments
Can you maybe post the SE and Sidecar or an example? Does it happen every time? If you want to trigger it more (or less)often for testing, the --keepaliveMaxServerConnectionAge flag on istiod controls the 30min time btw |
Yes, it happens every time. Here is the SE:
Here is the Sidecar:
|
curl 127.0.0.1:8080/debug/sidecarz?proxyID=sleep-ilo-2 in istiod. it will show you the inner object |
Without SE:
With SE:
|
This looks weird, with SE. The sleep-ilo-2 cannot matches the sidecar declared, rather it use the default sidecar, actually no sidecar. Let me think about hoiw that can happen |
I doubt in Proxy.SetWorkloadLabels, we overwrite the node labels with nil, because of the SE/Endppoints has not labels. So PushContext.getSidecarScope can not match the Want you to help confirm by curl /debug/adsz |
Sure
|
Is the above get without SE, can you get the result with SE BTW, i cannot get the ip from the result. As you said the ips are actually pods ip
|
I can see the labels do not include any "app": "sleep-ilo-2", so definitely cannot match the sidecar with selector
|
I found the cause, now we add registry serviceEntry in front of kube. The order should be reversed.
|
This is a regression from long before, since we refactored multicluster |
Is this the right place to submit this?
Bug Description
We have a Sidecar CRD with configurations of
egress.hosts
that match pods with sidecar injected byworkloadSelector
.We also create a ServiceEntry and add those pods as endpoints in a ServiceEntry by IP address.
Once we do it, we see that 30 minutes after the sidecars boot (when the sidecar connection to Istiod is recreated), Istiod ignores the Sidecar CRD and the egress configurations and starts to push all the mesh configs to the sidecars.
It happens even if the connection is recreated to the same Istiod.
We tried setting the ServiceEntry.spec.location to MESH_EXTERNAL and MESH_INTERNAL, but it didn’t change.
This can also be reproduced by deleting the Istiod that the sidecar is connected to:
Version
Additional Information
No response
The text was updated successfully, but these errors were encountered: