docs: kube-vip環境での実IP喪失原因と共有Ingress Controller移行手順を追記

mikoto-wordpress-nginxの調査で、type: ClusterIP + kube-vipアノテーション
による手動VIP付与構成では、kube-vip自体がTCP接続をプロキシするため
externalTrafficPolicyを設定しても実クライアントIPが失われることが判明。
共有Ingress Controller（Cilium組み込み等）へ移行する場合の具体的な
values設定とhelm upgradeコマンド例をREADMEに追加。
クラスタ構成の調査結果をCLAUDE.mdに記録。

CLAUDE.md

@@ -26,6 +26,16 @@ WordPress本体はイメージ内蔵のもの（`docker.io/wordpress:<tag>-fpm-a
 3. **Commit メッセージに Claude クレジット（Co-Authored-By 等）を追記することは禁止。** `user.name = Claude` でコミットされるため、ユーザー名で判別可能。
 4. `git pull` で取り込まれた変更は必ず尊重し、revert して push することは禁止（既存の共通ルールと同じ）。
 
+## クラスタ構成メモ（実運用環境）
+
+- ノード: `cpi11`(control-plane, 192.168.9.9/物理IF)、`wpi21`/`wpi22`/`wpi23`(worker)。全てRaspberry Pi(Ubuntu 25.04)。
+- CNI: **Cilium**（kube-proxyなし、eBPFベース）。`cilium-envoy` Podが動作しており、Cilium組み込みIngress Controller（Envoyベース）が利用可能。
+- Pod CIDR: `10.0.0.0/8`系、ノードごとに `/24` を割り当て（例: cpi11→`10.0.0.0/24`、wpi22→`10.0.1.0/24`、wpi21→`10.0.2.0/24`、wpi23→`10.0.3.0/24`）。
+- 外部公開: **kube-vip**（ARP方式、静的Pod `kube-vip-cpi11`）。物理ルーターのグローバルIP配下、`192.168.9.0/24` セグメント内でVIPを払い出す。このセグメントはルーターがLAN機器(スマホ/PC等)にDHCP払い出しする範囲と重複しないよう、ルーター側で範囲を絞って共存させている。**IPが希少なため濫用できない。**
+- 各WordPress/PHPFPMリリースは現状、`service.type: ClusterIP` + `kube-vip.io/loadbalancerIPs`/`kube-vip.io/vipHost` アノテーションを**Helm管理外で手動付与**し、リリースごとに個別のVIPを得る運用になっている（本チャートの `templates/service.yaml` にはannotationsのテンプレート化自体が存在しないため）。
+  - **既知の問題**: この構成では、kube-vipがL2 ARP応答に加えて自前でTCPコネクションをプロキシしてしまうため、`externalTrafficPolicy`（LoadBalancer/NodePort専用でありClusterIPには無効という制約とは別に、そもそもkube-vipの時点で）実クライアントIPが失われる。詳細はREADME.mdの「kube-vip等でグローバルIP/VIPが限られている環境での実IP取得（共有Ingress Controller構成）」を参照。
+  - 今後、実IP取得のためCilium組み込みIngress Controller（またはingress-nginx）へ移行する方針で合意済み（2026-08-08時点、ユーザーが選択）。ただし全リリース（wordpress-nginx系だけでなくphpfpm系も含む）の移行が必要な大掛かりな作業のため、本セッションではWordPressチャート側の対応（`ingress.yaml`/`forwardRealIP`は既存機能で対応済み、README migration手順を追記）のみ実施。実際のCilium Ingress有効化・各リリースのhelm upgradeはユーザー側の作業。
+
 ## チャート改修履歴
 
 ### 実IP取得の修正 + SMTP経由メール送信の追加（2026-08-08, v7.0.2-a）