3 ms·
I think they mean different things to different people. From the problems I have faced with customer-controlled OS installations, the biggest thing that they of
by zamalek 4y ago
I think they mean different things to different people. From the problems I have faced with customer-controlled OS installations, the biggest thing that they offer is configuration isolation (or rather independence). I have seen some truly crazy shit done by customer's administrators and even crazier shit done by management software that they install. Taking away that autonomy is huge.
- tsimionescu 4y agoAbsolutely, but the context of the article was specifically Kubernetes.
- paulgb 4y agoIn the context of Kubernetes, what do containers have to do with cgroups? I get that container runtimes typically provide a nicer interface for setting them up, but Kubernetes doesn’t use those interfaces anyway. If it was just about cgroups, they could have just run a regular process in cgroups.
- samus 4y agoContainers are a construct created by employing cgroups + namespaces together. Namespaces provide isolations in terms of filesystem, network, users, processes, and probably more.
- paulgb 4y agoYes, but those are features of Linux that containers use; containers don’t have exclusive use of them. My original point was: > Containers were a great advance, but much of their complexity falls into the “accidental” category. There’s no fundamental reason that I should need anything except my compiler to produce a universally deployable unit of code. I stand by that. We might just be arguing semantics about whether that unit of code would be called a “container” or not. I’m leaving open the possibility that it would be (say) a WebAssembly module or static binary.
- samus 4y agoA container can also give your application assurance that the file system looks a certain way. But you are right that you can get pretty far with bundling dependencies and assets and configuring all nontrivial paths with environment variables. However, the choice of containers for Kubernetes is a pretty fundamental one. It simplifies distribution of deployables to a single workflow also for programming languages that don't offer monolithic deployables, to legacy application not originally intended for Kubernetes, or that don't follow the 12 factor app principles.