Open lhanjian opened 1 month ago
IstioEndpoint do not always come from Endpoints, or even from a Kubernetes object, or even from a single Kubernetes object (sometimes its multiple). So I don't see how we can do this.
What do you need it for?
IstioEndpoint do not always come from Endpoints, or even from a Kubernetes object, or even from a single Kubernetes object (sometimes its multiple). So I don't see how we can do this.
Yes, But can these scenarios be used by developer to define the semantics themselves?
What do you need it for?
I used it for watch K8s Endpoints current ResourceVersion, it can make me know "Which K8s Endpoints ResourceVersion has been ACK by envoy“
In this observational scenario of xDS, k8s Generation is a better choice. Unfortunately, k8s endpoints do not have such a thing.
so i am implementing a feature for our istio,
K8s Endpoints(with newer ResourceVerison)->Istio EndpointController->endpointsByServiceAndSlice.
EndpointMetadata get information by MetadataClone()/Metadata() from IstioEndpoint, it also will including ResourceVerision,
then we can insert ResourceVersion in EnvoyMedata by AppendLbEndpointMetadata().
if EnvoyMetadata.ResourceVersion == K8s Endpoints ResoureceVersion (other sources), then we can acually know dynamic_endpoint_config of dataplane has been synced with K8s Endpoints.
Tks for your reply!
Another backgroup,
i also want to use config_distribution to track PUSH/ACK or xDS, but its postion of record seems not correct, in https://github.com/istio/istio/issues/48679 .
Before this,i also found EDS lost nonce in config_distribution. record https://github.com/istio/istio/issues/48985.
I don't think it makes sense to plumb complex data through OSS Istio codebase in order to support a closed source vendor fork (IIUC). If you want to maintain a fork, that is fine, but IMO you should be responsible to do the work to add features in your fork, not push the maintenance burden onto OSS with no benefit to OSS.
I don't think it makes sense to plumb complex data through OSS Istio codebase in order to support a closed source vendor fork (IIUC). If you want to maintain a fork, that is fine, but IMO you should be responsible to do the work to add features in your fork, not push the maintenance burden onto OSS with no benefit to OSS.
Thanks for your reply. I hope that in the future I can contribute useful abilities to the entire community.:-p
(This is used to request new product features, please visit https://github.com/istio/istio/discussions for questions on using Istio)
Describe the feature request
Istio Config CRs have resourceVersion, but istioEndpoint doesn't have resourceVersion.
So we don’t know which version of K8s Endpoints, IstioEndpoint corresponds to
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[ ] Ambient [ ] Docs [ ] Dual Stack [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [ ] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane
Additional context