Replicas should not be set on a deployment when a HPA is managing this field. If replicas is provided, during helm upgrade time the underlying Replica Set is scaled to this value during the deployment breaking any expected deployment upgrade strategy.
For example, if:
Autoscaling is enabled with a rolling update strategy with 0 max unavailable and 1 max surge.
A value for replicaCount is not provided as autoscaling is enabled.
During a helm upgrade that triggers a deployment upgrade the specified strategy will not be followed, the number of replicas will be immediately dropped to 1 (the default for replicaCount) instead of starting 1 surge container and swapping pods out 1 by 1.
The code above in _workload.tpl needs to read:
spec:
{{- if not $v.clustering.autoscaling.enabled }}
replicas: {{ $v.container.replicaCount }}
{{- end }}
selector:
matchLabels: {{ include "pinglib.selector.labels" . | nindent 6 }}
The deployment template always sets .spec.replicas which the charts values defaults to 1:
Replicas should not be set on a deployment when a HPA is managing this field. If replicas is provided, during helm upgrade time the underlying Replica Set is scaled to this value during the deployment breaking any expected deployment upgrade strategy.
For example, if:
During a helm upgrade that triggers a deployment upgrade the specified strategy will not be followed, the number of replicas will be immediately dropped to 1 (the default for replicaCount) instead of starting 1 surge container and swapping pods out 1 by 1.
The code above in _workload.tpl needs to read:
For this to work properly.
For reference on the fact that replicas should not be set when it is being managed elsewhere (HPA) see: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#replicas