Managing ALBs

Enabling automatic updates

When you enable automatic updates, your ALBs are updated to the version that is marked as the default. When a newer version becomes the default version, your ALBs are automatically updated to that version.

If only one worker node exists in a zone in your cluster, and you set the number of ALB replicas to 1, this single ALB pod is deleted and a new pod is created whenever updates are applied. This process might cause traffic disruptions even if you have worker nodes and ALB replicas in other zones. To prevent traffic disruptions, ensure that at least two worker nodes exist in each zone, and that two replicas exist for each ALB. Note that during the update process, only new connections are routed to the second ALB pod; existing connections on the updating ALB pod are safely terminated. For existing connections that are terminated during the update, initiate a retry in client applications.

Scheduling maintenance windows for automatic updates

You can control and manage automatic ALB updates by creating a customized ConfigMap that specifies the time you want the updates.

To set a time for automatic updates, you set the updateStartTime and updateEndTime keys in the deployment ConfigMap. Each key represents an assigned time in a 24 hour format (HH:MM). Note that this time is specified in coordinated universal time (UTC) rather than your local time.

1. Create a YAML file for your ConfigMap. Specify the updateStartTime, and updateEndTime fields as key-value pairs in the data field.

   The following example ConfigMap sets the automatic update function to update 35% of ALB pods in your cluster between 20:34 and 23:59 UTC.

   apiVersion: v1
   kind: ConfigMap
   metadata:
       name: ibm-ingress-deploy-config
       namespace: kube-system
   data:
       "updateStartTime": "20:34"
       "updateEndTime": "23:59"
   

2. Deploy the ConfigMap in your cluster. The new rules apply the next time an update takes place.

   kubectl apply -f <filename>.yaml
   

Disabling automatic updates

To receive bug fixes and security updates, keep automatic updates enabled. When automatic updates are disabled, you are responsible for updating your ALBs manually.

You can disable automatic updates for your ALBs by running ibmcloud ks ingress alb autoupdate disable -c <cluster_name_or_ID>.

To check if automatic updates are enabled for your cluster, use the ibmcloud ks ingress alb autoupdate get -c <cluster_name_or_ID> command. If you decide to enable automatic updates again, you can run ibmcloud ks ingress alb autoupdate enable -c <cluster_name_or_ID>.

Applying manual updates

You can manually apply a one-time update of your Ingress ALB pods with the ibmcloud ks ingress alb update command. This command applies the default ALB image version, but you can apply a different version by including the --version option. For more information or command options, see the CLI reference.

To update your ALB image to a specific version with the --version option, you must disable automatic ALB updates and then keep them disabled for as long as you want to run the specified version. Automatic updates always apply the default version and overwrite any manual updates you apply. If you want to use a different version, you cannot enable automatic updates.

• To list the available ALB versions, run the following command.

  ibmcloud ks ingress alb version ls --region <region>
  

• To update all ALB pods in the cluster, run the following command.

  ibmcloud ks ingress alb update -c <cluster_name_or_ID> --version <image_version>
  

• To update the ALB for specific ALBs, run the following command.

  ibmcloud ks ingress alb update -c <cluster_name_or_ID> --version <image_version> --alb <ALB_ID> [--alb <ALB_2_ID> ...]
  

Viewing supported image versions

To list the latest three versions that are supported for each type of image, run the following command.

ibmcloud ks ingress alb versions

Example output

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

The Kubernetes Ingress version follows the format <community_version>_<ibm_build>_iks. The IBM build number indicates the most recent build of the Kubernetes Ingress NGINX release that IBM Cloud Kubernetes Service released. For example, the version 1.1.2_2507_iks indicates the most recent build of the 0.47.0 Ingress NGINX version. IBM Cloud Kubernetes Service might release builds of the community image version to address vulnerabilities.

For the changes that are in each version of the Ingress images, see the Ingress version change log.

Reverting to an earlier version

If your ALB pods were recently updated, but a custom configuration for your ALBs is affected by the latest image version build, you can use the ibmcloud ks ingress alb update command with the --version option to roll back ALB pods to an earlier, supported version. The image version that you change your ALB to must be a supported image version that is listed in the output of ibmcloud ks ingress alb versions.

Note that if you revert to an earlier version, you must disable automatic ALB updates and then keep them disabled for as long as you want to run the earlier version. Automatic updates always apply the latest version and overwrite any manual updates you apply. If you want to use an earlier version, you cannot enable automatic updates.

Creating more ALBs in a zone

Each ALB in a zone is deployed as two pods on different worker nodes. To scale up your ALB processing capabilities and handle more connections, you can create additional ALBs in a zone. The IP address of the new ALB is automatically added to your Ingress subdomain.

When you create a multizone cluster, a default public ALB is created in each zone where you have worker nodes. If you later remove one of these original three zones and add workers in a different zone, a default public ALB is not created in that new zone. You can manually create an ALB to process connections in that new zone.

When using Ingress resource validation, every create and update request is validated by all ALBs. If no pods are running for a particular ALB instance, you might be unable to apply Ingress resources on your cluster. Make sure to have at least one running pod for each ALB in enabled state. For more information, see Ingress deployment customization reference.

1. In each zone where you have worker nodes, create an ALB.

   The following command applies to classic clusters. For more information and command options, see the CLI reference.

   ibmcloud ks ingress alb create --cluster <cluster_name_or_ID> --type <public_or_private> --zone <zone> --vlan <VLAN_ID> [--ip <IP_address>] [--version image_version]
   

   The following command applies to VPC clusters. For more information and command options, see the CLI reference.

   ibmcloud ks ingress alb create vpc-gen2 --cluster <cluster_name_or_ID> --type <public_or_private> --zone <vpc_zone> [--version image_version]
   

2. Verify that the ALBs that you created in each zone have a Status of enabled. For classic clusters, check that an ALB IP is assigned. For VPC clusters, check that Load Balancer Hostname is assigned.

   ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>
   

   Example output for a classic cluster.

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021       -
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945       -
   

   Example output for a VPC cluster.

   ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks
   
   

Changing the number of ALB pod replicas

By default, each ALB has 2 replicas. You can customize your ALB processing capabilities by manually changing the number of ALB pods or by enabling dynamic, automatic scaling.

A single ALB pod can handle a large amount of requests. If you experience timeouts, slow responses or other signs of overload, check the state of your backend application. Make sure that ALB is the bottleneck of your application before scaling ALB pods, otherwise it might not provide the expected results.

For classic clusters: If the ALB's load balancer service configuration has the externalTrafficPolicy set to Local, do not scale above 2 replicas. Classic load balancers run with a fixed configuration of 2 replicas, and can only forward traffic to ALB pods that are located on the same node as the load balancer pods.

By default, periodic Ingress version updates are automatically rolled out to your ALBs. If only one worker node exists in a zone in your cluster, and you set the number of ALB replicas to 1, this single ALB pod is deleted and a new pod is created whenever updates are applied. This process might cause traffic disruptions, even if you have worker nodes and ALB replicas in other zones. To prevent traffic disruptions, ensure that at least two worker nodes exist in each zone, and that two replicas exist for each ALB. Note that during the update process, only new connections are routed to the second ALB pod; existing connections on the updating ALB pod are safely terminated. It is recommended that client applications initiate a retry for existing connections that are terminated during the update.

Manually change the number of ALB replicas by creating a ConfigMap. Note that you cannot manually scale your ALB replicas if you have configured your ALB to use dynamic scaling.

1. Get the IDs for your ALBs.

   ibmcloud ks ingress alb ls -c <cluster_name_or_ID>
   

2. Create a YAML file for an ibm-ingress-deploy-config ConfigMap. For each ALB, add '{"replicas":<number_of_replicas>}'. This example increases the number of ALB pods to 4 replicas.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":4}'
     <alb2-id>: '{"replicas":4}'
     ...
   

3. Create the ibm-ingress-deploy-config ConfigMap in your cluster.

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. To apply the changes, update your ALBs. Note that it might take up to 5 minutes for the changes to apply.

   ibmcloud ks ingress alb update -c <cluster_name_or_ID>
   

5. Verify that the number of ALB pods that are Ready increased to the number of replicas that you specified.

   kubectl get pods -n kube-system | grep alb
   

Example commands for configuring dynamic ALB autoscaling

Example command for dynamic scaling based on an average CPU utilization of 60%.

ibmcloud ks ingress alb autoscale set -c <cluster_name_or_ID> --alb <alb-id> --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

Example command for dynamic scaling based on custom metrics stored in a file named my-custom-metrics.yaml.

ibmcloud ks ingress alb autoscale set -c <cluster_name_or_ID> --alb <alb-id> --min-replicas 2 --max-replicas 5 --custom-metrics-file my-custom-metrics.yaml

Calculating average CPU utilization

The following image shows an example scenario for determining CPU usage when planning your autoscaling configuration.

Assume that you have an idle cluster with two running ALB replicas that has no incoming traffic. The total CPU request in this case is 2*20m=40m. One of the replicas might use 5m CPU and the other 7m CPU. We can calculate the CPU utilization by using the following formula.

Disabling ALB autoscaling

Run the command to disable autoscaling for an ALB.

ibmcloud ks ingress alb autoscale unset --alb ALB --cluster CLUSTER