5 ms·

You don’t really have no concern for the underlying hardware. You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, network transf

You don’t really have no concern for the underlying hardware. You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, network transfer speed, and many other things. It’s at the point of needing to scale horizontally where I begin to disagree with your premise. This is where you’ll typically get into proprietary and/or ugly offerings.

dijit 5y ago
>You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, You still do with kubernetes > network transfer speed, and many other things. No, you don't. There's no slider for "network performance" on GCP, Azure or AWS.
- nigma1337 5y ago
  There might not be on GCP, but there are on other providers (alibaba cloud comes to mind)
- lima 5y ago
  Network performance is tied to the instance type on GCP, AWS and presumably Azure.
  - dijit 5y ago
    But there’s no slider. Typically you slide the instance size for other reasons. Here’s the thing: either you care about it (and you can game the sizing of the instance) or you dont and you run kubernetes. But you if you don’t care then it doesn’t matter. There’s no slider for you to care about. It is not extra overhead.
    - nostrebored 5y ago
      why is this slider important? You’ve picked something very arbitrary here
      - dijit 5y ago
        Uh. Because the parent said that kubernetes and VMs are different because "with VMs you have to configure things [..] like networking performance". But you configure the exact same things as with VMs and kubernetes. Network performance (as per OP) is not configurable on either. You just accept whatever accidental default you happen to have, it's not a conscious decision people are making, and it's an awkward assumption to say that you have to think about it. Because if you have to think about it: that doesn't go away with kubernetes anyway: if anything it probably gets worse.
        orf 5y ago
        Uh, no. If network performance is an issue then you configure some labels (slow, medium, mega-fast). You then launch your services on “hardware with network:slow” labels, and new instances will be brought up based on the labels it needs. Even better: you define a “bandwidth” resource and each service requests a slice of that. Kubernetes takes care of the box packing. If you care so much about it you can then enforce that in a number of different, flexible ways depending on your infrastructure or requirements. At the end of the day it’s no different to CPU, memory or GPU requests.
        dijit 5y ago
        Leaving aside the fact that I don’t believe anyone does this. You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs.
        orf 5y ago
        > Leaving aside the fact that I don’t believe anyone does this. Everyone who uses GPUs with Kubernetes does exactly this. GPUs are not a native thing to Kubernetes. > You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs You are of course entirely missing the point, and I’m not sure if you’re doing it on purpose or not. You have 100 units of work that you need to run. A unit of work is some “thing” that needs a certain number of CPU cores, memory, GPUs and other user-defined resources. Each unit of work also needs an individual identity, distinct from other units of work. Go and code something to run that workload on the minimum number of cloud VMs, taking into account cost and your own user-defined scaling policies, minimizing the amount of unused resources. Now make it handle adapting to changes in the quantity and definitions of those units of work. Now make it handle over-committing, allowing units of work to have hard and soft limits that depend on the utilization of the underlying hardware. Now make it provision some form of secure identity per unit of work. After you’ve spent time coding that, you’ll realize that: 1. It’s hard 2. You’ve re-invented part of Kubernetes 3. Your implementation is shit 4. It’s very much not “the same things you can configure on cloud VMs”
- parkingrift 5y ago
  >No, you don't. There's no slider for "network performance" on GCP, Azure or AWS. Who said there was a slider? Network performance is one of the key filters on every major cloud provider. Not every instance type has the same network performance. >You still do with kubernetes Sort of. It can be way more abstracted away. What's the minimum I need to run a node? Okay great, now run as many nodes as needed, when needed. To set that kind of thing up with bare metal on AWS, for example, would require getting into some proprietary offerings and/or absurd complexity. I had to actually go and look up with our default instance type was for our cluster. It's a rather useless fact since it doesn't much matter compared to the number of active nodes. That's not true at all if you're directly managing VMs. I'd absolutely never trade the complexity of kubernetes for the complexity of self-managing a horizontally scalable bare metal VM implementation. However, some people (obviously) disagree with that. To each their own.

dijit 5y ago

>You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, You still do with kubernetes > network transfer speed, and many other things. No, you don't. There's no slider for "network performance" on GCP, Azure or AWS.

nigma1337 5y ago
There might not be on GCP, but there are on other providers (alibaba cloud comes to mind)
lima 5y ago
Network performance is tied to the instance type on GCP, AWS and presumably Azure.
- dijit 5y ago
  But there’s no slider. Typically you slide the instance size for other reasons. Here’s the thing: either you care about it (and you can game the sizing of the instance) or you dont and you run kubernetes. But you if you don’t care then it doesn’t matter. There’s no slider for you to care about. It is not extra overhead.
  - nostrebored 5y ago
    why is this slider important? You’ve picked something very arbitrary here
    - dijit 5y ago
      Uh. Because the parent said that kubernetes and VMs are different because "with VMs you have to configure things [..] like networking performance". But you configure the exact same things as with VMs and kubernetes. Network performance (as per OP) is not configurable on either. You just accept whatever accidental default you happen to have, it's not a conscious decision people are making, and it's an awkward assumption to say that you have to think about it. Because if you have to think about it: that doesn't go away with kubernetes anyway: if anything it probably gets worse.
      - orf 5y ago
        Uh, no. If network performance is an issue then you configure some labels (slow, medium, mega-fast). You then launch your services on “hardware with network:slow” labels, and new instances will be brought up based on the labels it needs. Even better: you define a “bandwidth” resource and each service requests a slice of that. Kubernetes takes care of the box packing. If you care so much about it you can then enforce that in a number of different, flexible ways depending on your infrastructure or requirements. At the end of the day it’s no different to CPU, memory or GPU requests.
        dijit 5y ago
        Leaving aside the fact that I don’t believe anyone does this. You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs.
        orf 5y ago
        > Leaving aside the fact that I don’t believe anyone does this. Everyone who uses GPUs with Kubernetes does exactly this. GPUs are not a native thing to Kubernetes. > You just maybe proved the point that I originally asserted: the things you configure on kubernetes are the same things you configure on cloud VMs You are of course entirely missing the point, and I’m not sure if you’re doing it on purpose or not. You have 100 units of work that you need to run. A unit of work is some “thing” that needs a certain number of CPU cores, memory, GPUs and other user-defined resources. Each unit of work also needs an individual identity, distinct from other units of work. Go and code something to run that workload on the minimum number of cloud VMs, taking into account cost and your own user-defined scaling policies, minimizing the amount of unused resources. Now make it handle adapting to changes in the quantity and definitions of those units of work. Now make it handle over-committing, allowing units of work to have hard and soft limits that depend on the utilization of the underlying hardware. Now make it provision some form of secure identity per unit of work. After you’ve spent time coding that, you’ll realize that: 1. It’s hard 2. You’ve re-invented part of Kubernetes 3. Your implementation is shit 4. It’s very much not “the same things you can configure on cloud VMs”
parkingrift 5y ago
>No, you don't. There's no slider for "network performance" on GCP, Azure or AWS. Who said there was a slider? Network performance is one of the key filters on every major cloud provider. Not every instance type has the same network performance. >You still do with kubernetes Sort of. It can be way more abstracted away. What's the minimum I need to run a node? Okay great, now run as many nodes as needed, when needed. To set that kind of thing up with bare metal on AWS, for example, would require getting into some proprietary offerings and/or absurd complexity. I had to actually go and look up with our default instance type was for our cluster. It's a rather useless fact since it doesn't much matter compared to the number of active nodes. That's not true at all if you're directly managing VMs. I'd absolutely never trade the complexity of kubernetes for the complexity of self-managing a horizontally scalable bare metal VM implementation. However, some people (obviously) disagree with that. To each their own.