This is more of a theoretical question. How do you guys create the structure of a Kubernetes deployments/services/pods that runs multiple applications?
Let's say I want to run 3 Wordpress websites on my servers. For this I need: Nginx, MySQL, PHP-FPM and the Wordpress code base.
Is it better to spin off separate pods/services for Nginx, MySQL, PHP-FPM that will serve all 3 Wordpress websites and create 3 Wordpress pods/services for the 3 websites?
OR is it better to create a separate pods/service for each one of the websites, therefore the grouping would be:
With option 2 I would need somehow to route the specific website traffic to the specific service/pod
Kubernetes is extremely flexible as you are discovering and allows you to architect you application in numerous ways. As a general rule of thumb, only run one process per container per pod. However, there definitely valid use cases for running multiple containers in a pod. I think for your use case, you can use both approaches.
Let me attempt to break down each of your components:
MySQL
I would definitely run this in it's own pod. I would wrap it in a StatefulSet and front it with its own Service
Nginx + Wordpress
In my opinion, whether you run these two processes in one pod or two depends on how you are using tls, if at all. As we know, Wordpress is very vulnerable to attacks. Hence, perhaps you have rules in your Nginx config to limit access to certain paths, methods, etc. If you run Nginx and Wordpress in the same pod, then you can expose only the Nginx port and the only way traffic will get to the Wordpress container is if it goes through Nginx. If you run these containers as separate pods, then from a security standpoint, you'll need some other way to make sure that inbound traffic to your Wordpress pod only comes from your Nginx pod. You can accomplish this with the NetworkPolicy resource or you can just use mutual TLS between these two pods.
In summary, in a microservice architecture, you want your process to be as decoupled as possible so that they can be managed and deployed separately. Hence, a single process per container per Pod is attractive. However, there are instances that require you to run more than one container per Pod. In my example I used security as such motivation.