11–20 of 34 posts
Did anyone do some measurements on k8s/container latency overhead in networks?
Yes. And they are _really_ easy to find. https://machinezone.github.io/research/networking-solutions-... https://itnext.io/benchmark-results-of-kubernetes-network-pl... Edit: added one more link
Did anyone do some measurements on k8s/container latency overhead in networks?
Yes. And they are _really_ easy to find. https://machinezone.github.io/research/networking-solutions-... https://itnext.io/benchmark-results-of-kubernetes-network-pl... Edit: added one more link
Thanks for the links.
I think it's because they still want to use the socket API, but to "pretend" you can open a socket to a pod, or to a service, etc.
Instead, they should have defined a new API, like "connect('k8s:service:foobar?selectionstrategy=leastloaded')"
Then they could have made simple LD_PRELOAD shims to get their magic API to work with existing software without modification.
There would be no need for millions of IPtables rules, virtual IP addresses, port remapping, proxy processes, etc.
It's surprising k8s being so new seems to have no concept of ipv6
Because ipv6 is not a simple addition, but a complex suite of new protocols meant to replace v4, except that is never going to happen in our lifetimes. v6 should've simply been v4 with more bits
Did anyone do some measurements on k8s/container latency overhead in networks?
https://mailarchive.ietf.org/arch/msg/hackathon/PjbOkxx-5O0o...
I feel like k8s networking is 10x more complex than it needs to be... I think it's because they still want to use the socket API, but to "pretend" you can open a socket to a pod, or to a service, etc. Instead, they should have defined a new API, like "connect('k8s:service:foobar?selectionstrategy=leastloaded')" Then they could have made simple LD_PRELOAD shims to get their magic API to work with existing software wit…
I feel like k8s networking is 10x more complex than it needs to be... I think it's because they still want to use the socket API, but to "pretend" you can open a socket to a pod, or to a service, etc. Instead, they should have defined a new API, like "connect('k8s:service:foobar?selectionstrategy=leastloaded')" Then they could have made simple LD_PRELOAD shims to get their magic API to work with existing software wit…
That is basically how consul connect works: https://www.consul.io/docs/connect/native/go.html
I feel like k8s networking is 10x more complex than it needs to be... I think it's because they still want to use the socket API, but to "pretend" you can open a socket to a pod, or to a service, etc. Instead, they should have defined a new API, like "connect('k8s:service:foobar?selectionstrategy=leastloaded')" Then they could have made simple LD_PRELOAD shims to get their magic API to work with existing software wit…
Kubernetes' networking would arguably have been less complex (multiple CIDR subnets, proxying, etc.) if they'd embraced IPv6. But Google doesn't seem big on IPv6.
I feel like k8s networking is 10x more complex than it needs to be... I think it's because they still want to use the socket API, but to "pretend" you can open a socket to a pod, or to a service, etc. Instead, they should have defined a new API, like "connect('k8s:service:foobar?selectionstrategy=leastloaded')" Then they could have made simple LD_PRELOAD shims to get their magic API to work with existing software wit…
Earlier quoted context omitted.
Because ipv6 is not a simple addition, but a complex suite of new protocols meant to replace v4, except that is never going to happen in our lifetimes. v6 should've simply been v4 with more bits
No backwards compatibility could be IPv6's biggest mistake. Now everyone is forced to maintain 2 IP addresses.