4 ms·

Depends what you mean by 'container runtime' or 'container orchestration tool'... For example, Google's Borg absolutely uses Linux namespacing for its workload

by q3k 5y ago

Depends what you mean by 'container runtime' or 'container orchestration tool'... For example, Google's Borg absolutely uses Linux namespacing for its workloads, and these workloads get scheduled automatically on arbitrary nodes, but this doesn't feel at all like Docker/OCI containers (ie., no whole-filesystem image, no private IP address to bind to, no UID 0, no control over passwd...). Instead, it feels much closer to just getting your binary/package installed and started on a traditional Linux server.

isseu 5y ago
Yeah was gonna post this. Not sure if is updated enough but it's worth reading the Borg paper https://research.google/pubs/pub43438/ https://research.google/pubs/pub43438/
sitkack 5y ago
Install debs into a dynamically provisioned container, it will feel similar.
deleted 5y ago
[deleted]
menage 5y ago
> no whole-filesystem image At least in the past, almost all jobs ran in their own private filesystem - it was stitched together in userspace via bind mounts rather than having the kernel do it with an overlayfs extracted from layer tar files (since overlayfs didn't exist back then), but the result was fairly similar. Most jobs didn't actually request any customization so they ended up with a filesystem that looked a lot like the node's filesystem but with most of it mounted read-only. But e.g. for a while anything running Java needed to include in their job definition an overlay that updated glibc to an appropriate version since the stock Google redhat image was really old.