Kubernetes Autoscaling: HPA vs. VPA vs. Keda vs. CA vs. Karpenter vs. Fargate

🔴 - To support my channel, I’d like to offer Mentorship/On-the-Job Support/Consulting - [e-mail]
▬▬▬▬▬ Experience & Location 💼 ▬▬▬▬▬
► I’m a Senior Software Engineer at Juniper Networks (12+ years of experience)
► Located in San Francisco Bay Area, CA (US citizen)
▬▬▬▬▬▬ Connect with me 👋 ▬▬▬▬▬▬
► LinkedIn: / anton-putra
► Twitter/X: / antonvputra
► GitHub: github.com/antonputra
► Email: [e-mail]
▬▬▬▬▬▬ Related videos 👨‍🏫 ▬▬▬▬▬▬
👉 [Playlist] Kubernetes Tutorials: • Kubernetes Tutorials
👉 [Playlist] Terraform Tutorials: • Terraform Tutorials fo...
👉 [Playlist] Network Tutorials: • Network Tutorials
👉 [Playlist] Apache Kafka Tutorials: • Apache Kafka Tutorials
👉 [Playlist] Performance Benchmarks: • Performance Benchmarks
👉 [Playlist] Database Tutorials: • Database Tutorials
▬▬▬▬▬▬▬ Timestamps ⏰ ▬▬▬▬▬▬▬
0:00 Intro
1:24 Horizontal Pod Autoscaler (HPA)
5:03 Horizontal Pod Autoscaler Prometheus (Custom Metrics)
7:35 Vertical Pod Autoscaler (VPA)
9:44 Keda (Event Driven Autoscaling)
11:41 Cluster Autoscaler (CA)
13:11 Karpenter (Flexibility)
13:55 Serverless Kubernetes (Fargate & Autopilot)
▬▬▬▬▬▬▬ Source Code 📚 ▬▬▬▬▬▬▬
► GitHub: github.com/antonputra/tutoria...
#kubernetes #docker #devops

[@AntonPutra]

🔴 - To support my channel, I’d like to offer Mentorship/On-the-Job Support/Consulting - [e-mail]

[@AndroidandTechSolutions]

Thanks a lot!! All content in the channel is a gold mine. you have explained very well the concepts. thanks and keep it up 😊👏👏

[@AntonPutra]

Thank you! :)

[@raoanonymous]

Awesome content. Easy to understand. Thank you

[@AntonPutra]

thank you!

[@hz8711]

very good video, which includes not only useful information, but pretty important recommendations!

[@AntonPutra]

Thank you!

[@user-nm3yy8qh1n]

Your diagrams are very easy to understand. Thank you Anton

[@AntonPutra]

my pleasure!

[@roudder6606]

спасибо, хорошая подача и без воды

[@AntonPutra]

spasibo!

[@CodeSecLab]

Thank you Anton, this is very helpful and your diagrams and explanations are really clear and to the point. Keep going 👌🏼

[@AntonPutra]

❤️

[@JackReacher1]

master stroke, nice work!

[@AntonPutra]

thanks :)

[@tuvoxuan1894]

You did great!!! Thanks you so much

[@AntonPutra]

Thank you!!

[@fadi07full]

Hatsoff Next Level Explanations ! more power to you :)

[@devopstube6039]

I used Knative eventing but seems like KEDA is a more suitable option, easy to manage and understand, and looks simpler than Knative, Thanks for sharing it.

[@AntonPutra]

Welcome. I used to use OpenFaaS, but they decided to monetize it and began developing new features exclusively for paid subscribers.

[@CripplingDuality]

Different use cases

[@GabrielPozo]

Thanks for sharing this quality content!

[@AntonPutra]

My pleasure!

[@irwin_a]

Ur Gold to K8s community !!!

[@AntonPutra]

thanks :)

[@arpit92m]

subscribed, keep up the good work

[@AntonPutra]

thanks! will do!

[@diegonayalazo]

Thanks Teacher ❤!!

[@AntonPutra]

Thanks :)

[@LeandroSantos-bt1lg]

I have used keda in gcp with pub/sub and it works quite well.

[@AntonPutra]

cool, did you use workload identity or you had to use credentials json file?

[@LeandroSantos-bt1lg]

@@AntonPutra I had to use the credentials json file for the service account, the GKE cluster wasn’t provisioned with workload identity unfortunately.

[@AntonPutra]

​@@LeandroSantos-bt1lg I see. I hate using JSON credentials. I wonder why they had to use JSON instead of a key and secret as in AWS.

[@Ivorlun]

Антон, спасибо огромное! Как всегда - превосходная подача и идеально выбраны границы, в пределах которых освещена тема. And a question about scaling stateful apllication, particularly a database - is it possible to create master-master configuration with several endpoints in service for avoiding downtime during pod recreation? And do you see potential problems with auto attaching pv back to it or some concerns about it possible inconsistency?

[@AntonPutra]

Thank you! Well, it's possible, but I would highly recommend creating your own Operator instead of relying on StatefulSets. Based on my experience, databases and messaging systems work just fine in Kubernetes in light environments with low load. However, when you start moving all of it into production, you will discover many nuances, and recovering a database in Kubernetes in production is very challenging. Think twice, especially if you will be responsible for running it and not simply developing and handing it over to an ops team. :)

[@gmeister3022]

Elemental, highly informative content. Well done as per usual, Anton! If at all possible, I'd like to request a more advanced solution (i.e, deploying VPA along with JVM based applications, deploying a multidimensional pod autoscaling solution in a production-ready environment, etc.).

[@AntonPutra]

Thank you! I'll see what I can do.

[@twizzoe]

I need a clarification with regards the promtheus setup, if I already have a prometheus deployed on my cluster using the kube-prometheus-stack will that suffice to use also because I am seeing prometheus adapter and operator?

[@user-md9xv5nb4z]

thanks anton for this content, it is awesome, can you do a video comparing apache kafka and amazon kinesis please with grafana visualization

[@AntonPutra]

Thanks, sure at some point in the future.

[@arozendojr]

Is it possible to do automatic tracking for jaeger + istio, request and response communication between services on the jaeger dashboard? Would you have an example?

[@saikiransunkara1955]

Does EKS allow us to create node group with different instance types of ec2 instances? As far as I know it doesn't allow why because instances will be under ASG and will have launch configuration defined, Please correct me if I am wrong. If they are part of ASG then how to update the instance type of ec2 without causing downtime.

[@AntonPutra]

If you use kOPS to create Kubernetes (K8s) in AWS, you can definitely use mixed instance family types. I've been using it for spot instances so that, in case one instance type is not available, another one is selected automatically. I'm not sure about EKS; you may need to create launch templates. Here is the official documentation for mixed Auto Scaling groups (AGs): docs.aws.amazon.com/autoscaling/ec2/userguide/create-mixed-instances-group-manual-instance-type-selection.html.

[@duyluan97]

Could you please let me know which tool you used to create the video? The tool seems helpful in organizing the explanation. Thanks!

[@AntonPutra]

sure, it's adobe suite

[@duyluanontheflow]

Thanks@@AntonPutra

[@putnam120]

Where is the documentation of using karpenter with non AWS clouds? I have only ever seen documentation for AWS.

[@AntonPutra]

Here is for azure - github.com/Azure/karpenter

[@putnam120]

@@AntonPutra thank you

[@user-px6ck4vh1o]

[@AntonPutra]

Thanks :)

[@kelvinonuchukwu8215]

Where are we supposed to get the Github repository from?

[@AntonPutra]

github.com/antonputra/tutorials/tree/main/lessons/181

[@abdelhaibouaicha3293]

📝 Summary of Key Points: 📌 Autoscaling in Kubernetes allows adjusting resources based on application usage, saving on compute and avoiding wasted resources. 🧐 Different types of autoscaling controllers exist in Kubernetes, including built-in and separately installed ones. 🧐 Autoscaling is easier to implement for stateless applications compared to distributed databases. 🧐 The Horizontal Pod Autoscaler (HPA) is a common approach for autoscaling in Kubernetes, adjusting the desired scale based on metrics like CPU and memory usage. 🧐 Custom metrics can be used for autoscaling, such as latency, traffic, errors, and saturation, by deploying a Prometheus operator and instance. 🧐 For stateful applications, vertical scaling is the only option, and the Vertical Pod Autoscaler (VPA) recommends resource requests and limits. 🧐 Kubernetes allows autoscaling of the cluster itself with the Cluster Autoscaler, adjusting the node group size based on pending pods. 🧐 The KEDA project helps with autoscaling based on the number of messages in a queue or topic, supporting various messaging systems. 💡 Additional Insights and Observations: 💬 "Autoscaling is important because it allows you to adjust the resources allocated to your applications based on their usage, saving on compute and avoiding wasted resources." 📊 The Horizontal Pod Autoscaler (HPA) is a commonly used approach for autoscaling in Kubernetes. 🌐 The KEDA project supports various messaging systems like Apache Kafka, RabbitMQ, and MySQL for autoscaling based on message queues or topics. 📣 Concluding Remarks: Autoscaling in Kubernetes is a powerful tool that efficiently manages resources and handles varying workloads. It can be implemented using built-in controllers like the HPA and VPA, as well as additional tools like Prometheus and KEDA. By adjusting resources based on application usage, autoscaling optimizes resource allocation and improves overall efficiency. Made with Talkbud

[@matc8085]

Karpenter is not usable on GKE

[@AntonPutra]

I know, but they claim it is usable.