Add new podAntiAffinity example and modify existing production-ready example

[paapug]

This PR adds podAntiAffinity example and modifies the existing procudtion-ready example so that the pods will not be scheduled on the same node. This should ensure higher availability in any Kubernetes cluster.

The pod-anti-affinity example uses preferredDuringSchedulingIgnoredDuringExecution type, while production-ready example uses requiredDuringSchedulingIgnoredDuringExecution as no production cluster should have potential one point of failure (i.e. one node).

[MirahImage]

Thanks for your contribution!

[mkuratczyk]

@MrPsycho5 can you explain why the changes to the production example are necessary? It already includes topologySpreadConstraint to make sure RabbitMQ nodes run in different AZs, which by extension also requires them to run on different Kubernetes nodes. Unless I'm missing something we should use one or the other but not both because:

1. users with multiple AZs don't need this additional anti-affinity rule
2. users with a single AZ need to remove the topologySpreadConstratint anyway (otherwise the pods can't be scheduled)

Thanks,

[paapug]

I have the following situations in my mind:

1. User has 3 availability zones, 5+ nodes and 5 rabbit replicas. We should not only make sure the replicas are spread across different availability zones, but also different nodes within single zone.
   Perhaps we should also change DoNotSchedule to ScheduleAnyway to allow for such situation.

2. If the user only has single availability zone (in which case he indeed needs to remove the topologySpreadConstratint) we should at least keep the good practice and require the spread of replicas on different nodes.

[mkuratczyk]

Dzięki Jakub! ;)