Скачать или смотреть What are some common challenges and factors to consider when scaling a Kubernetes cluster production

We use a variety of Kubernetes clusters, which sometimes leads to scaling issues. Let me walk you through some of our deployment setups. First, we have self-managed clusters, where we use Kops for deployment, running on a single instance without auto-scaling. This is our first challenge, as auto-scaling is not enabled for these clusters.

For managed Kubernetes clusters, we use Amazon EKS, which supports auto-scaling via managed node groups. We also use AWS Fargate for certain deployments where we don’t need constant active users, helping us save costs. For high-usage deployments, we enable auto-scaling at both the pod and node levels.

On the pod level, we use the Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA). For VPA, we allocate more resources (RAM and CPU cores) for pods based on the demands of a specific deployment, like a Python-based backend that handles a lot of requests. The VPA automatically adjusts the pod resources to handle more load without needing to launch new pods, which helps maintain a smooth user experience. However, if the VPA reaches its maximum resource limit, the HPA kicks in.

The HPA scales horizontally by launching more pods when CPU usage exceeds a set threshold, typically 80%. Since the Kubernetes cluster handles all the traffic routing via services and ingress load balancers, we don’t need to manage the load balancing manually.

However, we face issues when the cluster becomes full. Sometimes, even though there is free space on the nodes, certain pods have higher resource requirements that prevent them from being scheduled. To solve this, we use AWS’s Cluster Autoscaler, which is connected to the AWS Auto Scaling group. When Kubernetes detects pending pods that can't be scheduled due to insufficient resources, it triggers the Cluster Autoscaler. This launches a new EC2 instance in the same node group, and within a few minutes, the new node is ready to accommodate the pending pods.

Even with this setup, we occasionally hit a limit where the AWS autoscaler reaches its maximum node group capacity. This happens when we’ve specified a maximum limit for nodes to prevent excessive scaling. When this occurs, we receive alerts from our monitoring system (Prometheus and Grafana) and notifications in our dedicated Slack channel for high CPU usage. When this happens, we raise tickets and increase the maximum limit of nodes in the AWS autoscaler to accommodate more resources and handle additional load.

This process ensures that, while we encounter occasional hiccups, our clusters remain scalable and able to handle large user loads efficiently.

★ You can also call or text us at (586) 665-3331 to have the free intro session.

Website: www.highpaidjobs.us

#Kubernetes #DevOps #CloudComputing #OnPrem #AWS #EKS #Fargate #InfrastructureAsCode #kubeadm #Terraform