Document changes to admission control flags

[tengqm]

Problem:
The admission-controls flag has been changed to enable-admission-plugins.
This behavior change has to be documented.

Proposed Solution:
Document it and hold it in release-1.10.

Page to Update:

Need a grep.

Ref: kubernetes/kubernetes#58567

[aburdenthehand]

G'day, I'm happy to work on it if no one else is (not yet able to assign myself to an issue).

This impacts the following 17 files:
admin/high-availability/kube-apiserver.yaml
admin/authorization/node.md
admin/admission-controllers.md
admin/extensible-admission-controllers.md
concepts/workloads/pods/podpreset.md
concepts/configuration/pod-priority-preemption.md
concepts/storage/persistent-volumes.md
concepts/policy/resource-quotas.md
getting-started-guides/coreos/cloud-configs/master.yaml
getting-started-guides/scratch.md
imported/release/notes.md
reference/setup-tools/kubeadm/implementation-details.md
reference/generated/federation-apiserver.md
reference/generated/kube-apiserver.md
tasks/administer-cluster/running-cloud-controller.md
tasks/federation/set-up-placement-policies-federation.md
tutorials/clusters/apparmor.md

Most seem like straightforward replacements (and adding 'disable-admission-plugins' as required)- admin/admission-controllers.md is the obvious exception.

@tengqm, are you able to answer a couple of questions:

1. Language in the PRs seems to refer to them as 'admission plugins', rather than 'admission controls'. Should this change also be made throughout? And would 'admission control plugins' also work?
2. I gather order of plugins is no longer relevant in the comma-separated list. Is that correct?
   Thank you

[tengqm]

@aburdenthehand Cool. Would love to see your contribution.
Responses to your questions:

• Yes, team is advocating "plugins" as the term to use, although the transition isn't complete yet. We still have a flag named --admission-control-config-file.
• Good question on order of plugins. There are now mutating plugins and non-mutating plugins. The order of non-mutating plugins is no longer an issue. All non-mutating plugins are executed before mutating ones. The order of mutating plugins still matters. However, users don't need to care about this after refactor admission flag kubernetes#58123 is in. Kubernetes now knows which plugin should run before which one.

[aburdenthehand]

@tengqm Thanks mate

• Ack - I'll write around it in this PR while the term is in transition. Will raise a separate issue to cover that (looks like it'll impact strings in 34 files, not all of which will be simple replacements)
• Slightly confused: #58123 was merged, so does that mean we can tell 1.10 users that order doesn't matter, regardless of mutating/non-mutating? Or am I missing something?

[tengqm]

@aburdenthehand Yes. The order doesn't matter to users now.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tengqm]

@aburdenthehand Looks like this can be closed?

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale