5 ms·

A few items: 1) The people on that page all contribute mightily to the project in various ways - we wouldn't be where we are without them. We take feedback fro

A few items: 1) The people on that page all contribute mightily to the project in various ways - we wouldn't be where we are without them. We take feedback from everyone (we have over 15 special interest groups, many led by non-core team members). 2) K8s developers are most definitely not primarily sponsored by Google - more than 60% of K8s devs are NOT Googlers. 3) Overlay networks are definitely not a hack - many partners set them up with great benefit. The fact is networking is hard (tm), and unless you're just looking for a flat network, then you're going to have to use SOMETHING. Disclosure: I work at Google on Kubernetes

otterley 10y ago
> K8s developers are most definitely not primarily sponsored by Google - more than 60% of K8s devs are NOT Googlers. The key metric, in my view, is how many of them can approve PRs into master. How many of them are not Googlers? Moreover, what would happen if a PR arrived that might make K8S incompatible with GCE, but be otherwise better for everyone else? I am certain it would be summarily rejected by Google. > Overlay networks are definitely not a hack - many partners set them up with great benefit. The fact is networking is hard (tm), and unless you're just looking for a flat network, then you're going to have to use SOMETHING. I respectfully disagree. The use of multiple IP addresses per node is a hard requirement of K8S, even though it is arguably unnecessary in environments whose servers can be bound to arbitrary ports. By doing so, K8S made an explicit tradeoff that was better suited to Google's cloud offering than others'. I'm not saying it was the wrong decision; I'm simply saying that it forces complexity on those who operate in single-IP-per-host environments. (In case you think I'm unfairly laying blame, I point the finger equally at AWS and other cloud providers who refuse to make it simple to allocate a useful number of IP addresses per instance.) I maintain my characterization that overlay networks are a hack: they make tracing more complex (tcpdump doesn't natively understand VXLAN or decapsulate their frames); they are compatible with few (if any) NetFlow analyzers (which are often used by orgs who use them for IDS and other purposes); and they add overhead to packet processing, particularly in virtualized environments that don't support VXLAN hardware offloading.
- smarterclayton 10y ago
  I originally objected to IP per pod given that it was so early in wide scale deployment of SDN on metal (at Red Hat, a year before Kube 1.0, we were already worried about how in the world we could support IP per pod as well as on gce). In light of everything, I think it was the right decision. While VXLAN is cumbersome, IP per entity allows very powerful integration into existing networks, fits well with almost all tools in the space, and makes apps much easier to run. I do still want to see more solid work done for programmable BGP (calico) and programmable iptables (Contiv) and even programmable routers (it's not that hard to program routers on the fly today, just incredibly specific to each technology). I also look forward to being able to exploit tools like ECMP more effectively within the cluster to do L3 load balancing and DSR - much of that would be a lot harder without being able to rely on endpoints everywhere.
harlowja 10y ago
Where are you getting the 60% number from? From an analysis of all commits in the k8s (main) repo this is the data I am getting about domains and the breakup of which users under which domains commit/author the most. ----------------------- Top 20 author (domains) ----------------------- google.com => 16825 gmail.com => 8220 redhat.com => 4051 fathomdb.com => 501 bedafamily.com => 420 coreos.com => 398 huawei.com => 352 raintown.org => 269 zte.com.cn => 183 mesosphere.io => 172 zju.edu.cn => 140 apache.org => 126 mirantis.com => 72 hotmail.co.uk => 67 amadeus.com => 67 163.com => 64 us.ibm.com => 64 tmrts.com => 44 box.com => 43 canonical.com => 42 -------------------------- Top 20 committer (domains) -------------------------- google.com => 16655 gmail.com => 7130 redhat.com => 4065 fathomdb.com => 493 bedafamily.com => 419 coreos.com => 388 huawei.com => 348 raintown.org => 268 zte.com.cn => 180 mesosphere.io => 174 zju.edu.cn => 131 apache.org => 121 amadeus.com => 66 163.com => 65 us.ibm.com => 64 hotmail.co.uk => 63 mirantis.com => 63 ebay.com => 53 box.com => 43 tmrts.com => 42 Btw you (google?) should really invest in something like http://stackalytics.com/ http://stackalytics.com/ if the community wants to have good transparency around this type of data. Crappy script to generate that data @ https://gist.github.com/harlowja/aca0b3c7d94c78014798fd9eb8887dff https://gist.github.com/harlowja/aca0b3c7d94c78014798fd9eb88...
- TheIronYuppie 10y ago
  There's no question Google has the most code checked in, but this can be a faulty metric (generated, rebased, etc can mess up authorship). We think it's more important around # of unique contributors, where we (Google) are <50%. For Stackalytics - http://stackalytics.com/?project_type=kubernetes-group&metric=commits http://stackalytics.com/?project_type=kubernetes-group&metri... Looks like my 60% number is out of date - looks like we (Google) are up to 44%. I'll have to figure out why. Disclosure: I work at Google on Kubernetes
  - otterley 10y ago
    In my experience, the question of who the contributors are and how much they may contribute is less important than the question of who has control of the project. If you're claiming that Google has delegated authority over Kubernetes to the open-source community, and therefore is not in a position to place its needs over those of the community, please say so explicitly here. Why quibble over statistics when we can get an official statement?

otterley 10y ago

> K8s developers are most definitely not primarily sponsored by Google - more than 60% of K8s devs are NOT Googlers. The key metric, in my view, is how many of them can approve PRs into master. How many of them are not Googlers? Moreover, what would happen if a PR arrived that might make K8S incompatible with GCE, but be otherwise better for everyone else? I am certain it would be summarily rejected by Google. > Overlay networks are definitely not a hack - many partners set them up with great benefit. The fact is networking is hard (tm), and unless you're just looking for a flat network, then you're going to have to use SOMETHING. I respectfully disagree. The use of multiple IP addresses per node is a hard requirement of K8S, even though it is arguably unnecessary in environments whose servers can be bound to arbitrary ports. By doing so, K8S made an explicit tradeoff that was better suited to Google's cloud offering than others'. I'm not saying it was the wrong decision; I'm simply saying that it forces complexity on those who operate in single-IP-per-host environments. (In case you think I'm unfairly laying blame, I point the finger equally at AWS and other cloud providers who refuse to make it simple to allocate a useful number of IP addresses per instance.) I maintain my characterization that overlay networks are a hack: they make tracing more complex (tcpdump doesn't natively understand VXLAN or decapsulate their frames); they are compatible with few (if any) NetFlow analyzers (which are often used by orgs who use them for IDS and other purposes); and they add overhead to packet processing, particularly in virtualized environments that don't support VXLAN hardware offloading.

smarterclayton 10y ago
I originally objected to IP per pod given that it was so early in wide scale deployment of SDN on metal (at Red Hat, a year before Kube 1.0, we were already worried about how in the world we could support IP per pod as well as on gce). In light of everything, I think it was the right decision. While VXLAN is cumbersome, IP per entity allows very powerful integration into existing networks, fits well with almost all tools in the space, and makes apps much easier to run. I do still want to see more solid work done for programmable BGP (calico) and programmable iptables (Contiv) and even programmable routers (it's not that hard to program routers on the fly today, just incredibly specific to each technology). I also look forward to being able to exploit tools like ECMP more effectively within the cluster to do L3 load balancing and DSR - much of that would be a lot harder without being able to rely on endpoints everywhere.

harlowja 10y ago

Where are you getting the 60% number from? From an analysis of all commits in the k8s (main) repo this is the data I am getting about domains and the breakup of which users under which domains commit/author the most. ----------------------- Top 20 author (domains) ----------------------- google.com => 16825 gmail.com => 8220 redhat.com => 4051 fathomdb.com => 501 bedafamily.com => 420 coreos.com => 398 huawei.com => 352 raintown.org => 269 zte.com.cn => 183 mesosphere.io => 172 zju.edu.cn => 140 apache.org => 126 mirantis.com => 72 hotmail.co.uk => 67 amadeus.com => 67 163.com => 64 us.ibm.com => 64 tmrts.com => 44 box.com => 43 canonical.com => 42 -------------------------- Top 20 committer (domains) -------------------------- google.com => 16655 gmail.com => 7130 redhat.com => 4065 fathomdb.com => 493 bedafamily.com => 419 coreos.com => 388 huawei.com => 348 raintown.org => 268 zte.com.cn => 180 mesosphere.io => 174 zju.edu.cn => 131 apache.org => 121 amadeus.com => 66 163.com => 65 us.ibm.com => 64 hotmail.co.uk => 63 mirantis.com => 63 ebay.com => 53 box.com => 43 tmrts.com => 42 Btw you (google?) should really invest in something like http://stackalytics.com/ http://stackalytics.com/ if the community wants to have good transparency around this type of data. Crappy script to generate that data @ https://gist.github.com/harlowja/aca0b3c7d94c78014798fd9eb8887dff https://gist.github.com/harlowja/aca0b3c7d94c78014798fd9eb88...

TheIronYuppie 10y ago
There's no question Google has the most code checked in, but this can be a faulty metric (generated, rebased, etc can mess up authorship). We think it's more important around # of unique contributors, where we (Google) are <50%. For Stackalytics - http://stackalytics.com/?project_type=kubernetes-group&metric=commits http://stackalytics.com/?project_type=kubernetes-group&metri... Looks like my 60% number is out of date - looks like we (Google) are up to 44%. I'll have to figure out why. Disclosure: I work at Google on Kubernetes
- otterley 10y ago
  In my experience, the question of who the contributors are and how much they may contribute is less important than the question of who has control of the project. If you're claiming that Google has delegated authority over Kubernetes to the open-source community, and therefore is not in a position to place its needs over those of the community, please say so explicitly here. Why quibble over statistics when we can get an official statement?