スケーラブルで安全な Google Kubernetes Engine（GKE）クラスタを構築するには、IP アドレス指定を効果的に管理する必要があります。このドキュメントでは、GKE がクラスタ通信に IP アドレスを使用する方法、サポートされているネットワーキング モデル、効果的な IP アドレス管理のベスト プラクティスの概要について説明します。
このドキュメントは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。 Google Cloud内の一般的なロールとタスク例の詳細については、GKE Enterprise ユーザーの一般的なロールとタスクをご覧ください。
先に進む前に、次のコンセプトをよく理解しておいてください。
- 基本的なネットワーキング: IP アドレス、CIDR、ファイアウォール、ネットワーク アドレス変換（NAT）など。
- Kubernetes のコア コンポーネント: クラスタ、ノード、Pod、Service など。
IP アドレスが GKE コンポーネントを接続する方法
GKE は Kubernetes ネットワーキング モデルに基づいて構築されています。このモデルでは、通信のために各コンポーネントに個別の IP アドレスが必要です。以降のセクションでは、GKE がクラスタのコア コンポーネントに IP アドレスを割り当てて使用する方法について説明します。
ノード: GKE は、各ノード（Compute Engine VM インスタンス）に対して、ノードプールに関連付けられたサブネットのプライマリ IP アドレス範囲から内部 IP アドレスを割り当てます。この IP アドレスにより、ノードと Kubernetes コントロール プレーン間の通信が可能になります。ノードには、アウトバウンド インターネット アクセス用の外部 IP アドレスを割り当てることもできます。
Pod: Kubernetes の「Pod ごとの IP」モデルに従い、GKE は各 Pod に対して、ノードに割り振られた Pod の CIDR の範囲から一意の IP アドレスを割り当てます。GKE では、VPC ネットワークは Pod の IP アドレスをネイティブにルーティングします。この組み込みのルーティング可能性により、ネットワーク アドレス変換（NAT）を必要とせずに、異なるノード間でも Pod 間の直接通信が可能になります。単一の Pod 内のすべてのコンテナは同じ IP アドレスを共有し、
localhost経由で通信できます。Service: GKE は、各 Kubernetes Service に対して、専用のセカンダリ IP アドレス範囲から安定した仮想 IP アドレス（
ClusterIP）を割り当てます。このClusterIPは、Pod のグループに単一の信頼性の高いエンドポイントを提供します。ClusterIPにトラフィックを送信すると、GKE はそのトラフィックを Service 内の正常な Pod に自動的にロードバランスします。コントロール プレーン: プライベート クラスタでは、コントロール プレーンは Google が管理するテナント プロジェクト内に存在し、独自の内部 IP アドレス範囲を使用します。このテナント プロジェクトは VPC ネットワークに接続することで、クラスタの VPC ネットワーク内のコントロール プレーンとノード間の安全な通信が可能になります。この接続は通常、Private Service Connect を使用します。
ロードバランサ: アプリケーションをインターネットまたは VPC ネットワーク内で公開するには、Google Cloud ロードバランサを使用するように GKE を構成します。外部ロードバランサは、パブリック IP アドレスを使用します。内部ロードバランサは、VPC ネットワークのプライマリ サブネット範囲から内部 IP アドレスを使用します。
次の表は、GKE がクラスタ コンポーネントに IP アドレスを割り当てる方法をまとめたものです。
| コンポーネント | IP アドレスの割り当て方法 |
|---|---|
| ノード | GKE は、各ノードに内部 IP アドレスを割り当てます。GKE は、ノードのノードプールに関連付けられたサブネットのプライマリ IP アドレス範囲からこの IP アドレスを割り振ります。このサブネットは、クラスタのデフォルト サブネットまたは追加のサブネットのいずれかです。 |
| Pod | GKE は、各 Pod に対して、ノードに割り振られた Pod の CIDR の範囲から一意の IP アドレスを割り当てます。 |
| Service（ClusterIP） | GKE は、各 Service に対して、クラスタの VPC ネットワーク内の専用のセカンダリ IP アドレス範囲から安定した仮想 IP アドレス（ClusterIP）を割り当てます。 |
| コントロール プレーン | プライベート クラスタでは、GKE コントロール プレーンは、Google が管理するテナント プロジェクト内の独自の内部 IP アドレス範囲を使用します。このテナント プロジェクトは、通常は Private Service Connect を使用して VPC ネットワークに接続します。 |
| ロードバランサ | 外部ロードバランサは、パブリック IP アドレスを使用します。内部ロードバランサは、クラスタのサブネットのプライマリ IP アドレス範囲から内部 IP アドレスを使用します。 |
Kubernetes の IP アドレス指定と GKE 実装
GKE を効果的に使用するには、抽象化された Kubernetes ネットワーキング モデルと、GKE が Google Cloudでこのモデルを実装する方法の違いを理解する必要があります。
Kubernetes の IP アドレス指定モデル: オープンソースの Kubernetes プロジェクトでは、各 Pod に一意の IP アドレスを割り当てることが規定されています。すべての Pod の IP アドレスは、ネットワーク アドレス変換（NAT）なしで直接通信できます。これにより、Pod が割り当てられた IP アドレスを使用して相互に到達できるフラット ネットワーク空間が確保されます。
GKE の IP アドレス指定の実装: GKE は、VPC ネイティブ ネットワーキングとの統合により、 Google Cloud に Kubernetes の IP アドレス指定モデルを実装します。Pod を作成すると、GKE は VPC のエイリアス IP アドレス範囲から IP アドレスを割り振ります。これにより、各 Pod の IP アドレスは VPC ネットワーク全体でネイティブにルーティング可能になります。これにより、Pod 間だけでなく、Compute Engine インスタンスや Cloud SQL データベースなどの他の Google Cloud リソースとも直接通信が可能になります。同様に、GKE は VPC ネットワーク内の Kubernetes
ServiceIP アドレス（ClusterIPなど）を管理します。外部公開用のLoadBalancerService を作成すると、GKE はGoogle Cloud ロードバランサをプロビジョニングします。これらのロードバランサは、パブリック IP アドレスまたは VPC ネットワークの内部 IP アドレスを使用します。GKE は、 Google Cloudの堅牢な IP アドレス指定およびネットワーキング インフラストラクチャを使用して、Kubernetes の IP ベースのネットワーキング コンセプトをスケーラブルかつ安全な方法で実装します。
GKE ネットワーキング モデル: VPC ネイティブ クラスタ
GKE は、 Google Cloud のコア機能である VPC ネイティブ ネットワーキングを使用して、Kubernetes ネットワーキング モデルを実装します。
このモデルは、エイリアス IP アドレス範囲を使用します。VPC ネイティブ クラスタでは、Kubernetes は Pod の IP アドレスをノードの仮想ネットワーク インターフェースのエイリアス IP アドレス範囲として構成します。
この実装には、主に次のようなメリットがあります。
- VPC ネイティブのルーティング可能性: Pod の IP アドレスは VPC ネットワーク内で直接ルーティングできます。これにより、ネットワーク設計が簡素化され、Pod と他の Google Cloud リソース（Compute Engine インスタンスや Cloud SQL インスタンスなど）間の低レイテンシの直接通信が可能になります。
- ルート割り当ての節約: Pod にエイリアス IP アドレスを使用することで、GKE は各ノードにカスタム静的ルートを作成しません。これにより、VPC ルート割り当てが節約されます。これは、以前のルートベース クラスタからの大幅な改善であり、大規模なデプロイの場合に重要です。
- セキュリティの強化: VPC ネイティブのルーティング可能性により、VPC ネイティブのファイアウォール ルールを Pod トラフィックに直接適用して、ネットワーク レベルのセキュリティを強化できます。
VPC ネイティブは、すべての GKE クラスタでデフォルトの推奨ネットワーキング モードです。
効果的な IP アドレス管理が不可欠な理由
クラスタがスケーリングできるようにしてアプリケーションの健全性を維持するには、IP アドレス空間を効果的に計画する必要があります。
- スケーラビリティの確保: ノード、Pod、Service の IP アドレス範囲を効果的に計画して、IP アドレスの枯渇を防ぎ、中断を伴うネットワークの再構築を必要とせずにクラスタがスケーリングできるようにします。
- 信頼性の保証: GKE クラスタと他のネットワーク（Cloud VPN 経由で接続されたオンプレミス環境など）間で IP アドレス範囲が重複しないようにします。範囲が重複すると、ルーティングの競合、予期しない動作、サービスの中断が発生する可能性があります。
- セキュリティの強化: IP アドレスを効果的に管理して、ネットワーク セキュリティを強化します。Kubernetes ネットワーク ポリシーを定義して Pod 間のトラフィック フローを制御し、ワークロード分離用のファイアウォール ルールをネットワーク レベルで構成します。
クラスタの IP アドレス指定モデルを選択する
GKE は、IPv4 専用、デュアル スタック（IPv4 と IPv6）、今後追加される IPv6 専用の各オプションなど、ネットワーキング要件を満たすために複数のネットワーク スタック構成をサポートしています。
IPv4 専用（シングル スタック）
これは、すべてのクラスタ コンポーネントが IPv4 アドレスを使用する標準的かつ最も一般的な構成です。IPv4 専用モデルでも、GKE は以下のように柔軟性を提供します。
- RFC 1918 プライベート IP アドレス: クラスタに RFC 1918 プライベート IP アドレス範囲（
10.0.0.0/8など）を使用します。 - プライベートで使用されるパブリック IP アドレス（PUPI）: 組織に十分なプライベート IP アドレス空間がない場合は、VPC ネットワーク内でパブリック IP アドレス範囲を内部使用できます。PUPI を使用する場合は、IP マスカレード エージェントを構成する必要があります。このエージェントは、Pod からのアウトバウンド トラフィックに対して送信元ネットワーク アドレス変換（SNAT）を実行します。SNAT を行わないと、PUPI を使用する Pod への戻りトラフィックは公共のインターネット経由でルーティングされ、失敗します。これを防ぐために、IP マスカレード エージェントは、アウトバウンド パケットの送信元 IP アドレスを Pod の PUPI からノードの内部 IP アドレスに変更します。これにより、戻りトラフィックはノードに正しくルーティングされ、元の Pod に転送されます。
デュアル スタック（IPv4 と IPv6）
デュアル スタック クラスタは、IPv4 と IPv6 の両方のプロトコルを使用します。GKE は、デュアル スタック クラスタのノード、Pod、Service に IPv4 アドレスと IPv6 アドレスの両方を割り当てます。このモデルは、次のような場合に最適です。
- IPv6 への段階的な移行を促進する。
- IPv6 対応のワークロードと、既存の IPv4 専用のクライアントとサービスの両方の互換性を確保する。
デュアル スタック ネットワーキングは、クラスタの作成時に有効にできるほか、既存のシングル スタック クラスタをデュアル スタックに更新できます。
次のステップ
- GKE のデフォルト ネットワーキング モードのメリットの詳細について、VPC ネイティブ クラスタについてを確認する。
- 利用を開始するために、VPC ネイティブ クラスタを作成する方法を確認する。
- クラスタの IP アドレス範囲のサイズ設定について、VPC ネイティブ クラスタの IP アドレス範囲の計画を確認する。
- 一般的な問題について、IP マスカレード エージェントのトラブルシューティングを確認する。