4 posts tagged with "kubernetes"

When using Kubernetes's Horizontal Pod Autoscaling (HPA), there is an invevitable time delay until the desired number of Pods are deployed. Until then, the service quality may degrade, for example, the response latency can become very large if there is a sudden increase in the traffic volume. This article assumes that you can roughly estimate the request volume trends by using e.g., historical data, and introduces a way to mitigate the service degradation by using Kubernetes's CronJob to adjust the HPA parameters before the expected traffic increase. We will write a template CronJob and a Python script that generates the CronJob manifests from the template using values from a CSV file.

In a previous article, I demonstrated the Horizontal Pod Autoscaler (HPA) of Kubernetes. In that article, I set up autoscaling for CPU utilization, but this time I will set the HPA target to the request processing time of the pod in question. Since it is time-consuming to manage metrics values on the application side, I will get the request processing time metrics from the service mesh Istio.

I got a chance to learn to use Istio, one of the most loved service mesh solutions, in a Kubernetes cluster at work. Before all this, I had no idea about what Istio is, or why service mesh is favored, but now I have clear answers to these and can confidently recommend introducing Istio into your Kubernetes cluster. It offers a variety of benefits, and in this article, I would like to share four advantages of Istio that I like most.

This article provides a quick hands-on for Kubernetes's Horizontal Pod Autoscaler (HPA). It deploys a simple CPU-intensive Web app on Kubernetes, and configures the HPA for the deployment. Then, we perform load testing to verify that the number of replicas scale automatically based on the metrics we configure.