|
33 | 33 |
|
34 | 34 | ## AzureMachinePool |
35 | 35 | Cluster API Provider Azure (CAPZ) has experimental support for `MachinePool` through the infrastructure |
36 | | -type `AzureMachinePool`. An `AzureMachinePool` corresponds to an [Azure Virtual Machine Scale Set](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview), |
37 | | -which provides the cloud provider specific resource for orchestrating a group of Virtual Machines. |
| 36 | +type `AzureMachinePool` and `AzureMachinePoolMachine`. An `AzureMachinePool` corresponds to an |
| 37 | +[Azure Virtual Machine Scale Set](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview), |
| 38 | +which provides the cloud provider specific resource for orchestrating a group of Virtual Machines. The |
| 39 | +`AzureMachinePoolMachine` corresponds to a virtual machine instance within the Virtual Machine Scale Set. |
38 | 40 |
|
39 | | -⚠️ Cloud provider for Azure does not currently support clusters in mixed mode (both vmss and vmas node pools), so it is not supported to have both `AzureMachinePools` and `AzureMachines` in the same workload cluster. |
| 41 | +### Safe Rolling Upgrades and Delete Policy |
| 42 | +`AzureMachinePools` provides the ability to safely deploy new versions of Kubernetes, or more generally, changes to the |
| 43 | +Virtual Machine Scale Set model, e.g., updating the OS image run by the virtual machines in the scale set. For example, |
| 44 | +if a cluster operator wanted to change the Kubernetes version of the `MachinePool`, they would update the `Version` |
| 45 | +field on the `MachinePool`, then `AzureMachinePool` would respond by rolling out the new OS image for the specified |
| 46 | +Kubernetes version to each of the virtual machines in the scale set progressively cordon, draining, then replacing the |
| 47 | +machine. This enables `AzureMachinePools` to upgrade the underlying pool of virtual machines with minimal interruption |
| 48 | +to the workloads running on them. |
| 49 | + |
| 50 | +`AzureMachinePools` also provides the ability to specify the order of virtual machine deletion. |
| 51 | + |
| 52 | +#### Describing the Deployment Strategy |
| 53 | +Below we see a partially described `AzureMachinePool`. The `strategy` field describes the |
| 54 | +`AzureMachinePoolDeploymentStrategy`. At the time of writing this, there is only one strategy type, `RollingUpdate`, |
| 55 | +which provides the ability to specify delete policy, max surge, and max unavailable. |
| 56 | + |
| 57 | +- **deletePolicy:** provides three options for order of deletion `Oldest`, `Newest`, and `Random` |
| 58 | +- **maxSurge:** provides the ability to specify how many machines can be added in addition to the current replica count |
| 59 | + during an upgrade operation. This can be a percentage, or a fixed number. |
| 60 | +- **maxUnavailable:** provides the ability to specify how many machines can be unavailable at any time. This can be a |
| 61 | + percentage, or a fixed number. |
| 62 | + |
| 63 | +```yaml |
| 64 | +apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4 |
| 65 | +kind: AzureMachinePool |
| 66 | +metadata: |
| 67 | + name: capz-mp-0 |
| 68 | +spec: |
| 69 | + strategy: |
| 70 | + rollingUpdate: |
| 71 | + deletePolicy: Oldest |
| 72 | + maxSurge: 25% |
| 73 | + maxUnavailable: 1 |
| 74 | + type: RollingUpdate |
| 75 | +``` |
| 76 | +
|
| 77 | +### AzureMachinePoolMachines |
| 78 | +`AzureMachinePoolMachine` represents a virtual machine in the scale set. `AzureMachinePoolMachines` are created by the |
| 79 | +`AzureMachinePool` controller and are used to track the life cycle of a virtual machine in the scale set. When a |
| 80 | +`AzureMachinePool` is created, each virtual machine instance will be represented as a `AzureMachinePoolMachine` |
| 81 | +resource. A cluster operator can delete the `AzureMachinePoolMachine` resource if they would like to delete a specific |
| 82 | +virtual machine from the scale set. This is useful if one would like to manually control upgrades and rollouts through |
| 83 | +CAPZ. |
40 | 84 |
|
41 | 85 | ### Using `clusterctl` to deploy |
42 | 86 | To deploy a MachinePool / AzureMachinePool via `clusterctl config` there's a [flavor](https://cluster-api.sigs.k8s.io/clusterctl/commands/config-cluster.html#flavors) |
@@ -83,6 +127,12 @@ metadata: |
83 | 127 | name: capz-mp-0 |
84 | 128 | spec: |
85 | 129 | location: westus2 |
| 130 | + strategy: |
| 131 | + rollingUpdate: |
| 132 | + deletePolicy: Oldest |
| 133 | + maxSurge: 25% |
| 134 | + maxUnavailable: 1 |
| 135 | + type: RollingUpdate |
86 | 136 | template: |
87 | 137 | osDisk: |
88 | 138 | diskSizeGB: 30 |
|
0 commit comments