Horizontal Pod Scaler¶
Introduction¶
If you have read through my blog from the top to the bottom, you will understand the concepts of MicroServices. To annex the learning goal of Scalability I have decided to use a technique called Horizontal Scaling. Before understanding Horizontal Scaling, Vertical Scaling must be first explained as it can paint a clear picture. Vertical Scaling refers to increasing the system resources based on demand. This setup has a few clear disadvantages; no single system can be finitely scaled vertically. Horizontal scaling gets around this problem by introducing multiple pods, meaning the same microservice hosted multiple times.
Theory¶
Execution¶
I created my first Microservice for the User component. This microservice uses mySQL; for simplicity reasons & the user microservice being a lesser used component in my application. I used my previous Spring Java REST API codebase to quickly set it up.
Implementation¶
Up until this point I implemented the deployment of my Ramses application in my Rancher cluster.
Rancher is an Kubernetes Management Interface; easily allowing me to deploy my pods in the way I configured them to. One of the services it provides is the implementation of a Loadbalancer; as can be seen here:
In it is my LoadBalancer configuration. Most of it is auto-generated by Rancher. I’ve made my own adjustments to the cpu resource, making Rancher scale my pod when the mCPU is met.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
creationTimestamp: "2022-05-17T11:11:20Z"
managedFields:
- apiVersion: autoscaling/v2
fieldsType: FieldsV1
fieldsV1:
f:spec:
f:maxReplicas: {}
f:metrics: {}
f:minReplicas: {}
f:scaleTargetRef:
f:apiVersion: {}
f:kind: {}
f:name: {}
manager: rancher
operation: Update
time: "2022-05-17T11:11:20Z"
- apiVersion: autoscaling/v2
fieldsType: FieldsV1
fieldsV1:
f:status:
f:conditions:
.: {}
k:{"type":"AbleToScale"}:
.: {}
f:lastTransitionTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"ScalingActive"}:
.: {}
f:lastTransitionTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"ScalingLimited"}:
.: {}
f:lastTransitionTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
f:currentMetrics: {}
f:currentReplicas: {}
f:desiredReplicas: {}
f:lastScaleTime: {}
manager: k3s
operation: Update
subresource: status
time: "2022-05-17T11:12:35Z"
name: lb-gameservice
namespace: ramses
resourceVersion: "418564"
uid: a10d1017-32d7-4921-95d5-51fc4ebf228a
spec:
maxReplicas: 10
metrics:
- resource:
name: cpu
target:
averageValue: 500m
type: AverageValue
type: Resource
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: gameservice
status:
conditions:
- lastTransitionTime: "2022-05-23T06:17:13Z"
message: recommended size matches current size
reason: ReadyForNewScale
status: "True"
type: AbleToScale
- lastTransitionTime: "2022-05-22T17:18:38Z"
message: the HPA was able to successfully calculate a replica count from cpu resource
reason: ValidMetricFound
status: "True"
type: ScalingActive
- lastTransitionTime: "2022-05-17T11:12:50Z"
message: the desired count is within the acceptable range
reason: DesiredWithinRange
status: "False"
type: ScalingLimited
currentMetrics:
- resource:
current:
averageValue: 1m
name: cpu
type: Resource
currentReplicas: 1
desiredReplicas: 1
lastScaleTime: "2022-05-22T14:26:40Z"
Monitoring¶
And lastly, I’ve implemented monitoring metrics to my Rancher, enabling with the help of Grafana to see the metrics granting insight to the pods.