What would you like to be added:
OS volumes for azure nodes can currently only be configured with a size (64Gi, 128Gi,...) and a type (Premium_LRS, Standard_LRS, ...)
In addition, we would need to configure that a Premium_LRS gets the "burstable" attribute.
According to Azure documentation, this can be done for Volumes used as PV by defining the
enableBursting: "true"
parameter in a storageClass.
For os volumes, this parameter would somehow need to get forwarded after setting it in the providerConfig, similar to how it is done for custom parameters for AWS gp3 volumes.
Why is this needed:
Without bursting, the bandwidth limitation of os volumes is critical e.g. if a lot of larger docker images need to get pulled after node startup. We saw long pod downtimes due to this throughput bottleneck.
A switch to PremiumV2_LRS volumes as nodes os which would be quicker is currently not supported by Azure, so activating bursting for (larger) Premium_LRS volumes is currently the only way to overcome this bottleneck.
/area storage /kind enhancement /platform azure
What would you like to be added: OS volumes for azure nodes can currently only be configured with a size (64Gi, 128Gi,...) and a type (Premium_LRS, Standard_LRS, ...) In addition, we would need to configure that a Premium_LRS gets the "burstable" attribute. According to Azure documentation, this can be done for Volumes used as PV by defining the
enableBursting: "true"
parameter in a storageClass. For os volumes, this parameter would somehow need to get forwarded after setting it in the providerConfig, similar to how it is done for custom parameters for AWS gp3 volumes.Why is this needed: Without bursting, the bandwidth limitation of os volumes is critical e.g. if a lot of larger docker images need to get pulled after node startup. We saw long pod downtimes due to this throughput bottleneck. A switch to PremiumV2_LRS volumes as nodes os which would be quicker is currently not supported by Azure, so activating bursting for (larger) Premium_LRS volumes is currently the only way to overcome this bottleneck.