I heard through the CNI grapevine that the current alpha implementation of Service Topology is likely to be redesigned as a new KEP with a different API. Are you aware of anything to the contrary?
I haven't heard of this, but things move fast in the Kubernetes world. Trying to find a link to the KEP now.
In the meantime, Linkerd has you covered if you want to use Service Topologies in Kubernetes. Oh, and you can get mTLS and metrics at the same time. Cool.
That's quite interesting! Haven't heard anything about it personally. When I worked on the RFC for this (back in April) the topology KEP and PR had a roadmap with things they would like to do or change.
From the link you've sent it looks like they were trying to come up with a new KEP. Very curious to see where that will go. Either way, if they change the current API it's just one more reason for me to get a few PRs into the linkerd control plane.
Hey Matei, this is a great post. We are working on a new approach to topology aware routing that we hope will be a bit simpler and more automatic. Here's the KEP we're working on - still very much prealpha and open to feedback/ideas: https://github.com/kubernetes/enhancements/blob/master/keps/....
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.
keep 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
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.
13 comments
[ 2.8 ms ] story [ 48.7 ms ] threadhttps://github.com/cilium/cilium/issues/9708#issuecomment-67...
In the meantime, Linkerd has you covered if you want to use Service Topologies in Kubernetes. Oh, and you can get mTLS and metrics at the same time. Cool.
From the link you've sent it looks like they were trying to come up with a new KEP. Very curious to see where that will go. Either way, if they change the current API it's just one more reason for me to get a few PRs into the linkerd control plane.
Fyi: that is not exactly correct if you have access to alpha features and on >1.17 - https://kubernetes.io/docs/concepts/services-networking/serv...
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.
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.