4 ms·

"No guys stop complaining that google doesn't give support to kubernetes, we are not Google, we are the Cloud Native Computing Foundation." -- Some kubernetes d

by msl09 10y ago

"No guys stop complaining that google doesn't give support to kubernetes, we are not Google, we are the Cloud Native Computing Foundation." -- Some kubernetes developer. Release blog of kubernetes brought to you by: -- Aparna Sinha, Product Manager, Google. Seriously though those new features are really neat, and seems to compete with the ease of setup of docker 1.12(though swarm was a bit of a mess when I last tried to make something useful of it (docker 1.12.0)), I hope I can test them at work soon. For now I'm having a great time with rancher.io and cattle.

TheIronYuppie 10y ago
Sorry, can you say more about your issue? We've always said we contribute (a ton!) to Kubernetes, but it's definitely not a commercial product, so we don't have a support for on-premises/non-Google Cloud deployments. That said (!!), if paid support is what you're after, please use one of the MANY organizations who DO offer support (http://kubernetes.io/community/ http://kubernetes.io/community/ - about halfway down the page) and are huge contributors to the community. Disclosure: I work at Google on Kubernetes.
- otterley 10y ago
  The problem is, if the supporting organization is not the same as the developing organization, there's no obligation for the developing organization to respond to feedback from the supporting organization -- the developers are free to accept or reject feedback as they deem fit. There could even be a conflict of interest: the Kubernetes developers are primarily sponsored by Google, which has an interest in promoting its own cloud offerings over those of their competitors. (Note the relative difficulty of setting up K8S on EC2; even if you can set it up, K8S assumes the ability to create a network topology that's unique to GCE; otherwise you have to use overlay network hacks.)
  - TheIronYuppie 10y ago
    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.
  - xkarga00 10y ago
    I don't think there is a distinction between a supporting and a developing organization at this point in the Kube ecosystem. At Red Hat we offer an enterprise version of Kube (OpenShift v3) and at the same time we contribute a ton of stuff back upstream. Personally it has been a great experience for me working with engineers from Google, different companies, and even individual contributors and I am pretty sure most if not all of my coworkers feel the same thing.
    - otterley 10y ago
      Have you ever made a contribution that conflicted with Google's goals? If so, how was it handled?
      - smarterclayton 10y ago
        To be honest, I've been contributing to Kubernetes longer than any one who doesn't work at google, and it hasn't ever been an issue for me. The Googlers I have worked with have been sticklers for doing the right thing for the people we expected to need Kubernetes. The google teams goals (seen from the outside) have been to built a phenomenal system for running applications that is stable, reliable, makes app author / maintainers lives easier, and will succeed as an open source ecosystem. If we have disagreed, it's more in the details of what to prioritize in the short term to succeed broadly (features, scale, ease of install, ease of running existing Docker images, etc). We haven't always picked right - but it's not for lack of trying. EDIT: And I have certainly "forced" things that I felt certain audiences need into Kube by convincing other contributors over their initial objections. I can't think of a place where a reasoned argument has not carried the day, ever.
        thockingoog 10y ago
        As someone who has been on the receiving end of Clayton's arguments (and a sometimes-winner :), I vouch. What he says above is really and truly the highest compliment one could pay.
TheIronYuppie 10y ago
I can't edit my previous comment, but let me just drop this here - Canonical JUST released a new commercially supported distro of Kubernetes. https://insights.ubuntu.com/2016/09/27/canonical-expands-enterprise-container-portfolio/ https://insights.ubuntu.com/2016/09/27/canonical-expands-ent... Disclosure: I work at Google on Kubernetes.

by msl09 10y ago

TheIronYuppie 10y ago

Sorry, can you say more about your issue? We've always said we contribute (a ton!) to Kubernetes, but it's definitely not a commercial product, so we don't have a support for on-premises/non-Google Cloud deployments. That said (!!), if paid support is what you're after, please use one of the MANY organizations who DO offer support (http://kubernetes.io/community/ http://kubernetes.io/community/ - about halfway down the page) and are huge contributors to the community. Disclosure: I work at Google on Kubernetes.

otterley 10y ago
The problem is, if the supporting organization is not the same as the developing organization, there's no obligation for the developing organization to respond to feedback from the supporting organization -- the developers are free to accept or reject feedback as they deem fit. There could even be a conflict of interest: the Kubernetes developers are primarily sponsored by Google, which has an interest in promoting its own cloud offerings over those of their competitors. (Note the relative difficulty of setting up K8S on EC2; even if you can set it up, K8S assumes the ability to create a network topology that's unique to GCE; otherwise you have to use overlay network hacks.)
- TheIronYuppie 10y ago
  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.
- xkarga00 10y ago
  I don't think there is a distinction between a supporting and a developing organization at this point in the Kube ecosystem. At Red Hat we offer an enterprise version of Kube (OpenShift v3) and at the same time we contribute a ton of stuff back upstream. Personally it has been a great experience for me working with engineers from Google, different companies, and even individual contributors and I am pretty sure most if not all of my coworkers feel the same thing.
  - otterley 10y ago
    Have you ever made a contribution that conflicted with Google's goals? If so, how was it handled?
    - smarterclayton 10y ago
      To be honest, I've been contributing to Kubernetes longer than any one who doesn't work at google, and it hasn't ever been an issue for me. The Googlers I have worked with have been sticklers for doing the right thing for the people we expected to need Kubernetes. The google teams goals (seen from the outside) have been to built a phenomenal system for running applications that is stable, reliable, makes app author / maintainers lives easier, and will succeed as an open source ecosystem. If we have disagreed, it's more in the details of what to prioritize in the short term to succeed broadly (features, scale, ease of install, ease of running existing Docker images, etc). We haven't always picked right - but it's not for lack of trying. EDIT: And I have certainly "forced" things that I felt certain audiences need into Kube by convincing other contributors over their initial objections. I can't think of a place where a reasoned argument has not carried the day, ever.
      - thockingoog 10y ago
        As someone who has been on the receiving end of Clayton's arguments (and a sometimes-winner :), I vouch. What he says above is really and truly the highest compliment one could pay.

TheIronYuppie 10y ago

I can't edit my previous comment, but let me just drop this here - Canonical JUST released a new commercially supported distro of Kubernetes. https://insights.ubuntu.com/2016/09/27/canonical-expands-enterprise-container-portfolio/ https://insights.ubuntu.com/2016/09/27/canonical-expands-ent... Disclosure: I work at Google on Kubernetes.