OK, A/AAAA are more common.
> your networking layer should be k8s aware and issue a watch command on Endpoints;
Or, I could use standard networking concepts and not build my entire app to suit one new thing that I may not want to stay with forever, or even more than just test.
> What linkerd buys you is you don't have to write this type k8s-aware, zipkin logging library for every language you're running in production
There are already TCP/IP, DNS, DHCP, &c libraries for all languages, and that aren't tied to a specific stack. Why should I build into this stack and not into a more common subset?
Even if you pick all your impls carefully, you have to wait for your TTL instead of a push mechanism for changes.
If you wanted to implement the watch as a library, code wise, it's maybe ~500 lines per language, using the k8s client lib. I could hammer it out in two days.
What linkerd buys you is you don't have to write this type k8s-aware, zipkin logging library for every language you're running in production. But I think it's straddling a very narrow section; small users shouldn't care about this and just rely on the round robin, zipkin is a PITA to run anyway. Large users will probably want to write their own libraries (zipkin is a lot better if you put traces in your process)