[Bug]: Issue with Documentation on Pod Affinity and Anti-Affinity

### Installation method

Own AWS account

### What happened?

Towards the end of the this [page](https://www.eksworkshop.com/docs/fundamentals/managed-node-groups/affinity/) this statement seems to be incorrect.

> If we check the running pods we can see that the third checkout pod has been placed in a Pending state since there are only two nodes and both already have a pod deployed

There are three nodes available ( third node was added in the beginning of the lab). I think the third checkout pod is in pending state because in the third node there was no redis pod (affinity rule).

### What did you expect to happen?

Document may be updated to:

If we check the running pods we can see that the third checkout pod has been placed in a Pending state since there are three nodes and the new checkout pod cannot be scheduled on the third node because checkout-redis pod is not running in that node.

### How can we reproduce it?

Please scale the checkout-redis pod to 3 and notice that third checkout pod is in ready state.

`kubectl scale --replicas=3 deployment/checkout-redis --namespace checkout`

### Anything else we need to know?

_No response_

### EKS version

1.23