Scaling Explained Through Kubernetes HPA, VPA, KEDA & Cluster Autoscaler
ฝัง
- เผยแพร่เมื่อ 7 ก.ค. 2024
- Discover the secrets behind effectively scaling your applications and servers with this dive into Kubernetes scaling mechanisms. This video demystifies the concepts of Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), Kubernetes Event-driven Autoscaling (KEDA), and Cluster Autoscaler. Learn when and how to use each tool, understand their differences, and catch a glimpse of real-world scenarios that showcase their capabilities.
#KubernetesScaling #PodAutoscaling #KubernetesTutorial #ClusterAutoscaler
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
🔗 Kubernetes: kubernetes.io
➡ Transcript and commands: devopstoolkit.live/kubernetes...
🎬 KEDA: Kubernetes Event-Driven Autoscaling: • KEDA: Kubernetes Event...
▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendar.app.google/Q9eaDUHN8... to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Scaling Introduction
01:04 Port (Sponsor)
02:08 Scaling Introduction (cont.)
05:38 Vertical Scaling Applications with VerticalPodAutoscaler
13:58 Horizontal Scaling Applications with HorizontalPodAutoscaler
16:04 Horizontal Scaling Applications with KEDA
18:38 Vertical Scaling Nodes
19:33 Horizontal Scaling Nodes Cluster Autoscaler
24:25 What to Use and When to Use It - วิทยาศาสตร์และเทคโนโลยี
I would like to see a video on dealing with SIGTERM signals. Also, I would be interested in learning how to implement services within a distributed system that can be started in any order. Fantastic video and please do keep them coming.
great stuff as always
I would really love to hear about graceful shutdowns, because we did that after implementing autoscaling, which was a pain we had in the last year. Pretty please from your fan.
Adding it to my to-do list...
@@DevOpsToolkit ❤️❤️
I use the Datadog operator that allows me to scale based on any metrics that I send to Datadog. Anyway, nice video 🙂
Hi Viktor thanks for another great video 🎉 I think that autoscaling is one of the most underestimated tasks in the journey towards kubernetes adoption. I've seen many companies struggling with pods restarting continuously, working for a while and then stopping and all sorts of problems which makes them wondering why they adopted kubernetes in the first place! Instead understanding these concepts is fundamental thanks for clarifying them!
I'd also like to see a video in graceful shutdown thank you
I'll work on it...
Interested in graceful shutdown sir!
Your book is one of the best out there. Thanks for sharing knowledge
What book is this? I must have missed it.
He was probably referencing leanpub.com/crossplane
Is there a very simple way to scale a homelab/non-production environment deploys to 0 when there is no traffic? Yet I found three：traefik+sablier，greenkeytech/zero-pod-autoscaler， ctrox/zeropod.
Scaling to zero is easy. Scaling back up when a request comes in is a challenge. Try knative.
It would be nice if there were a distributed possibly global and sharable operating system to abstract, reuse and resource the various hardware systems, architectures and providers. And some economic model to make it more affordable for everyone. I will try to learn more; try to do that or find something that does already. I want to create a system that carefully applies my focus; then start creating on that.
That is effectively kubernetes.
@@DevOpsToolkit Does it have a global provisioning system? Idea: There is a service that tracks and manages interaction with the providers. And then schedules the access to those provisions. Then each of the interfaces of the OS each developer-user is running has an availability service. Then the developers just use some language to denote the microservice and write their code for each one. Then they publish their microservice or application on the OS's web. Maybe it has some kind of address on the OS's web, and then can be reused by others if its very similar or same as used in many other application. The microservice which are in high demand might be subsidised. Some system groups similar microservice and makes suggestion based on performance. Then some kind of application marketplace helps further even out the costs. Then maybe a user-consumer platform to access them.
# til
The most annoying thing about HPA is that it doesn't scale well(pun obviously intended) for low amounts of resources. Lets say you have a web app that uses 400mb idling and does great up to 600mb. When it reaches this point i know site is actually in real use and i want to start some new pods that _start_ at 4gig
KEDA should help with that since it allows you to use any query you want.
Prvi like!!