リクエストライフサイクル全体図（LB→メッシュ→Pod）

1リクエストはいくつの層を通るのか

ブラウザのアドレスバーに URL を入れてから、実際の処理を担う Pod のプロセスがバイト列を読むまでに、リクエストは驚くほど多くの層を通過します。各層は「自分が終端するもの」と「下位へ委譲するもの」を持ち、責務がはっきり分かれています。この全体像を1枚の地図として持っていないと、障害切り分けで「TLS エラーはどの層で起きたのか」「リトライはどこで増えたのか」を追えません。

本記事では、外部リクエストが DNS → CDN/エッジ → L4ロードバランサ → L7 Ingress → サービスメッシュのサイドカー → Pod へ届くまでの経路を、段階順に追います。各層で TLS の終端・ルーティング・認証・リトライ がどう扱われるかを切り分け、最後に層ごとの責務を表で並べます。

全体像：層の積み重なり

まず全体を1枚で俯瞰します。左から右へ、外部から内部へ向かう経路です。

[クライアント]
   │  ① 名前解決（DNS）
   ▼
[DNS / GeoDNS]──返すのは「最も近いエッジのIP」
   │  ② TCP/TLS確立（Anycastで最寄りエッジへ）
   ▼
[CDN / エッジ]──TLS終端#1・キャッシュ判定・WAF
   │  ③ オリジンへ転送（再暗号化）
   ▼
[L4 ロードバランサ]──IP:Portで分散・TLSは素通し
   │  ④ ノードのNodePort等へ
   ▼
[L7 Ingress / APIゲートウェイ]──TLS終端#2・パス/ホストでルーティング・認証
   │  ⑤ ClusterIPサービス経由でPod群へ
   ▼
[サイドカー(送信側)]──mTLSで張り直し・リトライ・LB
   │  ⑥ サイドカー間mTLS
   ▼
[サイドカー(受信側)]──mTLS終端・認可・平文で渡す
   │  ⑦ localhost
   ▼
[アプリコンテナ(Pod)]──業務処理

層が「積み重なる」ことの本質は、各層が直下の層の詳細を知らなくてよい 点にあります。Ingress は CDN がどこにあるか知らず、Pod は Ingress のルーティング規則を知りません。各層は前段から受け取った入力（多くは HTTP ヘッダ）だけを頼りに自分の責務を果たし、結果を後段へ渡します。

段階を追う：DNS から TCP 確立まで

最初の関門は 名前解決 です。クライアントは example.com の IP を DNS に問い合わせます。グローバルサービスでは GeoDNS や DNS ベースの広域負荷分散が使われ、問い合わせ元の位置に応じて 最も近いエッジの IP を返します。ここでの「ルーティング」はまだ TCP コネクションすら張る前の、IP 選択という最も粗い粒度の分散です。

返ってきた IP がしばしば Anycast アドレス であることが重要です。同じ IP を世界中の複数エッジが広告し、BGP の経路選択でクライアントは最寄りのエッジへ自動的に届きます。つまり「どのエッジに着くか」はネットワーク層が決め、アプリは関与しません。

エッジ層：1回目の TLS 終端

クライアントが最寄りエッジに TCP を張ると、TLS ハンドシェイク が始まります。エッジ（CDN）はここで TLS を終端 します。これが本経路における最初の終端点です。終端とは「暗号化を解いて中身の平文 HTTP を読める状態にする」ことで、これができて初めて以下が可能になります。

• ホスト名（SNI／Host ヘッダ）を見たキャッシュ判定とコンテンツ配信
• WAF による不正リクエストの検査・遮断
• どのオリジンへ転送するかの判断

キャッシュにヒットすればここで応答が返り、リクエストはオリジンまで届きません。ヒットしなければ、エッジは オリジン（自社の入口）へ向けて再びコネクションを張り直し、多くの場合 再暗号化 して転送します。ここで原則が一つ見えます——TLS は層を移るたびに終端・再確立される。エッジ＝クライアント間の TLS と、エッジ＝オリジン間の TLS は別物のコネクションです。

L4 ロードバランサ：TLS を素通しする層

オリジンの入口には多くの場合 L4（トランスポート層）ロードバランサ が立ちます。L4 LB は IP アドレスとポート番号だけ を見て分散し、ペイロードの中身（HTTP の URL やヘッダ）は見ません。だから TLS を終端しません——暗号化されたバイト列を、コネクション単位でそのまま後段へ転送します。

ここが L4 と L7 の決定的な違いです。分散アルゴリズムの選択肢（ラウンドロビン、最小接続数、ハッシュなど）は /devops/load-balancer-algorithms/ で扱うとおりですが、L4 はコネクション全体を1つの後段へ固定的に割り当てるのに対し、L7 は同一コネクション上の 個々のリクエスト を別々の後段へ振り分けられます。

L4 LB:  見るのは IP:Port のみ → コネクション単位で分散、TLSは素通し
L7 LB:  HTTPを終端して中身を見る → リクエスト単位で分散、パス/ホストで判断

L4 が素通しすることで、TLS 終端の負荷とポリシー判断を内側の L7 層へ集約できます。Kubernetes ではクラウドの L4 LB がトラフィックをノードへ届け、そこから先のサービス VIP の解決は /devops/kube-proxy-service-vip/ のとおりノード内で行われます。

L7 Ingress / API ゲートウェイ：2回目の終端とアプリ層ルーティング

クラスタの入口に立つ Ingress コントローラ（L7 ロードバランサ／API ゲートウェイ） が、本経路で 2回目の TLS 終端 を行います。ここで初めてクラスタ内部で HTTP の中身が読め、アプリケーション層の処理が集中します。

• ルーティング：Host ヘッダとパスを見て、/api は API サービス、/img は画像サービス、というように リクエスト単位 で振り分ける。これが L7 ルーティングの本体です。
• 認証・認可（エッジ認証）：API キーや JWT、OIDC トークンの検証をここで一度行い、不正なリクエストをクラスタ内部へ入れない。境界での認証です。
• TLS 終端と内部への張り直し：外部向けの証明書をここで終端し、内部はサービスメッシュの mTLS へ引き継ぐ。

サービスメッシュ：サイドカーが担う層

Ingress を抜けたリクエストは、宛先 Pod の サイドカープロキシ へ届きます。サービスメッシュ（/devops/service-mesh/）は、各 Pod に小さなプロキシ（サイドカー）を同居させ、サービス間通信の制御をアプリのコードから剥がして プロキシ側へ寄せる仕組みです。内部動作は /devops/service-mesh-sidecar-internals/ に詳しいですが、ここでの責務は明確です。

1. mTLS の張り直し：送信側サイドカーと受信側サイドカーの間で相互 TLS を確立する。双方が証明書で互いを認証し、通信を暗号化する。Pod のワークロード ID に基づく認証は /devops/workload-identity-mtls/ のとおり、SPIFFE 形式の ID を証明書へ載せて「呼び出し元のサービスは誰か」を暗号的に保証します。
2. きめ細かいルーティングと負荷分散：宛先サービスの複数 Pod のうちどれへ送るかを、レイテンシや重み付けで決める。カナリアの重み付け配信もここで行われます。
3. リトライ・タイムアウト・サーキットブレーカ：失敗時の再試行、上限時間、/devops/circuit-breaker-bulkhead/ の遮断をサイドカーが担う。アプリは1回呼ぶだけで、再試行はプロキシが面倒を見ます。

受信側サイドカーは mTLS を終端し、認可ポリシーを評価したうえで、localhost 経由で平文の HTTP をアプリコンテナへ渡します。つまり Pod 内のアプリは、暗号化も再試行も意識せず平文を受け取る——これがメッシュが「通信の関心事をアプリから剥がす」ことの具体的な姿です。

各層の責務を1枚に並べる

これまでの段階説明を、責務の軸で横断的に整理します。空欄に近い層は「その責務を担わず下位へ委譲する」ことを意味します。

この表から、いくつかの設計原則が読み取れます。TLS は2回終端され（エッジとクラスタ境界）、内部ではサイドカー間 mTLS で3度目の暗号化が張られる。ルーティングは層ごとに粒度が違い、外側ほど粗く（IP 選択）、内側ほど細かい（リクエスト単位）。認証は段階的に深まり、境界では「外部ユーザーか」、メッシュでは「どのサービスか」を問う。リトライの主担当はサイドカー に寄せ、他層では極力重ねない。

折り返しと健全性

ここまでは「行き」の経路ですが、応答は同じ層を逆順に戻ります。各層が張ったコネクション（クライアント＝エッジ、エッジ＝Ingress、サイドカー間 mTLS）をそれぞれ逆向きにたどり、ヘッダで引き継いだコンテキストを保ったまま応答を返します。

この経路全体が健全に流れる前提として、各層は 直下が受け付け可能か を常に確認しています。L4・L7・メッシュはいずれもヘルスチェック（/devops/health-check-probes/）で不健全な後段を分散対象から外し、Pod の終了時には /devops/graceful-shutdown-draining/ のとおり既存接続を捌き切ってから抜ける（ドレイン）ことで、経路の途中で握ったリクエストを落とさないようにします。

まとめ

• 外部リクエストは DNS → CDN/エッジ → L4 LB → L7 Ingress → メッシュのサイドカー → Pod という層を順に通り、各層は固有の責務を持って上位の情報をヘッダで下位へ引き継ぐ。
• TLS は層を移るたびに終端・再確立される。エッジで1回、クラスタ境界の L7 で1回終端し、内部はサイドカー間 mTLS で張り直す。L4 は終端せず素通しする。
• ルーティングの粒度は外側ほど粗く内側ほど細かい。DNS/Anycast は IP 選択、L4 はコネクション単位、L7 とメッシュはパス・ホスト・重みを見たリクエスト単位。
• 認証は段階的。境界（Ingress）では外部ユーザーの素性、メッシュでは呼び出し元サービスのワークロード ID を mTLS で検証する。
• リトライ・タイムアウト・遮断はサイドカーへ集約 し、多層で重ねて再試行を増幅させない。リトライ予算で総量に上限をかける。