Originally we got a ton of pushback on it as people didn't get it. Had to hack it into docker with pause container. It was only after there were common sidecars that it clicked for folks. Docker issue from 2014 is still open.https://github.com/moby/moby/issues/8781 …
-
-
Replying to @jbeda @stephenaugustus and
Borg "alloc" -> Omega "scheduling unit" -> Kubernetes "pod". The name itself was from a brainstorm. Docker's logo is a whale. A group of whales is called a ... Also, it was short. The network model was explored in Borg a few years prior, but wasn't feasible at the time.
8 replies 41 retweets 192 likes -
Anyone know when alloc was born? Was this capability an epiphany or an accretion? If this isn’t lost to history, I would love to do the archeology.
4 replies 2 retweets 7 likes -
Replying to @littleidea @thockin and
The borg folks would know better but here is my guess -- alloc was originally there to create a kind of "mini personal borg" that you could schedule into. It was a bit of a recursive concept. You could create the alloc to set aside space and then schedule into it later.
3 replies 0 retweets 8 likes -
Replying to @jbeda @littleidea and
But the usage was evolved was that folks would put coupled pairs of services in there. The canonical examples were a log saver and a server or a search server and a search data loader. You could use constraints to ensure that one of each ended up in each alloc.
2 replies 0 retweets 6 likes -
Replying to @jbeda @littleidea and
But the behavior here was somewhat confusing. Allocs were indexed (similar to k8s StatefulSets) and the things that scheduled into them were indexed too. Because there was this recursive scheduling system it woldn't line up.
1 reply 0 retweets 2 likes -
Replying to @jbeda @littleidea and
Specifically: alloc #3 might have logsaver #10 and server #8. IIRC this could cause problems when doing rolling upgrades. Over time this pairing pattern was the dominate use of alloc and provisions were made so that all of the indexes lined up cleanly.
2 replies 0 retweets 5 likes -
Replying to @jbeda @littleidea and
Pod skilled that "sub allocation" capability and instead went strait to a clearer concept of having explicitly co-located resources.
2 replies 0 retweets 5 likes -
Replying to @jbeda @littleidea and
Another thing -- at the time Borg generally didn't use linux namespaces. As such the network was shared across the node, not across the alloc/container. Ports were assigned to containers and they were kept honest about which ports they were allowed to use.
2 replies 1 retweet 7 likes -
Replying to @jbeda @littleidea and
Because of this the idea of creating an IP per pod/alloc only came to fruition with Kubernetes. (Above Tim says that there were experiments around this before k8s but I never heard about those so TIL!)
2 replies 0 retweets 3 likes
Replying to @jbeda @littleidea and
Yes, there were other capabilities that required IPs rather than reusing host networking.
8:52 PM - 7 Nov 2018
0 replies
0 retweets
3 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.