Scheduling ALB updates by using the new startTime, endTime, and updatePercentage settings
You can now further control and manage your IBM Cloud ALB updates by specifying a time window and/or percentage of ALBs to update through customizing a configmap.
When you create a public application load balancer (ALB) for a cluster, a defined version is associated with the ALB. As future versions are released, you can update the ALB either automatically or manually. You can automatically update your ALBs by enabling IBM’s autoupdate, which manages ALBs and updates them when new versions become available. The other option is to manually update your ALBs by using the update command via the IBM Cloud CLI. To learn more about the two update paths, visit the blog here. Previously, the updates to an ALB occurred whenever the command was run or when the autoupdate was triggered. You could not control the time of day or the proportion of ALBs that could update at one time. By utilizing the new update times and percentage keys in the deployment configmap, you can now define values to control these update parameters.
How it works:
Update Time Window
You can define an optional time window for updating your ALBs. To take advantage of this time window restriction, two keys must be set and populated within the deployment configmap : updateStartTime and updateEndTime. Both fields must be set and assigned a time in a 24-hour format (HH:MM). These fields apply to all of the ALBs within the cluster and are not assigned on a per ALB basis. After you assign updateStartTime and updateEndTime, these values are evaluated against 24-hour UTC time and define the window in which ALBs can update. Whenever an update request occurs, whether manual or automatic, the current time in UTC is compared against the updateStartTime and updateEndTime of the configmap for the ALB. If the update request does not fall within that window, it does not update. Instead, when an update is unsuccessful due to this rule, the ALB that attempted to update, will have its status set to “update pending - waiting for next update window” and an internal time-to-live value is started. This time-to-live value is set to last for the duration of time between the current time and beginning of the update window you have defined in the configmap. This value acts as a sleep and prevents the ALB from attempting another update until it expires. If you do not set a time, your value is malformed, or if only one of the keys is set, then the update job runs immediately when triggered.
Update Percentage
Another axis of control you can use for your ALB updates is to control what proportion of ALBs for that cluster may be updating at any given time. That is the portion of updating ALBs to the total number of ALBs enabled. The field, updatePercentage can be defined in the configmap as a whole number from 0 to 100 to represent this percentage. Whenever an ALB update request is made, through either the manual or automatic path, the ALB percentage of updating ALBs is calculated. The percentage is calculated for each ALB as it attempts to update and is represented by the formula: (total ALBs in update state + current ALB)/total ALBs for cluster. If this percentage value is greater than the updatePercentage defined in the configmap, then the ALB does not update. Instead, a time-to-live of 6 minutes is introduced to sleep the current ALB, and prevent it from updating. After 6 minutes, the ALB attempts to update again. No matter what value you choose for updatePercentage, at least one ALB will always be allowed to update at a time. There will never be a state in which no ALBs can proceed with updating due to a low updatePercentage value. For example, an updatePercentage value of 0 will still allow one ALB to update at a time and likewise a value of 25 for a cluster with two ALBs will also update one at a time. If you do not set a percentage value or if the value is malformed, then the update proceeds for all ALBs without any restrictions.
Combining startTime, endTime, and updatePercentage settings
These two rules are applied in an additive format with the time window rule taking precedence over the percentage rule. When an ALB update request is issued, it must first fall within the correct time window, and then it must also not exceed the proportion defined in the configmap before it can continue and perform the update.
How to define the keys in the configmap
For every deployment, you can define fields in the customizable deployment configmap for their ALBs. More information can be read about this config file here. To define the above fields, enter them as key-value pairs in the data field of the configmap. The following example shows the output of a simple confgmap.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: ibm-ingress-deploy-config
namespace: kube-system
data:
"updatePercentage":"35"
"updateStartTime":"20:30"
"updateEndTime":"23:59"
```
In this example, 35% of ALBs may update between 20:34 and 23:59 UTC time. Next, you can apply the configmap by first, connecting to your cluster using ibmcloud cluster config –c <cluster id> and then using kubectl apply –f <configmap-name>. These new rules are applied the next time an update takes place. If you define a new configmap and apply it, the changes will not take effect on ALBs that are currently in the pending state due to a previous update attempt. To reset the ALB’s time-to-live and force them to evaluate against the new configmap details, you must first update and apply the configmap and then manually call an update via the IBM Cloud CLI. This path will will reevaluate the time and, given a change in the configmap that allows the ALB to update, proceed with the update. The following links provide more information on commands for the IBM Cloud CLI and ALB updates respectively.
Questions?
If you have questions, engage our team via Slack by here and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.
#Featured-area-2-home #Featured-area-2 #IBMCloud