Google Kubernetes Engine（GKE）ネットワーキングは、Google のグローバル VPC 上に構築され、コンテナ化されたアプリケーションのための強力かつスケーラブルで安全な基盤を提供します。抽象的な Kubernetes ネットワーキング モデルを、グローバル ロードバランサや高スループット VM ネットワーキングなどの具体的な高性能リソースに変換します。
このドキュメントとこのドキュメント セットの残りの部分は、組織のネットワーク アーキテクチャを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。
Kubernetes ネットワーキングが異なる理由
Kubernetes を使用してアプリケーションをオーケストレートする際は、ネットワーク設計について異なる考え方をします。Kubernetes では、個々のホストや仮想マシン（VM）のネットワークを管理するのではなく、Pod、Service、外部クライアントがどのように通信するかを重視します。この抽象化により、手動ポート マッピングなどの複雑さが解消され、アプリケーションのデプロイとスケーリングが簡素化されます。
前提条件
GKE でのネットワーキングについて学習する前に、次のことを理解しておく必要があります。
- 一般的なネットワーキング、 Google Cloud、Kubernetes の主なコンセプト。
- GKE の学習を開始するをご覧ください。
コア ネットワーキングと Google Cloud の基礎
GKE は標準のネットワーキング原則に基づいて構築されています。GKE がクラスタ内およびクラスタ間でトラフィックを管理およびルーティングする方法を理解するには、次のコア ネットワーキングのコンセプトを理解しておく必要があります。
ネットワーキング レイヤとプロトコル
ネットワークを介してデータがどのように移動するかを理解するには、まずネットワーキング レイヤから始めます。GKE は、ネットワーク スタックのトランスポート レイヤ、インターネット レイヤ、アプリケーション レイヤのコンセプトを広範に使用します。基本的な機能と、HTTP、DNS、TCP/IP スイートなどの一般的なプロトコルに精通している必要があります。詳細については、OSI モデルをご覧ください。
トランスポート層 - 伝送制御プロトコル（TCP）または User Datagram Protocol（UDP）: アプリケーション間のエンドツーエンド通信を処理します。伝送制御プロトコル（TCP）は、信頼性の高い順序付けされたエラーチェック済みの配信を提供します。これは、ほとんどのアプリケーション トラフィックに不可欠です。User Datagram Protocol（UDP）は、高速なコネクションレス型の通信を提供し、ストリーミングやゲームでよく使用されます。GKE は、Pod と Service の通信に両方のプロトコルを使用します。
インターネット レイヤ - インターネット プロトコル（IP）: 異なるネットワーク間でパケットのアドレス指定とルーティングを行います。GKE のすべての Pod とノードには IP アドレスが割り振られます。IP アドレス ルーティングは、トラフィックがクラスタと VPC ネットワークを通過する方法を決定します。
アプリケーション レイヤ - ハイパーテキスト転送プロトコル（HTTP）とドメイン ネーム システム（DNS）: このレイヤは、アプリケーションがネットワークとやり取りする場所です。HTTP と HTTPS はウェブ通信の基礎であり、Ingress コントローラとロードバランサでアプリケーションの公開によく使用されます。DNS は、Kubernetes でのサービス ディスカバリに不可欠であり、人間が読めるサービス名を IP アドレスに変換します。
IP アドレス指定と CIDR 表記
Kubernetes ネットワーキング モデルは、すべてのコンポーネント間の通信に IP アドレスを広範囲に使用するため、IP アドレス指定と CIDR（クラスレス ドメイン間ルーティング）表記を理解する必要があります。CIDR は、 Google CloudVPC ネットワーク内のクラスタの IP アドレスの割り振りを計画するうえで重要です。これにより、Pod、Service、ノードの IP アドレスのブロックを定義できます。たとえば、Pod に 10.10.0.0/16 を割り振ると、65,536 個の IP アドレスが予約されます。適切な CIDR 計画を立てることで、クラスタのスケーリング時に IP アドレスが不足する状況を防ぐことが可能です。
Linux ネットワーク ユーティリティ
GKE は、基盤となる Linux カーネル機能を使用して、クラスタ内のトラフィック ルーティングとロード バランシングを実装します。ルーティング テーブルや iptables などの Linux ネットワーク管理の基本的なコンセプトとユーティリティを理解している必要があります。従来、各ノードの主要な Kubernetes コンポーネントである kube-proxy は、これらのユーティリティをプログラミングして、Service 宛てのトラフィックをインターセプトし、バックエンド Pod のいずれかにリダイレクトします。GKE Dataplane V2 を使用する最新の GKE クラスタでは、パフォーマンスとオブザーバビリティを向上させるために iptables が eBPF に置き換えられます。
Kubernetes ネットワーキング モデルについて理解する
Kubernetes ネットワーキング モデルは、コンテナ化されたアプリケーションがクラスタ内で通信する方法を定義します。仮想マシンに重点を置く従来のモデルとは異なり、Kubernetes は Pod 間通信と Service ベースの通信を重視しています。このモデルでは、動的 Pod IP アドレスの信頼性の低さを抽象化することで、アプリケーション ネットワーキングの予測可能性を高めます。Pod は一時的なものであり、新しい IP アドレスでいつでも再作成できるため、Pod IP アドレスとの直接通信は本質的に不安定です。Kubernetes は、Pod を Service にグループ化することで、この問題を解決します。Service は、安定した仮想 IP アドレス（ClusterIP）と一貫性のある DNS 名を提供します。アプリケーションはこれらに確実に接続できます。この安定したエンドポイントと、NAT を必要とせずにすべての Pod が直接通信できるフラットなネットワークを組み合わせることで、コンテナ化された最新のアプリケーションの堅牢な基盤が構築されます。
Kubernetes ネットワーク モデルの主な原則
各 Pod に一意の IP アドレスがある: Kubernetes クラスタ内のすべての Pod に独自の IP アドレスが割り振られます。この IP アドレスは、その Pod 内のすべてのコンテナで共有されます。この一意の IP アドレスにより、Pod は仮想マシンと同様に、ネットワーク上の個々のホストとして機能します。
NAT なしのフラットな Pod 間通信: すべての Pod は、実行されているノードに関係なく、IP アドレスを使用して互いに直接通信できます。GKE では、この直接通信は VPC ネイティブ クラスタを使用して実現されます。このクラスタでは、Pod の IP アドレスは VPC ネットワーク内のエイリアス IP アドレスです。これらのエイリアス IP アドレスにより、Pod は VPC 内で直接ルーティング可能になり、ネットワーク アドレス変換（NAT）が不要になり、ノード間の通信が簡素化されます。
Service が安定したエンドポイントを提供する: Pod は一時的なものであり、新しい IP アドレスでいつでも再作成できるため、Pod IP アドレスとの直接通信は信頼性が低くなります。Kubernetes Service は、一連の Pod をグループ化し、安定した IP アドレス（
ClusterIP）と DNS 名を公開することで、この問題を解決します。この問題の抽象化により、動的な Pod のセットへの一貫したアクセスが実現します。DNS による組み込みのサービス ディスカバリ: Kubernetes には、Service に DNS 名を自動的に割り当てる組み込みの DNS サービスが含まれています。アプリケーションは、これらの名前（
my-service.my-namespace.svc.cluster.localなど）を使用して、他の Service を確実に特定し、通信できます。統合ロード バランシング。クライアントが Service の
ClusterIPアドレスにトラフィックを送信すると、ノードのネットワーキング ルール（kube-proxyまたは GKE Dataplane V2 によってプログラム済み）がトラフィックをインターセプトし、その Service 内のすべての正常な Pod に対してロード バランシングを行います。この分散はソースで行われるため、非常に効率的で、高可用性を確保できます。
要するに、Kubernetes ネットワーク モデルは、従来のネットワークの複雑さの多くを、コンテナ化されたアプリケーション用のよりシンプルで強力なプリミティブ セットに抽象化します。Pod 間の直接通信、安定した Service エンドポイント、統合された DNS とロード バランシングを有効にすることで、コンテナ化された最新のアプリケーションに堅牢でスケーラブルな基盤を提供します。
GKE と Google Cloud の関係
GKE ネットワーキングは、Kubernetes ネットワーキングの概念モデルと Google Cloudの物理インフラストラクチャの間の橋渡し役を果たします。
Kubernetes ネットワーキング モデル: Kubernetes は、すべての Pod が独自の IP アドレスを取得するルールを定義し、NAT を必要とせずに Pod 間の直接通信を可能にします。
Google Cloud ネットワーキング: VPC、サブネット、ファイアウォール、ロードバランサなどの基盤となるインフラストラクチャです。
GKE ネットワーキング: この接続レイヤは、 Google Cloudのインフラストラクチャを使用して Kubernetes モデルを実装します。
Container Network Interface（CNI）: GKE は、各ノードで CNI プラグインを使用して Pod の IP アドレスの割り振りを処理し、Pod をノードのネットワークに接続します。
GKE コントロール プレーン: こうしたコンポーネントはGoogle Cloud と連携して、Pod IP 範囲の VPC ルートを自動的に構成し、ファイアウォール ルールを管理して、Kubernetes デプロイに基づいてロードバランサをプロビジョニングします。
GKE で Google Cloud ネットワーキングの知識が不可欠な理由
GKE は Google Cloudネットワーキング インフラストラクチャ上に構築されます。GKE は別のネットワーク レイヤを作成しません。代わりに、既存の Google Cloud ネットワーキング コンポーネントを使用します。そのため、GKE クラスタの設計と保護には、 Google Cloud ネットワーキングの理解が不可欠です。
Google Cloud ネットワーキングの基礎が重要な理由は次のとおりです。
クラスタが VPC 内で実行される: すべての GKE クラスタは VPC 内で動作します。ノード、Pod、Service のすべての IP アドレスは、VPC サブネットで定義された IP アドレス範囲から取得されます。IP アドレスを適切に割り振って不足を回避するには、VPC とサブネットの設計に関する実用的な知識が必要です。詳細については、VPC ドキュメントをご覧ください。
アプリケーションの公開で Google Cloud ロードバランサを使用する: LoadBalancer Service または Ingress を使用してクラスタの外部でアプリケーションを公開すると、GKE は組み込みの Google Cloud ロードバランサをプロビジョニングします。通常、LoadBalancer Service はレイヤ 4 トラフィックに使用され、Ingress はレイヤ 7 HTTP(S) トラフィックに使用されます。これらのロードバランサの動作を理解すると、外部トラフィックの管理、ヘルスチェックの設定、接続の問題のトラブルシューティングを効果的に行えます。詳細については、Cloud Load Balancing のドキュメントをご覧ください。
Google Cloud ファイアウォール ルールを介してセキュリティが適用される: GKE は、クラスタの重要なトラフィックを許可するファイアウォール ルールを自動的に作成します。ただし、ワークロードを保護するには、カスタム VPC ファイアウォール ルールを定義する必要があります。構成が誤っていると、重要なトラフィックがブロックされる可能性があるため、これらのルールの仕組みを理解することが重要です。詳細については、Cloud Next Generation Firewall のドキュメントをご覧ください。
次のステップ
- アーキテクチャの詳細解説について、GKE ネットワーキングの 3 つの柱を確認する。
- GKE ネットワーク ポリシーと Kubernetes ネットワーク ポリシーについて学習する。
- Service を使用したアプリケーションの公開と、Kubernetes Service のコンセプトについて学習する。
- GKE 用 Ingress と Kubernetes Ingress について理解する。
- VPC ネイティブ クラスタの詳細を確認する。
- GKE Dataplane V2 のメリットについて学習する。
- GKE ネットワーキングのトラブルシューティング。