4 ms·
It is sad to me you actually need linkers/istio for this. EndpointSlices support topology labels which the article states is in vanilla kubernetes. Which means
by wernerb 6y ago
It is sad to me you actually need linkers/istio for this.
EndpointSlices support topology labels which the article states is in vanilla kubernetes. Which means you can create different services for example a zone. Like "myservice-eu-west1a".
The problem is that a pod has no easy way to know what topology it is in to make the choice to go to myservice-eu-west1a. The feature for getting topology labels through the downward api is not there! A pod has no idea where its scheduled!
The only way to find out is to ask the kubernetes api, but this requires rbac, a client, libraries etc.. unacceptable! Guess what linkerd does for you?
I am glad for the feature linkerd offers as it solves a problem and I can see the benefit of perhaps doing latency based routing as well on top of this.
It just ticks me off we need something complex to do something simple: keep workloads to their own zone depending on where they are.
- The_rationalist 6y agokeep workloads to their own zone depending on where they are. Hadoop achieve exactly that, I wonder if their solution could be used as an inspiration for solving this in kubernetes
- harpratap 6y ago>A pod has no idea where its scheduled! I would argue this is a good thing. All of the this automatic routing and failovers should be transparent to business logic developers. You shouldn't need to include K8s apis inside your main container.