Document the different ways the PolicyServer CRD can be useful

[viccuad]

There are several reasons one may want separate PolicyServers instead of only the default one. Most of the times one doesn't need to think about them, but they may be useful for specific personas:

• You might have a set of policies that are critical, and want to run them with more redundancy/more CPU/memory resources.
• You might want to isolate a noisy tenant from the other ones of the cluster. You could schedule a Policy Server to host the policies that belong to this tenant
• You might want to schedule special policies (like our alpha kyverno policy) over this server. So that iterating over different configuration doesn't slow down the deployment of a Policy Server that hosts more stable and critical policies
• You can also allow tenants to self-service by instantiating their own PolicyServers and policies
• When dealing with context aware policies (the ones that read kubernetes information to take decisions), you could have Policy Servers running with ad-hoc Service Account. For example, if you need a policy to be able to read secrets across the whole cluster, you could create a ServiceAccount with this RBAC permission, then allocate a dedicated Policy Server using this ServiceAccount and, finally, deploy that context-aware policy over there

Acceptance criteria

Add these to the docs. For example under how-to's -> operator manual -> Configuring PolicyServers or Explanations -> PolicyServers.

[jhkrug]

I suggest both places. In Explanations for a high level view (to answer the question as it appeared in the Slack thread (Why would I want 2 or more Policy Servers?)). And an example in How-tos with detail of how to implement.