CAPZ - Machine Deployment rolling update strategy

[T-Kukawka]

Currently on CAPZ there is no way to specify the rolling update strategy for the worker nodes.

CAPZ exposes this feature, however we do not have this implemented on GS side on cluster and cluster-azure Charts. Specification for the fields are listed below:

kubectl explain MachineDeployment.spec.strategy.rollingUpdate

KIND:     MachineDeployment
VERSION:  cluster.x-k8s.io/v1beta1

RESOURCE: rollingUpdate <Object>

DESCRIPTION:
     Rolling update config params. Present only if MachineDeploymentStrategyType
     = RollingUpdate.

FIELDS:
   deletePolicy	<string>
     DeletePolicy defines the policy used by the MachineDeployment to identify
     nodes to delete when downscaling. Valid values are "Random, "Newest",
     "Oldest" When no value is supplied, the default DeletePolicy of MachineSet
     is used

   maxSurge	<>
     The maximum number of machines that can be scheduled above the desired
     number of machines. Value can be an absolute number (ex: 5) or a percentage
     of desired machines (ex: 10%). This can not be 0 if MaxUnavailable is 0.
     Absolute number is calculated from percentage by rounding up. Defaults to
     1. Example: when this is set to 30%, the new MachineSet can be scaled up
     immediately when the rolling update starts, such that the total number of
     old and new machines do not exceed 130% of desired machines. Once old
     machines have been killed, new MachineSet can be scaled up further,
     ensuring that total number of machines running at any time during the
     update is at most 130% of desired machines.

   maxUnavailable	<>
     The maximum number of machines that can be unavailable during the update.
     Value can be an absolute number (ex: 5) or a percentage of desired machines
     (ex: 10%). Absolute number is calculated from percentage by rounding down.
     This can not be 0 if MaxSurge is 0. Defaults to 0. Example: when this is
     set to 30%, the old MachineSet can be scaled down to 70% of desired
     machines immediately when the rolling update starts. Once new machines are
     ready, old MachineSet can be scaled down further, followed by scaling up
     the new MachineSet, ensuring that the total number of machines available at
     all times during the update is at least 70% of desired machines.

Acceptance criteria:

• expose MachineDeployment.spec.strategy.rollingUpdate in cluster and cluster-azure charts to be configurable by customers