Accidental complexity, essential complexity, and Kubernetes

Re:Accidental complexity, essential complexity, and Kubernetes by zamalek on Monday September 05, 2022 @05:09PM (#32729513)

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.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by tsimionescu on Monday September 05, 2022 @05:14PM (#32729557)

Absolutely, but the context of the article was specifically Kubernetes.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by paulgb on Monday September 05, 2022 @08:47PM (#32731255)

In 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.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by samus on Tuesday September 06, 2022 @02:12AM (#32733538)

Containers are a construct created by employing cgroups + namespaces together. Namespaces provide isolations in terms of filesystem, network, users, processes, and probably more.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by paulgb on Tuesday September 06, 2022 @04:25AM (#32734420)

Yes, 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.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by samus on Tuesday September 06, 2022 @12:08PM (#32739113)

A 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.

[ Parent | on HN ]