What's new
Overview of changes introduced in v2 of deployment.
2.8.0
- Add annotation config.linkerd.io/skip-outbound-ports: “443”
- Add port 80 to l5d-dst-override url in middleware
2.7.0
- Update timeoutSeconds: 30 readiness and liveliness probe
2.6.0
- Add option for startupprobe
2.5.0
Changes introduced
- Raise value resource request memory to 256Mi
2.4.0
Changes introduced
Remove hard values linkerd resources
Add help text for extra annotations
Add if linkerd add annotation cluster-autoscaler.kubernetes.io/safe-to-evict: true
2.3.0
Changes introduced
- Upgraded HorizontalPodAutoscaler from version autoscaling/v2beta2 to autoscaling/v2
autoscaling/v2beta2 is deprecated in version 1.23+ of kubernetes and removed in version 1.26+ Apps clusters will eventually be upgraded and deployment of apps using old chart versions will fail once cluster is upgraded to version 1.26+.
2.2.0
Changes introduced
- Make it possible to at custom annotations to pods in values.yaml
How to add pod annotations in values.yaml
deployment:
podAnnotations:
key1: value1
key2: value2
2.1.0
Changes introduced
- Default CPU og memory requested per pod is reduced to 50m and 128Mi, respectively.
- Configurable liveliness and readiness probes are available. Default behavior is that this is disabled.
New optional fields with default values available in values.yaml
|
|
Walk-through:
3. Enable or disable readiness probe for this application.
4. The path to the liveliness endpoint in the application.
5. Number of seconds after the container has started before readiness probes are initiated.
6. Minimum consecutive failures for the probe to be considered failed after having succeeded.
7. How often (in seconds) to perform the probe
8. Number of seconds after which the probe times out.
10. Enable or disable liveliness probe for this application.
11. The path to the liveliness endpoint in the application.
12. Number of seconds after the container has started before liveliness probes are initiated.
13. Minimum consecutive failures for the probe to be considered failed after having succeeded.
14. How often (in seconds) to perform the probe
2.0.0
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
|
|
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
|
|
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.