selenium.enabled=true構成でphp-fpmのCrashLoopBackOffとサイト完全停止が続いた件を調査し、2つの設計上の欠陥を確認した。(1) resources values キーがテンプレートで一切参照されておらず、全コンテナがQoS Class: BestEffortで動作しOOM Killされやすい状態だった。(2) nginx/php-fpm/SeleniumをすべてSelenium同一Podで起動しており、Kubernetesの Pod Ready判定(全コンテナのAND)により、Seleniumだけが不調でもPod全体がServiceのEndpointsから外れ、Seleniumを使わない静的ページ配信まで巻き込まれてサービス全体が停止していた。対応: Seleniumを独立Deployment(<release>-phpfpm-selenium)/Serviceに分離し、SELENIUM_URLを自動注入。resourcesをnginx/phpfpm/selenium個別に構造化して実際にコンテナへ反映されるよう修正。詳細はCHANGELOG-8.5.10-b.md参照。
6.4 KiB
Changelog - Version 8.5.10-b
不具合修正・アーキテクチャ変更
Selenium を独立した Deployment/Service に分離(サービス完全停止の防止)
背景(実際に発生した障害)
selenium.enabled: true の構成(hotels / booking.e-stay.jp)で、php-fpm コンテナの
CrashLoopBackOff が断続的に発生し、その間サイト全体が Nginx の 502(unsupported FastCGI protocol version)で完全に閲覧不能になる障害が続いた。v8.5.9-d で php-fpm の
起動方式(exec php-fpm -F)を修正した後も、8時間で1,375回という高頻度の再起動が
継続して観測された。
原因(確定した2点)
resourcesvalues キーがテンプレート側で一切参照されていなかった(死んだ設定)。values.yamlのresources: {}にどんな値を書いても、nginx・php-fpm・selenium いずれのコンテナにも CPU/メモリの requests・limits が反映されない実装だった。 このため全コンテナがQoS Class: BestEffort(実際のデプロイでも確認済み)で動作し、 ノードのメモリ逼迫時に Linux の OOM Killer に真っ先に狙われる状態だった。 Selenium(Chromium)はメモリを多く消費するため、Raspberry Pi 等のメモリに余裕がない ノードでは他コンテナの OOM Kill を誘発しやすい。- nginx・php-fpm・Selenium を同一 Pod のコンテナとして起動しており、Pod の Ready 判定
が「全コンテナの AND」になっていた。 readinessProbe を持たないコンテナは、
Running であれば Ready 扱いになる一方、CrashLoopBackOff で Waiting/Terminated を
繰り返している間は Ready=false になる。Kubernetes の Service は Pod 全体が Ready
でなければ Endpoints に含めないため、Selenium だけが不調でも Service の
Endpoints がゼロになり、Selenium を全く使わない静的ページの配信まで巻き込まれて
サイト全体が停止していた。
replicaCount: 1(冗長性なし)の構成では、この1点が 即・全断につながる。
(OOM Kill が今回の php-fpm クラッシュの直接のトリガーだったかは、kubectl describe pod
の Last State / Reason 等での確認が必要で、本リリース時点では未確認・要検証。
ただし上記2点はコード上で確認できる確定した設計上の欠陥であり、いずれも本番運用の
安定性を損なうため、原因の切り分けを待たずに先に修正する。)
対応
selenium.enabled: trueのとき、Selenium は nginx/php-fpm と別の 独立した Deployment(<release>-phpfpm-selenium)と Service として起動するように 変更した(templates/deployment-selenium.yaml/templates/service-selenium.yamlを新設)。- php-fpm コンテナの
SELENIUM_URL環境変数は、selenium.enabled: trueのとき 自動的にこの新しい Service(http://<release>-phpfpm-selenium:4444/wd/hub)を 指すよう自動注入される(phpEnvで独自に設定していても、こちらが優先される)。 selenium.replicaCount(既定1)で Selenium の Pod 数を独立して設定可能。selenium.mountHtml(既定false):trueにすると Selenium コンテナにも PVC のhtmlサブパスをマウントする。別 Pod からの同時マウントになるため、 有効にする場合はpersistence.accessMode: ReadWriteMany(NFS バックエンドの StorageClass なら対応可能)が必要。- メインの Service(
<release>-phpfpm)・Deployment にはapp.kubernetes.io/component: webラベルを、Selenium 側にはcomponent: seleniumラベルを付与し、セレクタが混線しないようにした。
- php-fpm コンテナの
resourcesvalues キーを実際にコンテナへ反映されるよう修正し、nginx・php-fpm・ selenium で個別に設定できる構造に変更した:既定値は空(resources: nginx: { requests: {...}, limits: {...} } phpfpm: { requests: {...}, limits: {...} } selenium: resources: { requests: {...}, limits: {...} }{})で、requests/limits なしの現行動作を維持する。本番運用では 設定を強く推奨する(推奨値の例はvalues.yamlのコメントを参照)。
互換性(重要・要対応)
selenium.enabled: trueを使っている既存リリースは、アップグレード後に 以下の対応が必要:- Selenium コンテナがそれまで暗黙にマウントしていた PVC の
htmlサブパスに 依存していた場合(例: ブラウザのダウンロード先を公開ディレクトリに置いていた等)、selenium.mountHtml: trueを設定し、persistence.accessModeをReadWriteManyに変更する。依存していなければ何もする必要はない (既定mountHtml: falseのままでよい)。 phpEnv.SELENIUM_URLにhttp://localhost:4444/wd/hub等を手動設定している場合、 Selenium が別 Pod になったことでlocalhostには到達できなくなる。ただし チャートが自動的に新しい Service を指す値へ上書きするため、多くの場合は 何もしなくても動作する(自動注入の値が env リストの後方にあるため優先される)。 設定の混乱を避けるため、phpEnv.SELENIUM_URLの手動指定は削除することを推奨する。
- Selenium コンテナがそれまで暗黙にマウントしていた PVC の
resources: {}は元々どのコンテナにも一切効いていなかったため、この構造変更で 既存の動作が変わることはない(誰も実質的な値を得ていなかったため、破壊的変更にはならない)。
対象ファイル: templates/deployment.yaml, templates/deployment-selenium.yaml(新規),
templates/service.yaml, templates/service-selenium.yaml(新規), values.yaml,
README.md, Chart.yaml, CLAUDE.md, CHANGELOG-8.5.10-b.md
アップグレード手順
helm repo update
helm upgrade <リリース名> cafepieters/phpfpm --version 8.5.10-b -f values.yaml
selenium.enabled: true の場合、上記「互換性」を確認のうえアップグレードすること。
リリース日: 2026-09-26 担当: プロサーバーエンジニア(Claude)