Support configuration to inject unattended-upgrades into CSE.

[msjelly]

Describe the request
Support ability to optionally inject unattended-upgrades into CSE.
Explain why AKS Engine needs it
Aks-engine does not release patches of previous versions of AKS Engine images for patch releases of the OS. It is desirable to have the OS patches as early as possible after the nodes are provisioned.
Describe the solution you'd like
Add optional configuration in cluster definition to inject unattended-upgrades in CSE. Reboot sentinel e.g. /var/run/reboot-required would trigger CSE to reboot the node. https://github.com/Azure/aks-engine/blob/master/parts/k8s/cloud-init/artifacts/cse_main.sh#L272
Describe alternatives you've considered
https://github.com/jackfrancis/kamino
Additional context
Ideally, we need this to be configurable at the granularity of agentpool rather than as a cluster wide setting.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it.

[dmeytin]

Janet, there is another alternative to keep cluster with the latest security patches:

1. Boot a new VM using the cluster's SKU (VHD used to during the cluster's creation)
2. Run unattended-upgrades
3. Generalize the VM (az vm generalize --resource-group [ResourceGroup] --name [VmName])
4. Upload the VM's image into Shared Image Gallery
5. Upgrade VMSS with the image

This solution is similar to kamino, except the fact that the image is created once and then propagated to all environments

[msjelly]

@dmeytin We dynamically add/delete agentpools with different configurations (e.g. CPU/GPU VM types/sizes) and prefer not to have to maintain pre-baked VM image for each configuration that we have to support.

[dmeytin]

This is absolutely legit approach, with the only drawback of long scaling times that could be omitted by using pre-baked VM image.
Running CSE for each VM boot that end ups with reboot could take up to 5min

[msjelly]

I've seen agentpool creation take between 3min-40min depending on size of our agentpool. If the latency goes up to something like 8 minutes minimum, that's not desirable but may be tolerable... With the approach you propose (and kamino), is it the case that we'll need to create separate VM image for each VM size that we want to support and that we have to create such VM image for each cluster?

[dmeytin]

VHD is for OS disk only.
The VM size is independent from OS image.

[msjelly]

Same OS image can be used for upgrading CPU and GPU VMs?