9 ms·

Autoscale Kubernetes workloads on any cloud using any event

55 points by innovate 2y ago

innovate 2y ago
Kedify has recently launched a SaaS-based Kubernetes event-driven autoscaling service that is powered by the popular OSS project KEDA.
anonymous_union 2y ago
kubernetes is dying, isn't it?
- lifty 2y ago
  Yes, just like Linux.
  - zbynek 2y ago
    Linux is dying? I though that year 2024 is the year of Linux on the desktop!
    - 7thpower 2y ago
      No it’s 2025, but definitely going to happen.
    - bigstrat2003 2y ago
      Sadly yes. Netcraft confirms it.
    - vidarh 2y ago
      I just realised I've used Linux on the desktop for 30 years this year.
- nilamo 2y ago
  Commenting so I can see the replies later...
- dijit 2y ago
  Kubernetes is a framework, it'll take a long time to die, it will likely contort itself into fitting whatever paradigm is needed. However, I wonder what you mean? Kubernetes from where I sit has almost complete ubiquity across most companies. Even in places where it's a poor fit.
  - vidarh 2y ago
    People starting to put abstractions over it means a) there's a chance people will start asking for a given abstraction rather than Kubernetes, and not care if that abstraction eventually subsumes or replaces Kubernetes, b) at least some people think Kubernetes is enough of a nuisance to deal with to be looking for alternatives. Whether that means Kubernetes is dying, I'm not so sure. But Kubernetes is extremely complex for a lot of workloads that it's total overkill for, so I'm not surprised people are looking for options.
- remram 2y ago
  I'm not sure what in the article makes you say that? Anyway, the answer is no.
- kobalsky 2y ago
  Could you explain how you arrive to that conclusion from seeing some proyect offering an alternative autoscaling engine? The only issue I have with the default HorizontalPodAutoscaler is that I cannot scale down to 0 when some processing queues are empty. Other than that, we have shrines erected to k8s.
acedTrex 2y ago
so basically this is a gui abstraction over "kubectl apply -f scaledObject.yaml" ...
- mplewis 2y ago
  Not really.
- zbynek 2y ago
  It is a single place for installation, updates, security fixes and the whole administration of KEDA across the whole fleet of k8s clusters. Very soon there will be configuration optimization and recommender, dynamic scaling policies and much more. And yeah, also gui abstraction over `kubectl...` is there :)
- deleted 2y ago
  [deleted]
Aldipower 2y ago
Who needs autoscaling? I mean this as a serious question. Has somebody a real story where autoscaling helped out the company or product? If you have the hardware resources, why not just scale up from the beginning on? If you do not have the resources, you need a lot of money anyways to pay the upscaled rent afterwards.
- kube-system 2y ago
  1. Scaling up beyond the level of resources you anticipated may help you maintain better uptime. This could be useful if uptime is very valuable for you. 2. Hopefully, if you scale up, you can also scale down, which will save you money when you don't need to rent the resources.
- liveoneggs 2y ago
  In the cloud you pay by the minute (or less) so scaling down saves money. Every single day my services scale up during peak times and down in the evenings.
- dijit 2y ago
  I gave a talk on this[0], but I've had some moderate success doing autoscaling based on region for AAA always-online games. That said, you could conceivably live at a higher abstraction. Take dev environments for example. Ideally the team working on infra problems does not need to care how many versions of a backend are operating on the dev environment. The only thing infra needs to take into account the requested resources. Perverse incentives on wasting resources aside, it's nice when you can have fewer variables in your mind when focusing on your responsibility areas, it allows deeper intuition and creativity - at the sacrifice of some cross cutting creativity across teams. [0]: https://sh.drk.sc/~dijit/devfest2019-msv.pdf https://sh.drk.sc/~dijit/devfest2019-msv.pdf
  - deathanatos 2y ago
    > Ideally the team working on infra problems does not need to care how many versions of a backend are operating on the dev environment. > The only thing infra needs to take into account the requested resources. > Perverse incentives on wasting resources aside (I do infra.) That's like, 95% of the problem. AFAICT, most devs have absolutely no idea how powerful a computer is. My last change was to resize a 400 core, 800 GiB set of compute into a 100 core, 150 GiB set. It was just ludicrously over-provisioned, because the dev teams isn't incentivized to care at all. (…sadly, I'm not allowed to go out an hire a dev now, even though I literally just saved that amount of money in cloud costs…) (It's still over-provisioned, but that was the easy "we can lop this compute off and I promise you you won't notice.) The economics/incentives at play are the hard part. Getting management to not look at infra for "ehrmagerd the cloud bill" but instead devote dev time into getting them to dig into "why is this app, which ostensibly just shuffles JSON about the landscape, using 8 cores and all the RAM?" is … tough. And not what I signed up for in SWE, damn it. The other way is equally bad: devs find they've run out of resources? Knee-jerk is "resize compute upwards" not some introspection of "wait, what is a reasonable amount of CPU use for JSON shuffling?" Usage graphing is the other tool that really puts some devs' work in a rather bad light: resource requests of like 20 CPU, but the usage graph says "0.02 CPU". So … at least the code's not inefficient, but the requested resources are wasted.
benced 2y ago
The march away from companies directly managing Kubernetes to Kubernetes being the layer that every future abstraction will be built on continues.
fbergen 2y ago
What part of the stack takes the majority of the time for spawning a new replica? Is it the time to boot a VM/environment or is it application doing bunch of init work setting up connections etc?

55 points by innovate 2y ago

Kedify has recently launched a SaaS-based Kubernetes event-driven autoscaling service that is powered by the popular OSS project KEDA.

anonymous_union 2y ago

kubernetes is dying, isn't it?

lifty 2y ago
Yes, just like Linux.
- zbynek 2y ago
  Linux is dying? I though that year 2024 is the year of Linux on the desktop!
  - 7thpower 2y ago
    No it’s 2025, but definitely going to happen.
  - bigstrat2003 2y ago
    Sadly yes. Netcraft confirms it.
  - vidarh 2y ago
    I just realised I've used Linux on the desktop for 30 years this year.
nilamo 2y ago
Commenting so I can see the replies later...
dijit 2y ago
Kubernetes is a framework, it'll take a long time to die, it will likely contort itself into fitting whatever paradigm is needed. However, I wonder what you mean? Kubernetes from where I sit has almost complete ubiquity across most companies. Even in places where it's a poor fit.
- vidarh 2y ago
  People starting to put abstractions over it means a) there's a chance people will start asking for a given abstraction rather than Kubernetes, and not care if that abstraction eventually subsumes or replaces Kubernetes, b) at least some people think Kubernetes is enough of a nuisance to deal with to be looking for alternatives. Whether that means Kubernetes is dying, I'm not so sure. But Kubernetes is extremely complex for a lot of workloads that it's total overkill for, so I'm not surprised people are looking for options.
remram 2y ago
I'm not sure what in the article makes you say that? Anyway, the answer is no.
kobalsky 2y ago
Could you explain how you arrive to that conclusion from seeing some proyect offering an alternative autoscaling engine? The only issue I have with the default HorizontalPodAutoscaler is that I cannot scale down to 0 when some processing queues are empty. Other than that, we have shrines erected to k8s.

acedTrex 2y ago

so basically this is a gui abstraction over "kubectl apply -f scaledObject.yaml" ...

mplewis 2y ago
Not really.
zbynek 2y ago
It is a single place for installation, updates, security fixes and the whole administration of KEDA across the whole fleet of k8s clusters. Very soon there will be configuration optimization and recommender, dynamic scaling policies and much more. And yeah, also gui abstraction over `kubectl...` is there :)
deleted 2y ago
[deleted]

Aldipower 2y ago

Who needs autoscaling? I mean this as a serious question. Has somebody a real story where autoscaling helped out the company or product? If you have the hardware resources, why not just scale up from the beginning on? If you do not have the resources, you need a lot of money anyways to pay the upscaled rent afterwards.

kube-system 2y ago
1. Scaling up beyond the level of resources you anticipated may help you maintain better uptime. This could be useful if uptime is very valuable for you. 2. Hopefully, if you scale up, you can also scale down, which will save you money when you don't need to rent the resources.
liveoneggs 2y ago
In the cloud you pay by the minute (or less) so scaling down saves money. Every single day my services scale up during peak times and down in the evenings.
dijit 2y ago
I gave a talk on this[0], but I've had some moderate success doing autoscaling based on region for AAA always-online games. That said, you could conceivably live at a higher abstraction. Take dev environments for example. Ideally the team working on infra problems does not need to care how many versions of a backend are operating on the dev environment. The only thing infra needs to take into account the requested resources. Perverse incentives on wasting resources aside, it's nice when you can have fewer variables in your mind when focusing on your responsibility areas, it allows deeper intuition and creativity - at the sacrifice of some cross cutting creativity across teams. [0]: https://sh.drk.sc/~dijit/devfest2019-msv.pdf https://sh.drk.sc/~dijit/devfest2019-msv.pdf
- deathanatos 2y ago
  > Ideally the team working on infra problems does not need to care how many versions of a backend are operating on the dev environment. > The only thing infra needs to take into account the requested resources. > Perverse incentives on wasting resources aside (I do infra.) That's like, 95% of the problem. AFAICT, most devs have absolutely no idea how powerful a computer is. My last change was to resize a 400 core, 800 GiB set of compute into a 100 core, 150 GiB set. It was just ludicrously over-provisioned, because the dev teams isn't incentivized to care at all. (…sadly, I'm not allowed to go out an hire a dev now, even though I literally just saved that amount of money in cloud costs…) (It's still over-provisioned, but that was the easy "we can lop this compute off and I promise you you won't notice.) The economics/incentives at play are the hard part. Getting management to not look at infra for "ehrmagerd the cloud bill" but instead devote dev time into getting them to dig into "why is this app, which ostensibly just shuffles JSON about the landscape, using 8 cores and all the RAM?" is … tough. And not what I signed up for in SWE, damn it. The other way is equally bad: devs find they've run out of resources? Knee-jerk is "resize compute upwards" not some introspection of "wait, what is a reasonable amount of CPU use for JSON shuffling?" Usage graphing is the other tool that really puts some devs' work in a rather bad light: resource requests of like 20 CPU, but the usage graph says "0.02 CPU". So … at least the code's not inefficient, but the requested resources are wasted.

benced 2y ago

The march away from companies directly managing Kubernetes to Kubernetes being the layer that every future abstraction will be built on continues.

fbergen 2y ago

What part of the stack takes the majority of the time for spawning a new replica? Is it the time to boot a VM/environment or is it application doing bunch of init work setting up connections etc?