5 ms·

I'm sure all this complexity makes sense for all sorts of reasons buried in the history of Kubernetes development at Google. "Things are the way they are becaus

I'm sure all this complexity makes sense for all sorts of reasons buried in the history of Kubernetes development at Google. "Things are the way they are because they got that way." The fact that so many other orgs, many of which are startups or just small to medium sized tech companies, use a system this complex is ludicrous to me.

jacques_chester 6y ago
Well, I might have designed it differently, but I wasn't there. For what it does, this architecture works well. More to the point: none of it is visible to end-users of Kubernetes. You send a Pod definition, some magic happens, pow! running software.
- tannhaeuser 6y ago
  Except when it doesn't, at which point you're lost.
  - jacques_chester 6y ago
    Well, like I said, I might have done it differently. But there's a consistent logic to how it works[0]. That carries a lot of water. [0] most folks emphasise the control loop aspect, I think it's more helpful to point to blackboard / tuple-space systems as prior art.
    - tannhaeuser 6y ago
      > I think it's more helpful to point to blackboard / tuple-space systems as prior art Ah, nevermind then, that gives me rest concerning the viability and transparency of it all.
      - jacques_chester 6y ago
        I'm glad I could help.
comfydragon 6y ago
The practical change that's happening is that in future versions of Kubernetes, they're removing support for using a shim for telling the Docker daemon to run containers, and focusing on just using containerd (which Docker uses under the covers anyway). It's kind of like if you had a shell script to launch programs, and it used to move the mouse to press icons, but now you've deprecated that and will only run programs directly.
lima 6y ago
Hi! Small tech company that uses k8s here. Much of the complexity is irreducible and has to go somewhere, and it's much better to have it in a single, stateless, well-defined place that's also easy too introspect. I've seen way too many Ansible nightmares grown out of deceptively "simple" mutable VM deployments. k8s makes our life so much easier because it eliminates a whole bunch of other complexity. Easily reproducible development environments, workload scheduling, sane config management...
- LimaBearz 6y ago
  My favorite opposite of this is companies running k8s, using a ansible to build state on launch..
mplewis 6y ago
You don't need the complexity until you do, and then you're facing a rewrite into the complex system. Defining a deployment in YAML isn't really all that hard.
yipbub 6y ago
It's a generic API for automated provisioning. It asks you to make some decisions up front (what do you want to do when an instance goes down or has a new version available), and lets you forgo making some (like which nodes your instance should run on). It's not more complex. If you're small, the overhead is probably not worth it. If you're big enough, you manage the k8s control plane, and you don't have to manage your tenants infra. Is a programming language too complex for hello world? Perhaps, but that's not all it does.

jacques_chester 6y ago

Well, I might have designed it differently, but I wasn't there. For what it does, this architecture works well. More to the point: none of it is visible to end-users of Kubernetes. You send a Pod definition, some magic happens, pow! running software.

tannhaeuser 6y ago
Except when it doesn't, at which point you're lost.
- jacques_chester 6y ago
  Well, like I said, I might have done it differently. But there's a consistent logic to how it works[0]. That carries a lot of water. [0] most folks emphasise the control loop aspect, I think it's more helpful to point to blackboard / tuple-space systems as prior art.
  - tannhaeuser 6y ago
    > I think it's more helpful to point to blackboard / tuple-space systems as prior art Ah, nevermind then, that gives me rest concerning the viability and transparency of it all.
    - jacques_chester 6y ago
      I'm glad I could help.

comfydragon 6y ago

The practical change that's happening is that in future versions of Kubernetes, they're removing support for using a shim for telling the Docker daemon to run containers, and focusing on just using containerd (which Docker uses under the covers anyway). It's kind of like if you had a shell script to launch programs, and it used to move the mouse to press icons, but now you've deprecated that and will only run programs directly.

lima 6y ago

Hi! Small tech company that uses k8s here. Much of the complexity is irreducible and has to go somewhere, and it's much better to have it in a single, stateless, well-defined place that's also easy too introspect. I've seen way too many Ansible nightmares grown out of deceptively "simple" mutable VM deployments. k8s makes our life so much easier because it eliminates a whole bunch of other complexity. Easily reproducible development environments, workload scheduling, sane config management...

LimaBearz 6y ago
My favorite opposite of this is companies running k8s, using a ansible to build state on launch..

mplewis 6y ago

You don't need the complexity until you do, and then you're facing a rewrite into the complex system. Defining a deployment in YAML isn't really all that hard.

yipbub 6y ago

It's a generic API for automated provisioning. It asks you to make some decisions up front (what do you want to do when an instance goes down or has a new version available), and lets you forgo making some (like which nodes your instance should run on). It's not more complex. If you're small, the overhead is probably not worth it. If you're big enough, you manage the k8s control plane, and you don't have to manage your tenants infra. Is a programming language too complex for hello world? Perhaps, but that's not all it does.