What's new

Overview of changes introduced in v2 of deployment.

On this page:

2.0.0

Upgrading to 2.0.0 from 1.x.x leads to a short downtime during deployment. Subsequent deployments will run as normal.

If your apps deployment folder contains the templates folder please follow the migration guide.

Changes introduced

  • Deployment renamed to -v2 due to changes in selector fields (field is immutable) WARNING leads to downtime during first deploy
  • Add resource requests to all deployments
  • Horizontal pod autoscaler enabled by default for all deployments (automatic scaling of application)
  • Labels and selectors updated for most kubernetes objects
  • Default initial replicaCount changed from 1 to 2

New optional fields with default values available in values.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
deployment:
  autoscaling:
    enabled: true
    replicas:
      min: 2
      max: 10
    avgCpuUtilization: 70
    behavior:
      stabilizationWindowSeconds:
        scaleUp: 0
        scaleDown: 120
  resources:
    requests:
      cpu: 300m
      memory: 256Mi

Walkthrough

3. Enable or disable autoscaling for this application

5. The lower limit for the number of pods that can be set by the autoscaler.

6. The upper limit for the number of pods that can be set by the autoscaler.

7. The target average CPU utilization (represented as a percent of requested CPU) over all the pods for when scaling should occur.

9. The stabilization window is used to restrict the flapping of replicas when the metrics used for scaling keep fluctuating.

10. Number of seconds the average CPU utilization for all pods are above the threshold (avgCpuUtilization) before scaleUp starts.

11. Number of seconds the average CPU utilization for all pods are below the threshold (avgCpuUtilization) before scaleDown starts.

14. CPU millicores reserved by the kubelet for each pod of this application. Used by HPA to calculate scale. Pods are allowed to consume more than this if it’s available.

15. Memory reserved by the kubelet for each pod of this application. Pods are allowed to consume more than this if it’s available

New optional field without default values available in values.yaml

1
2
3
4
5
deployment:
  resources:
    limits:
      cpu: 1000m
      memoty: 512Mi

Walkthrough

4. Upper limit of CPU millicores a pod is allowed to consume. Pods hitting the limit will be throttled

5. Upper limit of memory a pod is allowed to consume. Pods exceeding this limit will be terminated by the system with an out of memory (OOM) error.

Pull requests merged