こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「一つの仮想サーバー（VM）の中に、まるで小さなアパートのようにたくさんのコンテナを住まわせたい」という要件にぶつかることがよくあります。
GCP（Google Cloud）の世界で、Kubernetesをはじめとするコンテナオーケストレーションツールがなぜあんなにも軽快に、そして複雑なネットワークを難なくクリアして動いているのか。その秘密の鍵を握るのが、今回取り上げる「エイリアスIPレンジ（Alias IP ranges）」という仕組みです。
「IPアドレス」「サブネット」「ネットワーク仮想化」……。初学者のうちは、なんだか呪文のように難しく聞こえる言葉ばかりですよね。でも、大丈夫です！今回は、私たちの身近にある「郵便配達の仕組み」に例えながら、一歩ずつ優しく紐解いていきましょう。
—
1. エイリアスIPレンジってなに？身近な例えで考えてみよう
まずは、GCPの仮想マシン（VMインスタンス）を「大きなお家」に例えてみてください。
通常のクラウドの仕組みでは、VMインスタンスを1台作ると、その家には1つの「表札（プライベートIPアドレス）」が与えられます。郵便屋さん（他のサーバー）は、その表札めがけて荷物を届けますよね。
ここで、こんなシチュエーションを想像してください。
「この一軒家の中に、実は3人の家族（コンテナ）が住んでいて、それぞれが別々に郵便物を受け取りたい！」
もし表札が1つしかなかったらどうなるでしょう？届いた荷物は全部リビングの玄関に山積みになり、「これ、誰宛ての子包！？」と大混乱になってしまいますよね。
だからといって、家族の人数分だけ大きなお家（VMインスタンス）を建てるのは、家賃（コスト）もかかるし管理も大変です。
そこで登場するのが「エイリアスIPレンジ」です。
これは、1つのお家（VMインスタンス）に、複数の「部屋番号付きの追加の表札（IPアドレス）」をまとめて割り当てる魔法の仕組みなんです。
- メインの表札:
10.128.0.2（VMインスタンス自体のIP） - 追加の表札（エイリアスIP）の束:
10.244.0.0/24や192.168.10.0/24など
これなら、郵便屋さん（他のVMや外部ネットワーク）は、ちゃんと言い伝えられた「部屋番号（エイリアスIP）」めがけて、荷物をダイレクトに配達できるようになります。
—
2. なぜKubernetesでエイリアスIPが必要なの？
GCPのマネージドKubernetesサービスである GKE (Google Kubernetes Engine) では、このエイリアスIPがデフォルトのネットワーク方式（VPCネイティブクラスター）として使われています。
昔のKubernetesは、コンテナ同士の通信を行うために、仮想的なオーバーレイネットワーク（トンネル）をわざわざ作っていました。これは例えるなら、「手紙をいったん別の封筒に入れて、二重に包装して送り直す」ようなもの。包み直す手間にCPUのパワーが使われてしまいますし、パケットの構造も複雑になります。
しかし、GCPのエイリアスIPを使えばどうでしょう？
GCPの物理・仮想ネットワーク（VPC）自体が、「あ、その部屋番号（エイリアスIP）を持つコンテナね、このVMの中継地点へ直接届ければいいんだな」と最初から理解してくれます。
結果として、余計なカプセル化（オーバーレイ）をせず、素のIPパケットのまま爆速で通信できるという、パフォーマンスと管理性の両方を手に入れられるのです。
—
3. 実践！GCPでエイリアスIPを設定してみよう
理屈が分かったところで、実際にGoogle CloudのCLI（gcloudコマンド）を使って、エイリアスIPを持ったVMインスタンスを構築する手順を見ていきましょう。
実務の現場でもそのまま使える設定例を用意しましたので、一緒に見ていきましょうね。
ステップ1: VPCネットワークとサブネットの準備
まずは、VMが所属する土台となるVPCネットワークとサブネットを作ります。ここでは、エイリアスIPとして割り当てるための「セカンダリIPレンジ」をあらかじめ定義しておくのがポイントです。
# 1. カスタムモードのVPCネットワークを作成します
gcloud compute networks create my-custom-vpc \
--subnet-mode=custom
# 2. サブネットを作成し、コンテナ用のエイリアスIPとして使う「セカンダリレンジ」を定義します
gcloud compute networks subnets create my-subnet \
--network=my-custom-vpc \
--region=asia-northeast1 \
--range=10.128.0.0/20 \
--secondary-range=k8s-pod-range=10.244.0.0/16
# ↑「k8s-pod-range」という名前で、10.244.0.0/16 のIPの束をコンテナ用に予約しています！ステップ2: エイリアスIPを持つVMインスタンスの作成
次に、先ほど作ったサブネットを指定し、さらにその中からエイリアスIPレンジを割り当てたVMインスタンスを建てます。
gcloud compute instances create my-app-server \
--zone=asia-northeast1-a \
--machine-type=e2-medium \
--subnet=my-subnet \
--private-network-ip=10.128.0.2 \
--aliases=k8s-pod-range=10.244.0.0/24
# ↑ --aliases オプションで、先ほどのセカンダリレンジの中から
# 「10.244.0.0/24」のブロックをこのVMのエイリアスIPとしてガッツリ割り当てています。これで、my-app-server というお家の中に、10.244.0.0/24 という一団の「部屋番号たち」が紐付けられました！このVM上で動くDockerやKubernetesのkubeletは、この範囲から自由にご近所のコンテナへIPを配分できるようになります。
—
4. 現場のSREが教える！トラブルシューティングの勘所
ここまで順調に見えますが、現場でエイリアスIPを扱う際にはいくつか注意すべきポイント（ハマりどころ）があります。先輩SREからのちょっとしたアドバイスです。
① ルーティングの魔法（GCPのVPCがすべてを知っている）
従来のオンプレミス環境や古いクラウドだと、「追加のIPを使うには、OS側でIPエイリアス（ip addr add など）の設定をしなきゃいけないんだっけ？」と混乱しがちです。
しかし、GCPのエイリアスIPはGCPのコントロール plane（VPCルーター）側が賢くルーティングを管理してくれます。
「10.244.0.5 宛てのパケットが来たら、あのVMインスタンスへ投げればいいんだな」とGoogle側のルーターが知っているため、VM自体のOSネットワーク設定がシンプルで済むのが大きなメリットです。
② IPアドレスの枯渇問題（CIDR設計の重要性）
エイリアスIPレンジを設計するときに最も頭を悩ませるのが「IPのサイジング（サイズ見積もり）」です。
Kubernetesクラスターが将来的にどれくらい巨大化し、何個のポッド（コンテナ）が立ち並ぶかを予測し、適切なプレフィックス長（/16 や /24 など）を最初から設計図に組み込んでおく必要があります。
途中で「やっぱりIPが足りなくなったから広げたい！」となると、サブネットやレンジの再作成が必要になり、大規模なメンテナンス（場合によってはクラスターの作り直し）に発展することも……。初期設計が勝負の分かれ道です！
—
5. まとめ
今回は、GCPのエイリアスIPレンジについて、身近な「お家と部屋番号」の例えを交えながら解説しました。
- エイリアスIPレンジとは: 1台のVMインスタンスに複数のIPアドレス（の束）をスマートに持たせる仕組み。
- メリット: 余計なカプセル化（オーバーレイ）をせず、GCPのVPCルーティングと直接連携して高速なネットワークを実現できる（GKEのVPCネイティブクラスターの土台）。
- ポイント: 初期設計でのIPレンジ（CIDR）のサイジングが非常に重要！
クラウドやネットワークの仕組みは、一見すると難解な用語の壁に阻まれがちですが、私たちが普段暮らしている社会のルールや仕組みに置き換えてみると、スッと腑に落ちるものです。
インフラやネットワークの世界は、泥臭くもあり、綺麗に噛み合ったときの爽快感は格別です。この記事が、あなたのクラウド学習の楽しい一歩になれば、SREとしてこれ以上嬉しいことはありません。
それでは、また次回の技術解説でお会いしましょう！
コメント