Using Apache v2.4+ with mod_php disabled, php-fpm enabled, and mpm_event (instead of default mpm_prefork) provides better performance (and tuning options, IMO) for PHP/PHP-FPM and multi-threaded processes. Using nginx as the front-end web server in a "selective reverse proxy to apache2/httpd for PHP processes" will still offer the added benefits of the superior static file serving, caching options + simple reverse proxy + load balancing featureset of nginx and add the superior multi threaded performance of Apache.
My "answer" here, would be:
I recommend using Apache v2.4+ as a backend for PHP processes with nginx as your "public facing" reverse-proxy. The primary concern seems to be for scalability, so I think that my suggestion would provide greater scalability and reduce resource consumption "at scale", with only a minimal increase in resource consumption at idle.
This is where my curiosity kicks in (aka feeling curious, might delete later, idk):
Sorry if I'm necromancing this thread here, but there is limited material and content on this subject matter of splitting off PHP-FPM into a separate container from the web server.
I've asked about this very topic here, and here in the OP there is a vague mention of "scalability reasons".
Though my "answer" doesn't actually answer the question proposed in the OP... This is me proposing a solution by asking: "is this really the right question in the first place?"
I agree with the ultimate point @simbo1905 is trying to make, here. Just use the same container for the web server + php-fpm.
What is it about breaking off PHP-FPM from the web server (in this case: nginx) increases the scalability of an application? Why not use multiple instances of matching containers with nginx+php-fpm running together? Just as the answer by @simbo1905 suggests with apache2+php-fpm?
I see the points being made about security and scalability. I understand the concept of scaling up instances of php-fpm containers under heavy load, but nginx makes it VERY easy to load balance such load. Why not have the added benefit of additional load balanced resources if you are concerned about resource the resource usage php-fpm being scalable?
I'm not sure what the benefits are of having a separate PHP-FPM instance running are if you could just "spend" the extra tiny kb's of disk space and RAM for a more stable and performant application. If the PHP-FPM process(es) or the nginx process(es) fail, the application fails.
The case for making PHP/PHP-FPM "more secure" by having separated containers seems moot, also, considering the layers of protection to the PHP engine that are locked down by system users/groups with appropriate permissions. If anything, it seems like a larger attack surface for malicious actors to be able to pinpoint the port(s) that PHP-FPM is running on, instead of the "same system default" of connecting to php-fpm via unix socket(s).
All that said, I'm mostly asking for personal curiosity. I'm somewhat new to the nuances and performance tuning of Docker/Kubernetes, so I feel like there might be something I'm missing. In the research I've done, sometime around late 2019, many Devs/DevOps/Engineers seem to have started to lean towards putting EVERY service in its own separate container with PHP-FPM dependent applications. I have not yet wrapped my head around "why". It makes sense to me having a separate SQL/Datastore container. It also makes sense to me to isolate the web server in use cases where PHP/php-fpm or some other web server dependent service isn't required as a core function of the entire application. But in the cases where you need both the web server(s) and the back-end services to work in concert, I have yet to understand why the need to separate them.