/tags/vpc/ Recent content in VPC on LIFELOG Hugo -- gohugo.io ja © 2026 0222-nnn Wed, 02 Sep 2026 00:00:00 +0900 /blog/20260902_terraform_gcp_advanced_gke_routes_based_ip_masq/ Wed, 02 Sep 2026 00:00:00 +0900 /blog/20260902_terraform_gcp_advanced_gke_routes_based_ip_masq/ <h2 class="relative group">概要 <div id="概要" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100"> <a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700" style="text-decoration-line: none !important;" href="#%e6%a6%82%e8%a6%81" aria-label="アンカー">#</a> </span> </h2> <p>複数のGoogle Cloud Projectをまたぐ構成では、「別チームのVMへ自分のPodから届かない」という壁にぶつかります。</p> <p>相手側の設定を変えられない、あるいは変えたくない場面もあります。自分側だけで解決したいところです。</p> <p><strong>この記事は、いったん公開した内容を実測で覆したものです。</strong></p> <p>当初は「routes-basedなクラスタでは Pod のルートが交換されないから失敗する」と説明していました。<strong>確かめたら、どちらも違いました。</strong></p> <table> <thead> <tr> <th>当初の説明</th> <th>実測</th> </tr> </thead> <tbody> <tr> <td>routes-based なクラスタ</td> <td><code>useIpAliases: true</code> で <strong>VPC-native</strong></td> </tr> <tr> <td>Pod CIDR 宛のルートは交換されない</td> <td><code>peering-route-...</code> として<strong>交換されていた</strong></td> </tr> <tr> <td>失敗の原因はルートの非交換</td> <td><strong>宛先側のファイアウォール</strong></td> </tr> </tbody> </table> <p>結果そのものは変わりません。宛先側を触らず ConfigMap だけで復旧できます。<strong>変わったのは、なぜ直るのかの説明です。</strong></p> <p>Terraformの基本操作は前提としています。Dataplane V2 などのハードニング設定は<a href="/blog/20260902_terraform_gcp_advanced_gke_dataplane_v2_networkpolicy/">前回のNetworkPolicy記事</a>で扱っています。</p> <h2 class="relative group">検証すること <div id="検証すること" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100"> <a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700" style="text-decoration-line: none !important;" href="#%e6%a4%9c%e8%a8%bc%e3%81%99%e3%82%8b%e3%81%93%e3%81%a8" aria-label="アンカー">#</a> </span> </h2> <ul> <li>2プロジェクト構成で、PodからPeering先のVMへのcurlが失敗すること（Step 1: 再現）</li> <li><strong>宛先側の設定を変えず、ip-masq-agentのConfigMapだけで成功すること</strong>（Step 2: 解決）</li> <li><strong>クラスタは routes-based なのか VPC-native なのか</strong></li> <li><strong>Pod CIDR 宛のルートは Peering で交換されているのか</strong></li> <li><strong>失敗の原因はルートなのかファイアウォールなのか</strong>（対照実験）</li> </ul> <h2 class="relative group">前提環境 <div id="前提環境" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100"> <a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700" style="text-decoration-line: none !important;" href="#%e5%89%8d%e6%8f%90%e7%92%b0%e5%a2%83" aria-label="アンカー">#</a> </span> </h2> <ul> <li>Google Cloud CLI、Terraform、Docker</li> <li>Billingが有効な検証用Google Cloud Project <strong>2つ</strong></li> <li>GKE、Compute Engine、VPC Peeringを操作できるGoogleアカウント</li> <li>検証時のバージョン：Terraform 1.14.3、google 7.46.0</li> </ul> <p>GKE・ノードイメージ・ip-masq-agent のバージョンは記録していません。ip-masq-agent が既定で入るかどうかも、既定の <code>nonMasqueradeCIDRs</code> も、このあたりで変わります。再現するなら次を控えておきます。</p>