Configuring deploy and runtime behavior
On this page:
You can change how your application is deployed in kubernetes in the file deployment/values.yaml
Examples of what options are available are: scale/autoscaling, ports and resources allocated.
We provide some default values that you can choose to override as you see fit. The default values are defined here
To override a value in this file you need do add it as a child to the deployment section in deployment/values.yaml
An example where initial scale is overridden.
The values.yaml in the centralized chart defines replicaCount at the root as follows:
replicaCount: 2 ...
To override this in your deployment/values.yaml you add it as a child to the deployment section:
deployment: replicaCount: 3
The initial scale is controlled by the field
replicaCount. If autoscaling is enabled the autoscaler will override this value.
Example where initial scale is set to 2:
deployment: replicaCount: 2
From version 2.0.0 of the deployment helm-chart autoscaling is available and enabled by default.
Autoscaling leverages Horizontal Pod Autoscaler to automatically scale your application based on CPU utilization.
When configuring how the autoscaling of your app behaves, there are two sections in the values that affect it.
- resources cpu/memory guarantees and limits for the app pods at runtime, see: Resources Configuration
- autoscaling when and how the autoscaling should happen
Defaults if not overridden in deployment/values.yaml
deployment: autoscaling: enabled: true replicas: min: 2 max: 10 avgCpuUtilization: 70 behavior: stabilizationWindowSeconds: scaleUp: 0 scaleDown: 120
min: The lowest number of pods the autoscaler is allowed to scale down to. max: The highest number of pods the autoscaler is allowed to scale up to.
Average percentage of CPU request that is utilized.
Scale up is not instant as the new pod needs some time to start (1-2 min in most cases). If all the resources in the cluster is consumed azure also need to start a new node (5-10 min in most cases). Leave some resources that can handle the load while the extra capacity is provisioned.
The stabilization window is used to restrict the flapping of replicas when the metrics used for scaling keep fluctuating.
By default, apps initiate scale up as soon as the average utilization is above the threshold and wait two minutes before we start a scaledown.
scaleUp: Number of seconds to wait from the last scale-event to a new scaleUp is evaluated. scaleDown: Number of seconds to wait from the last scale-event to a new scaleDown is evaluated.
Setting good requests and limits you need to know the app well, e.g. what tasks is it meant to perform and how it does it. We try to set sane defaults, but they might not be suited for your workloads.
Defaults if not overridden in deployment/values.yaml
deplyoment: resources: requests: cpu: 300m memory: 256Mi
All values available, the values are only provided as an example.
deplyoment: resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1000m memory: 512Mi
This section in the yaml defines the resources that will be reserved by the kubelet for each pod of the app.
Requests are used when the kubernetes scheduler decides what node the pod should run on. This will limit the number of pods that can run on a node.
Requests are also used by the Horizontal Pod Autoscaler to determine if the app should scale up or down.
Given a cluster with 2 cores (2000 millicores) and 4Gi of memory and all the pods requesting 200m (200 millicores) and 256Mi.
The number of pods a node can run based on the CPU request is: 2000 / 200 = 10
The number of pods a node can run based on the memory request is: 4096Mi / 256Mi = 16
The number of pods a node can run, with or without actual load, is then 10.
Requests does not limit how much CPU or memory a pod can use when there are available resources, but if resources are scarce pods exceeding their request can be evicted from the node.
This section in the yaml defines the maximum of resources a pod of this app is allowed to use.
If a pod tries to use more CPU than the limit it is throttled.
If a pod tries to allocate more memory than the limit it is terminated with an Out Of Memory (OOM) error
By default all services are add to the Linkerd service mesh.
We strongly recommend not changing this setting as it add mutual TLS and other security features to all communication between services in the cluster.
deployment: ... linkerd: enabled: true ...
Volumes and VolumeMounts
This section defines volumes mounted into folders available to the application. There are some default mounts the default functionality needs to communicate with Altinn Platform.
deployment: ... volumes: - name : datakeys persistentVolumeClaim: claimName: keys - name: accesstoken secret: secretName: accesstoken
At the time of writing there is one case for adding other Volumes: Secrets loaded from Azure Key Vault
In the service definition you can change the port forwarding rules to your application, most likely this is something you do not need to change.
If your application runs on a different port than 5005, set deployment.service.internalPort to the port your app is running on.
deployment: ... service: name: deployment type: ClusterIP externalPort: 80 ## If your application is running on another port, change only the internal port. internalPort: 5005 ...
Sections overridden at deploytime
These sections are overridden at deploytime so changes have no affect.