chore: replace deprecated extensions/v1beta APIs for 1.16

[mboersma]

Reason for Change:
Future-proofs the addons manifests not to use deprecated beta workload APIs.

The new API names should work from Kubernetes 1.14 onward, so that's where this change is made. In Kubernetes 1.16, the old extensions/v1beta1 names will be unsupported.

• All resources under apps/v1beta1 and apps/v1beta2 - use apps/v1 instead
• daemonsets, deployments, replicasets resources under extensions/v1beta1 - use apps/v1 instead
• podsecuritypolicies resources under extensions/v1beta1 - use policy/v1beta1 instead
• networkpolicies resources under extensions/v1beta1 - use networking.k8s.io/v1 instead (NOTE: there weren't any networkpolicies to convert in AKS Engine, just including here for completeness. See [1.16] Stop serving deprecated beta workload APIs kubernetes/kubernetes#70672.)

Issue Fixed:
Fixes #1522

Requirements:

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

Notes:

[codecov]

Codecov Report

Merging #1527 into master will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1527      +/-   ##
==========================================
- Coverage   75.84%   75.78%   -0.06%     
==========================================
  Files         128      128              
  Lines       18302    18388      +86     
==========================================
+ Hits        13881    13936      +55     
- Misses       3636     3655      +19     
- Partials      785      797      +12

[jackfrancis]

So, the issue with putting all of these into the 1.14/ directory is that they will be interpreted as 1.14-only. The implementation as-is for "which manifest to choose" is "if there is a version-specific manifest that matches my desired k8s version, use it, otherwise use the one in the root dir".

Does that match the way we've organized these changes across files?

[mboersma]

they will be interpreted as 1.14-only.

Whoops, so how would we segregate this change into before- and after-1.14 manifests? I can make them the default, but then how would I say "use the older versions for Kubernetes <= 1.13"?

[mboersma]

I suppose a more conservative approach would be only to make this change for 1.16 and onward, but that begs the same question eventually.

[jackfrancis]

It would be to create a pre-1.14 directory for each manifest.

Alternatively, because this change is apparently valid for all relevant k8s versions, we could just change the existing manifests.

[mboersma]

After refactoring, this should now represent the minimum set of changes to keep just Kubernetes 1.16 from choking on extensions/v1beta1 in addon manifests.

Is that worth merging in advance, or should I keep it ready until there is a testable alpha release of Kubernetes 1.16?

[jackfrancis]

I vote for merging this in advance. @adelina-t if we build hyperkube from upstream HEAD right now does that have the relevant 1.16 changes?

@CecileRobertMichon FYI and thoughts welcome

[CecileRobertMichon]

Does this mean we'll have to make a 1.x dir for every new minor k8s version after 1.16?

+1 on merging in advance

[jackfrancis]

@CecileRobertMichon either that or before 1.17 lands we'd create pre-1.14 directories for every component.

I have a preference towards a per-version manifest definition. It will require more boilerplate when we introduce a new version, and additional overhead for making general changes to manifests that span versions; but it is arguably more expressive and encourages per-version curation, which is arguably the right way to maintain these manifests.

[mboersma]

a per-version manifest definition

As in duplicating the entire set of addon manifests for each new version, even if they're the same as before?

That obviously requires more maintenance, but removes any confusion about the source of a manifest. I'm in favor of that tradeoff.

[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