chore: update cluster-autoscaler to latest patch releases

[mboersma]

Reason for Change:
See https://github.com/kubernetes/autoscaler/releases. Some minor fixes are included in each patch.

Issue Fixed:

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Notes:

[jackfrancis]

/lgtm

[acs-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jackfrancis, mboersma

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jackfrancis,mboersma]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov]

Codecov Report

Merging #2038 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2038   +/-   ##
=======================================
  Coverage   76.67%   76.67%           
=======================================
  Files         135      135           
  Lines       20564    20564           
=======================================
  Hits        15768    15768           
  Misses       3877     3877           
  Partials      919      919

[jackfrancis]

@marosset Should we be running the actual E2E tests against the Windows VHD CI job? In the Linux VHD Pipeline job we just run the VHD CI scripts and validate zero exit code. (I think that's what we should be doing for the Windows job, but maybe I'm missing some context?)

[marosset]

@jackfrancis we did intend to run the actual E2E tests against the Windows VHD CI job.
We have low to medium confidence in the quality of windows patches w.r.t. k8s (given past history) and wanted a way to verify basic functionality in aks-engine clusters when rev'ing the VHD without needing to make multiple checkins and VHD builds.
Would it make sense to to have a flag to skip the E2E test by default and then when we have a PR where we do want explicit E2E coverage re-run with that a flag set to true?
Given how by default we don't save the VHD it makes it hard to get test coverage before merging to master otherwise.

[jackfrancis]

@marosset that makes sense, I actually think we could use that strategy for Linux as well to our benefit.

Does it make sense that the changeset in this PR would kick off the Windows VHD CI? I would assume those changes are Linux only, but perhaps I'm not aware of some tasty code re-use in that file. :)

[marosset]

@jackfrancis currently any changes in /packer/ (and this PR updates packer/install-dependencies.sh) will trigger the Windows VHD but i don't think it makes sense to run that here. I'll update the trigger to be something like /packer/windows for now and we can look into splitting packer/ into packer/linux/ and packer/windows/ in the near future to avoid running the linux VHD CI for windows only changes