phpfpm/CHANGELOG-8.5.10-b.md

Changelog - Version 8.5.10-b

⚠️ v8.5.10-b は単体では既存リリースの helm upgrade が失敗する不具合を含む （Deployment.spec.selector: ... field is immutable）。設計・原因の記録として 本ファイルは残すが、実際の適用は v8.5.10-c 以降を使うこと。修正内容は CHANGELOG-8.5.10-c.md を参照。

不具合修正・アーキテクチャ変更

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点）

1. resources values キーがテンプレート側で一切参照されていなかった（死んだ設定）。 values.yaml の resources: {} にどんな値を書いても、nginx・php-fpm・selenium いずれのコンテナにも CPU/メモリの requests・limits が反映されない実装だった。 このため全コンテナが QoS Class: BestEffort（実際のデプロイでも確認済み）で動作し、 ノードのメモリ逼迫時に Linux の OOM Killer に真っ先に狙われる状態だった。 Selenium（Chromium）はメモリを多く消費するため、Raspberry Pi 等のメモリに余裕がない ノードでは他コンテナの OOM Kill を誘発しやすい。
2. 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 ラベルを付与し、セレクタが混線しないようにした。
• resources values キーを実際にコンテナへ反映されるよう修正し、nginx・php-fpm・ selenium で個別に設定できる構造に変更した:

  resources:
    nginx: { requests: {...}, limits: {...} }
    phpfpm: { requests: {...}, limits: {...} }
  
  selenium:
    resources: { requests: {...}, limits: {...} }
  

  既定値は空（{}）で、requests/limits なしの現行動作を維持する。本番運用では 設定を強く推奨する（推奨値の例は values.yaml のコメントを参照）。

互換性（重要・要対応）

• selenium.enabled: true を使っている既存リリースは、アップグレード後に 以下の対応が必要:
  1. Selenium コンテナがそれまで暗黙にマウントしていた PVC の html サブパスに 依存していた場合（例: ブラウザのダウンロード先を公開ディレクトリに置いていた等）、 selenium.mountHtml: true を設定し、persistence.accessMode を ReadWriteMany に変更する。依存していなければ何もする必要はない （既定 mountHtml: false のままでよい）。
  2. phpEnv.SELENIUM_URL に http://localhost:4444/wd/hub 等を手動設定している場合、 Selenium が別 Pod になったことで localhost には到達できなくなる。ただし チャートが自動的に新しい Service を指す値へ上書きするため、多くの場合は 何もしなくても動作する（自動注入の値が env リストの後方にあるため優先される）。 設定の混乱を避けるため、phpEnv.SELENIUM_URL の手動指定は削除することを推奨する。
• 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）