kubernetes環境でphpアプリケーションを運用しようと思った時に、構成は意外と悩む部分かと思います
nginxやapacheが必要になるところが問題なんですよね
今回は nginx + php-fpm をkubernetesで動作させるパターンを考えていきます

観点は

耐障害性
管理しやすさ
socket接続
静的ファイルの取り回し
- アプリケーション内にjsやcssがある場合、それらはnginxがホスティングして、phpファイルはnginxを通してphp-fpmコンテナへという流れになる
  - CDNを使おうという話ではあるけども
好み

このへん+αな感じですかね

1.Supervisor

ひとつのコンテナでphp-fpmとnginxプロセスを動かします
docker以前のphp環境を持ってくるような感じになりますか
1コンテナ1プロセス？頭が固いなあ！

耐障害性
- コンテナ内部が複雑なので、面倒そうな雰囲気は感じる
- supervisorを理解していないと、liveness/readinessの設定は難しい
  - nginxやphp-fpmの動作に異常が起きるとどうなるのか、など
- コンテナとしては単独なので、上記をクリアできれば安定しそうではある
管理しやすさ
- imageを作るのが難しい
  - supervisorガチ勢なら余裕か
- ログの取り回しは地獄
socket接続はもちろん可能
静的ファイル配信も問題なし

非常に玄人向けなイメージ
1コンテナに全部詰め込むのが気持ち悪くない人

2.サイドカー

php-fpmとnginxそれぞれ独立したコンテナを1つのpodで動かします
1.からnginxとphp-fpmのコンテナを独立させた形
個人的にはこれにスタンダードを感じます

耐障害性
- 両方ともアプリケーションとしての動作に不可欠なコンテナなので、liveness/readinessは複雑になる
  - それぞれにlivenessを設定して、両方通したreadinessを設定するなど
- nginxとphp-fpmがペアなので、基本は一蓮托生かな
管理しやすさ
- nginxのimageは公式を使えばいいし、php-fpmもベースになる部分は公式でimageが出てるので比較的作りやすい
- ログに関してはphp-fpmをどうクリアするか次第
  - nginxはstdout/stderrで問題ない
  - nginxとphp-fpmがペアなのはログが見やすくなるかも
socket接続は可能
- コンテナ間の共用ボリュームを設定する必要がある
そのままだとアプリケーションファイルはphpコンテナ側にあるはずなので、静的ファイルがある場合は対策が必要
- 静的ファイルをnginxがホスティングできるようにする必要がある

supervisorなんてわからんわ、という人向け
バランスはいいと思います、なんのバランスか知らんけど

php-fpmとnginxを別のpodにしてservice間通信にします
2.のサイドカー構成をpod単位で独立させた形
kubernetesっぽい構成です

耐障害性
- それぞれ完全に独立しているので、liveness/readinessの設定がわかりやすい
  - けど、php単独のreadiness的なヘルスチェックは少し面倒
- 落ちてもコンテナひとつpodひとつなので、他の部分に影響を与えない
管理しやすさ
- 基本は2.と同じ
- nginxとphp-fpmのログを関連付けるのに分散トレーシング的なのは欲しい…
socket接続は不可能
静的ファイルの対応も2.と同じく必要
マルチAZの場合、nginxとphp-fpmがAZまたぎになることがあるので、パフォーマンスの問題がある

2.とあんまり変わらないし、kubernetes的でよさそうな雰囲気
ただしsocket接続ができなかったり、AZ問題があるなど、パフォーマンスの問題があります

ingress controllerにNGINX Ingress　Controllerを使用すれば、FastCGIをサポートしているので自前のnginxが必要なくなります
3.から間のnginxがなくなる形
設定方法は以下の公式ドキュメントで

耐障害性
- 単純に障害点が減るので強い
- php-fpmのreadinessについては2.3.と同じ
管理しやすさ
- これも単純に管理するものが減るので強い
- nginx側の細かいチューニングはnginx ingress controllerを完全理解する必要があるのはしんどい点かも
socket接続は不可能
nginxでの静的ファイルホスティングはちょっと厳しそう
マイクロサービス的にクラスタ内でphpから別のphp…となる場合は結局間のnginxが必要になるのでは？
- internal ingressみたいな感じでnginx ingress controllerで捌けるかどうか（わからん）

条件が揃えばかなり有力な選択肢になります
これのためにingress controllerを乗り換える、まではいかないかな

私は無難に2で運用しています
3はAZまたぎの遅延が受け入れられなかった
nginx ingress controllerも使ってない