Live data from Hacker News

Into the Borg – SSRF inside Google production network

opnsec.com

51–60 of 79 posts

Re: Into the Borg – SSRF inside Google production network

#51

Earlier quoted context omitted.

> I don't disagree that Kubernetes is not positioned to be a replacement for Borg Good. Because that was my point, but the verbiage “don’t disagree” says a lot. We agree, except for the timeline. We will all be dead before Borg is replaced with Kubernetes. You can take that to the bank. Kinda weird to fire up a throwaway, presumably to conceal your Google credentials, then attack a Xoogler who used to work on Borg SR…

>Good. Because that was my point. Fair enough, but you said a whole lot of other crap that is very much misleading in my opinion, and I was addressing all of that. >It can only span multiple clouds now because other clouds had to ship Kubernetes See, this is the kind of thing that makes me treat this as FUD rather than just criticism. I was running Kubernetes on AWS long before Amazon offered a service for it. If Kub…

I’m talking about competitors to GKE, which is the entire thesis of that point and that you refuse to acknowledge, which is why you’re knee jerking FUD. I’m a solo developer. I make a Kubernetes app. Do I think Kubernetes is great if I have to build a CloudFormation thing to spin up all of its infrastructure and run it myself, or would I rather pay big company to do it?

The latter.

GKE. EKS/etc. They exist for that use case because that’s where the lock in happens. Now you’re a Kubernetes deployable and too dug in to get off. For a while, your only option was GKE or (God help you, at first) running it yourself. Now other vendors have stepped up to compete, which is the exact situation Google wanted. They shook out the Kubernetes issues with the early adopters with ops experience, then went after pure developers, and had first mover advantage on that customer until the others were forced to respond. I wish I could tell you how many teams I’ve consulted with who when I say “where are we deploying?” immediately say Kubernetes on GKE without a second thought. That is what Google wanted.

This doesn’t take a rocket scientist to figure out, but if you work on Kubernetes I wouldn’t expect you to know this strategy firsthand. It would come from Diane or her people. You’re just having a hootin’ and hollerin’ grand old time building some open source software with a foundation (ooo! So OpenStack!) and mindshare and all the cool kids surrendering their startup to go all in on Kubernetes. Meanwhile, you’re supported by Google, and in fact were conceptualized, to drive sales to Google Cloud. Sorry.

Did you ever ask yourself what the higher level point of Kubernetes is? Like, why throw an entire team on shipping an entire new infrastructure category just to open source it? To make operations better for the industry? Google competes on operations. To use public company capital to chase a hobby? Think about the leadership decision to initiate Kubernetes, and why it was made.

> but you said a whole lot of other crap that is very much misleading in my opinion

The entire comment was quite clearly in support of Google’s decision calculus to not replace Borg. Your rebuttals are honestly more misleading, in my opinion, than my points, because you’re personally wrapped up in it and that’s coming across.

Re: Into the Borg – SSRF inside Google production network

#52

Earlier quoted context omitted.

You heard wrong. There’s a meme out there, helpfully nudged along by Google, that Kubernetes is Borg “done right” and the successor. It’s even mentioned in this article. Neither of those things are true. Not even remotely. Please pass along to everyone to stop repeating the meme, because it distracts from Kubernetes’ true purpose, which is to lock people into GKE and force competitors to ship a Kubernetes runtime to…

Thanks so much for the detailed clarification! The k8s-as-Borg-successor meme is even perpetuated on the Borg paper, so I guess that's why I repeated it :P If I may ask, is it primarily just reliance on publicly-available infrastructural pieces that hobbles K8s in terms of scalability? i.e. that the problem is more about ecosystem than architecture, because the industry just doesn't have things like (or as "good" as)…

In this thread there is a repeated meme of "Borg is way more scalable than Kubernetes, and will always be so".

But this ignores a lot of the history of Borg. When Borg was first created, it was not nearly as scalable as its current incarnation. We hit scalability bugs and limitations all the time! (I was working on a team which was exploring the scalability limits of MapReduce, which was often very good at finding the limits in Borg and other systems it interacted with.)

Over the years many many Borg engineers have taken on many projects, both in solving bugs and rearchitecting major pieces of Borg with the intention of making it scale better (to run more jobs at once, utilize machines better, increase the degree of failure and performance isolation between jobs, and scale up to manage larger clusters of machines). Many of the lessons learned went into the design of Kubernetes, but Kubernetes is still much newer than Borg, which means it has fewer years of the "identify a scalability bug and squash it" feedback loop.

What is really needed to drive that loop is a major customer pushing the boundaries of scalability and identifying bugs. My guess (from the outside) is that the main users of Kubernetes have been pushing the limits in other directions, which has meant the team has been prioritizing other things (such as improving usability, and adding features) in their development efforts.

Re: Into the Borg – SSRF inside Google production network

#53
post #52

Earlier quoted context omitted.

Thanks so much for the detailed clarification! The k8s-as-Borg-successor meme is even perpetuated on the Borg paper, so I guess that's why I repeated it :P If I may ask, is it primarily just reliance on publicly-available infrastructural pieces that hobbles K8s in terms of scalability? i.e. that the problem is more about ecosystem than architecture, because the industry just doesn't have things like (or as "good" as)…

In this thread there is a repeated meme of "Borg is way more scalable than Kubernetes, and will always be so". But this ignores a lot of the history of Borg. When Borg was first created, it was not nearly as scalable as its current incarnation. We hit scalability bugs and limitations all the time! (I was working on a team which was exploring the scalability limits of MapReduce, which was often very good at finding th…

Borg will remain orders of magnitude beyond Kubernetes until Kubernetes is completely rearchitected. It’s not scalability bugs. It’s decisions regarding how the cluster maintains state that hamstring it, and that’s so fundamental to everything it’s not a find/squish loop.

As I said in my comment, those major customers (one personal experience, three anecdotally, eight or nine I’ve consulted with) have quietly ruled out Kubernetes, either by trying it or prying it apart and deciding not to try it. That feedback isn’t coming. At Borg scale, Kubernetes is very much considered a nonstarter.

Re: Into the Borg – SSRF inside Google production network

#54

Earlier quoted context omitted.

>Good. Because that was my point. Fair enough, but you said a whole lot of other crap that is very much misleading in my opinion, and I was addressing all of that. >It can only span multiple clouds now because other clouds had to ship Kubernetes See, this is the kind of thing that makes me treat this as FUD rather than just criticism. I was running Kubernetes on AWS long before Amazon offered a service for it. If Kub…

I’m talking about competitors to GKE, which is the entire thesis of that point and that you refuse to acknowledge, which is why you’re knee jerking FUD. I’m a solo developer. I make a Kubernetes app. Do I think Kubernetes is great if I have to build a CloudFormation thing to spin up all of its infrastructure and run it myself, or would I rather pay big company to do it? The latter. GKE. EKS/etc. They exist for that u…

>Do I think Kubernetes is great if I have to build a CloudFormation thing to spin up all of its infrastructure and run it myself,

Yes.

>or would I rather pay big company to do it?

Also yes. The two aren't mutually exclusive.

Come on, you've used Borg. You wanna volunteer to going back to just using machines and VMs by hand, or worse, wiring up a complex and unreadable (Ansible|SaltStack|Chef|Puppet) playbook to set everything up?

No. This is why in the early days I was indeed running Kubernetes on AWS, by hand. As the tooling improved it only got better. I honestly wanted to have alternative choices, but Docker continually missed the point with Swarm and I just gave up on it.

>Your rebuttals are honestly more misleading, in my opinion, than my points, because you’re personally wrapped up in it and that’s coming across.

You are projecting wildly on this one.

Re: Into the Borg – SSRF inside Google production network

#55
post #38

Earlier quoted context omitted.

To be fair to @elvinyung, a good chunk of your points five and six could be summarized at a high level as "switching costs".

I suppose that’s fair, but I’d argue against switching even being a primary motivation for anyone at Google, which is why I don’t think of it that way. You do have a point, though. Without intimate knowledge of Borg, I can understand the successor discussion. With knowledge of what changed (i.e., was getting rid of borgmaster really that important to sacrifice that much perfwise?) I can’t even remotely fathom any pur…

I probably don't - my experience is very one-sided, as I've never tried Kubernetes.

Re: Into the Borg – SSRF inside Google production network

#56

Earlier quoted context omitted.

You heard wrong. There’s a meme out there, helpfully nudged along by Google, that Kubernetes is Borg “done right” and the successor. It’s even mentioned in this article. Neither of those things are true. Not even remotely. Please pass along to everyone to stop repeating the meme, because it distracts from Kubernetes’ true purpose, which is to lock people into GKE and force competitors to ship a Kubernetes runtime to…

[Disclaimers: I worked on Borg and Omega, and currently work on Kubernetes/GKE. Everything here is my personal opinion.] There's a lot to unpack here, but I'll do my best. I don't see Kubernetes locking people into GKE. There's an extensive conformance program ( https://github.com/cncf/k8s-conformance ) administered by the CNCF. AWS and Azure both have certified hosted Kubernetes offerings. Portability is in Google's…

As a Xoogler myself, I have always wondered about the logic of "we can't open source X because it uses too many libraries and is too integrated". The obvious answer is, OK, open source the libraries and refactor the integrations to make them more flexible.

Reimplementing all of Borg from scratch seems crazy to me given the huge effort that went into it. Does Google want an open source cluster infrastructure or not? If yes, in what universe is it less effort to write a totally new one from scratch vs just progressively open sourcing things?

Re: Into the Borg – SSRF inside Google production network

#57
post #56

Earlier quoted context omitted.

[Disclaimers: I worked on Borg and Omega, and currently work on Kubernetes/GKE. Everything here is my personal opinion.] There's a lot to unpack here, but I'll do my best. I don't see Kubernetes locking people into GKE. There's an extensive conformance program ( https://github.com/cncf/k8s-conformance ) administered by the CNCF. AWS and Azure both have certified hosted Kubernetes offerings. Portability is in Google's…

As a Xoogler myself, I have always wondered about the logic of "we can't open source X because it uses too many libraries and is too integrated". The obvious answer is, OK, open source the libraries and refactor the integrations to make them more flexible. Reimplementing all of Borg from scratch seems crazy to me given the huge effort that went into it. Does Google want an open source cluster infrastructure or not? I…

What's the size of the transitive dependency graph of Borg? 10MLOC? 50MLOC? 100MLOC? I have no idea. But it's a lot of code no matter what. Open sourcing that much code is a huge undertaking, unless you're just planning to throw it over the wall with no expectation of external people working on it.

On the other hand starting from scratch you get to grow the community and the codebase in lockstep.

Re: Into the Borg – SSRF inside Google production network

#58
post #12

> Google is still relying on Borg for its internal production infrastructure, but I can tell you it’s not because of the design of Borg interfaces! No matter how spartan, the Borg status pages are more helpful than most Kubernetes UIs out there when it comes to debugging a problem in depth, i.e. past CPU and memory graphs. Part of that is made possible by applications exposing debugging endpoints and telling Borg abo…

Yeah, I would kill for the k8s pod contract to have something like the borg status line.

As a matter of post-SLA curiousity, what is in the status line?

Re: Into the Borg – SSRF inside Google production network

#59
post #56

Earlier quoted context omitted.

[Disclaimers: I worked on Borg and Omega, and currently work on Kubernetes/GKE. Everything here is my personal opinion.] There's a lot to unpack here, but I'll do my best. I don't see Kubernetes locking people into GKE. There's an extensive conformance program ( https://github.com/cncf/k8s-conformance ) administered by the CNCF. AWS and Azure both have certified hosted Kubernetes offerings. Portability is in Google's…

As a Xoogler myself, I have always wondered about the logic of "we can't open source X because it uses too many libraries and is too integrated". The obvious answer is, OK, open source the libraries and refactor the integrations to make them more flexible. Reimplementing all of Borg from scratch seems crazy to me given the huge effort that went into it. Does Google want an open source cluster infrastructure or not? I…

Indeed. The universe where you aren’t trying to replace Borg, and instead have other motives for conceiving of Kubernetes in the first place. That’s all I’m trying to say.

Hadoop is nowhere close to the original thinking behind MapReduce, and Kubernetes is nowhere close to the original thinking behind Borg. The difference is Yahoo! wrote one, and the other leads us to speculate about why they’d want to offer such a good concept to the world, then ship something that so spectacularly misses that mark, particularly scalewise, but get away with it because it’s Google doing it.

There are only a couple explanations, especially when you factor in that corporations always act in their interest. That’s not a moral dimension, that’s just how it works. What upside is there for Google having everyone do cluster orchestration the way they do? Really, I challenge you to think of one. When I was there, you couldn’t even say the word Borg externally (despite the original article not being the first security-based leak of it). Operations and engineering velocity was, and remains, a crucial competitive advantage for Google. Since I’ve left, there’s a clear shift toward teaching the industry how to do operations, from the Borg paper on through to the SRE book. Why? Why suddenly cede that competitive advantage, the ability to ship a whole production service in like, a weekend?

Because you do it poorly, drive people to Google Cloud because administering Kubernetes at any scale is like self-flagellating with a rake (don’t get me started and be satisfied that I’m speaking from ulcers here), and keep ahead of the competition who are forced to respond to GKE now that a whole community is clamoring for Docker in prod. It’s the only explanation that fits. Maybe it wasn’t even intentional, but it’s what has played out.

Another possible explanation is that Google wanted to end run Mesos, which was threatening to dominate until Kubernetes got a bunch of mindshare and venture capital. Mesos, with care and careful choice of schedulers, can be on the same field as Borg. Twitter is very happy with it at scales that would decimate Kubernetes, as well as many others I cannot name. Google’s VC endeavors have been dumping into Kubernetes startups, and now you don’t hear about Mesos any more. Just like Docker before it, we just can’t get enough bad operational systems as a profession, apparently.

My whole career I’ve been obsessed with high scale orchestration because it is a uniquely difficult problem. I saw Borg and went Jesus, we are all behind the curve as an industry. Then the first few releases of Kubernetes came out and I killed it dead with a few dozen nodes and moderate load. It’s gotten better, yes, but Borg has literally centuries of engineering in it, and a steering committee is going to push Kubernetes to OpenStack or Java status (I’d argue it’s already there, given that people are now shipping distributions of it). And now operations as a discipline suffers for it. I can’t get a SRE gig any more without a dev team who doesn’t need Kubernetes, at all, making it a showstopper to ship.

Kinda funny, by the way, that this thread has been off the front page for hours and is still active with new faces. I must have ruffled eng-misc. :)

Re: Into the Borg – SSRF inside Google production network

#60

Earlier quoted context omitted.

There's a lot of FUD in here, like suggesting that Google wouldn't use something written in Go for this purpose (lol,) suggesting an open source platform that can span multiple clouds is an attempt to lock people into GKE (lol 2x,) and suggesting that Kubernetes is "married" to Docker (CNI? CRI?) or isn't extensible (the entire gRPC/REST API? custom resources? device plugins?) People use Kubernetes for the ecosystem,…

> I don't disagree that Kubernetes is not positioned to be a replacement for Borg Good. Because that was my point, but the verbiage “don’t disagree” says a lot. We agree, except for the timeline. We will all be dead before Borg is replaced with Kubernetes. You can take that to the bank. Kinda weird to fire up a throwaway, presumably to conceal your Google credentials, then attack a Xoogler who used to work on Borg SR…

> It can only span multiple clouds now because other clouds had to ship Kubernetes.

This isn't true. People were running open-source Kubernetes on AWS and Azure before either provider had a hosted Kubernetes service. In fact back when GKE was the only hosted Kubernetes service, more companies were running Kubernetes on non-Google platforms than on GCP (https://www.cncf.io/blog/2017/12/06/cloud-native-technologie...).

[Disclaimer: I work on Kubernetes/GKE at Google.]

Post reply on HN