Skip to main content

Scaling further

In this lab exercise, we'll scale up our entire application architecture beyond what we did earlier in the Cluster Autoscaler section and observe how the responsiveness differs.

The following configuration file will be applied to scale up our application components:

~/environment/eks-workshop/modules/autoscaling/compute/overprovisioning/scale/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: all
spec:
  replicas: 5

Let's apply these updates to our cluster:

~$kubectl apply -k ~/environment/eks-workshop/modules/autoscaling/compute/overprovisioning/scale
~$kubectl wait --for=condition=Ready --timeout=180s pods -l app.kubernetes.io/created-by=eks-workshop -A


As the new pods roll out, a conflict will eventually arise where the pause pods are consuming resources that the workload services could utilize. Due to our priority configuration, the pause pods will be evicted to allow the workload pods to start. This will result in some or all of the pause pods entering a Pending state:


~$kubectl get pod -n other -l run=pause-pods
NAME                          READY   STATUS    RESTARTS   AGE
pause-pods-5556d545f7-2pt9g   0/1     Pending   0          16m
pause-pods-5556d545f7-k5vj7   0/1     Pending   0          16m


This eviction process allows our workload pods to transition to ContainerCreating and Running states more quickly, demonstrating the benefits of cluster over-provisioning.