GKE ネットワーキングの基本を理解する - ネットワーキングの基本
Google Cloud Japan Team
※この投稿は米国時間 2022 年 8 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。
この記事では、Google Kubernetes Engine（GKE）のネットワーキング コンポーネントと、さまざまなオプションについて説明します。Kubernetes はコンテナ化されたワークロードとサービスを管理するのに適したオープンソース プラットフォームで、GKE は Google Cloud インフラストラクチャで Kubernetes を実行するためのフルマネージド環境です。
IP アドレス指定
Kubernetes のさまざまなネットワーク コンポーネントは、通信を行うために IP アドレスとポートを利用します。IP アドレスは、ネットワーク上のさまざまなコンポーネントを識別する一意のアドレスです。
コンポーネント
コンテナ - アプリケーション プロセスを実行するための最小のコンポーネント。1 個以上のコンテナが 1 つの Pod で実行されます。
Pod - 物理的にグループ化されたコンテナのコレクション。Pod はノードに割り当てられます。
ノード - クラスタ（ノードのコレクション）内のワーカーマシン。ノードは 0 個以上の Pod を実行します。
Service
ClusterIP - これらのアドレスは、Service に割り当てられます。
ロードバランサ - クラスタ内のノードに対して内部トラフィックまたは外部トラフィックのロード バランシングを行います。
Ingress - HTTP(S) トラフィックを処理する特別なタイプのロードバランサです。
IP アドレスは、さまざまなサブネットからコンポーネントと Service に割り当てられます。可変長サブネット マスク（VLSM）は、CIDR ブロックの作成に使用されます。サブネットで利用可能なホストの数は、使用するサブネット マスクに応じて変わります。
Google Cloud で利用可能なホストの計算式は 2n- 4 であり、通常オンプレミス ネットワークで使用される 2n- 2 ではありません。
IP アドレスを割り当てる流れは次のようになります。
ノードに、クラスタの VPC ネットワークから IP アドレスが割り当てられます。
内部ロードバランサの IP アドレスは、ノードの IPv4 ブロックからデフォルトで自動的に割り当てられます。必要に応じて、ロードバランサの指定範囲を作成し、loadBalancerIP オプションを使用してその範囲からアドレスを指定できます。
Pod には、そのノードで実行中の Pod に対して発行されるアドレスの範囲から、アドレスが割り当てられます。ノードあたりの最大 Pod 数は、デフォルトで 110 です。この Pod 数にアドレスを割り振るには、総数に 2 を掛け（110 × 2 = 220）、最も近いサブネットである /24 を使用します。これにより、Pod のスケジューリングのためのバッファリングが可能になります。この上限は作成時にカスタマイズ可能です。
コンテナは、実行する Pod の IP アドレスを共有します。
Service（クラスタ IP）アドレスは Service 用に予約されたアドレスプールから割り当てられます。
VPC ネイティブ クラスタに関するドキュメントの VPC ネイティブ クラスタの IP アドレス範囲を扱うセクションでは、アドレス範囲の計画およびスコープ設定の例を示しています。
ドメイン ネーム システム（DNS）
DNS を使用することで、名前から IP アドレスの解決を可能にします。これにより、Service に対して自動的に名前エントリを作成できます。GKE ではいくつかのオプションを提供しています。
kube-dns - Kubernetes ネイティブのアドオン サービス。Kube-dns はクラスタ IP を介して公開されるデプロイで実行されます。デフォルトでは、クラスタ内のポッドは DNS クエリにこのサービスを使用します。「kube-dns の使用」に関するドキュメントで、その仕組みについて説明しています。
Cloud DNS - Google Cloud DNS のマネージド サービス。クラスタ DNS の管理に活用できます。kube-dns と比較した Cloud DNS の利点として次のものが挙げられます。
クラスタでホストされる DNS サーバーの管理を軽減。
GKE ノードでの DNS ローカル解決をサポート。これはレスポンスをローカルにキャッシュ保存することで行われ、これによりスピードとスケーラビリティの両方を実現します。
Google Cloud Operations モニタリング スイートとのインテグレーション。
Service Directory は Google Cloud が提供する別のサービスで、GKE と Cloud DNS を統合し、Namespace を介して Service を管理します。
gke-networking-recipes GitHub リポジトリでは、内部ロードバランサ、ClusterIP、Headless および NodePort で試すことができるいくつかの Service Directory の例が提供されています。
GKE の DNS オプションに関する詳細は、次の記事を参照してください。DNS on GKE: Everything you need to know（GKE における DNS: 知っておくべきすべてのこと）
ロードバランサ
ロードバランサは、アクセスを制御し、さまざまなリソースにトラフィックを分散します。GKE では次のようないくつかのオプションを提供しています。
Ingress
これらは、クラスタ内の Service 宛の HTTP(S) トラフィックを処理します。Ingress リソースタイプを使用します。このタイプを使用すると、GKE 用の HTTP(S) ロードバランサが作成されます。構成時に、ロードバランサに静的 IP アドレスを割り当てることで、アドレスは変更されることはありません。
GKE では、外部 Ingress と内部 Ingress の両方をプロビジョニングできます。以下のガイドへのリンクでは、構成方法について説明しています。
GKE では、ネットワーク エンドポイント グループ（NEG）を使用してトラフィックを直接 Pod IP に転送するコンテナ ネイティブなロード バランシングを活用できます。
サービス ルーティング
このトピックを理解するための主なポイントは 3 つあります。
フロントエンド - さまざまなルールに基づいてトラフィックを受け入れるフロントエンドを通じて、クライアントに Service を公開します。これは、DNS 名または静的 IP アドレスになります。
ロード バランシング - トラフィックが許可されると、ロードバランサは利用可能なリソースに分散し、ルールに基づいてリクエストを処理します。
バックエンド - GKE で使用できるさまざまなエンドポイントです。
運用
GKE では、次のようなクラスタ ネットワークを設計する方法がいくつか提供されています。
Standard - このモードを使用すると、管理者はクラスタの基盤となるインフラストラクチャを構成できます。このモードは、より深いレベルの制御と責任が必要な場合に役立ちます。
Autopilot - GKE では、クラスタの基盤となるインフラストラクチャのプロビジョニングと管理を行います。Autopilot は、使用に際して事前構成されていて、これにより引き継ぎ管理の自由度が少し高くなります。
限定公開クラスタ（内部 IP 接続のみを許可）。クライアントがインターネットにアクセスする必要がある場合（例: アップデートのため）、Cloud NAT を使用できます。
プライベート サービス アクセス（VPC がプライベート IP アドレスを介してサービス プロデューサー サービスと通信できるようにします）Private Service Connect（VPC ネットワーク全体で Service をプライベートに利用できます）
まとめ
以下は、全体を簡潔に要約したものです。
IP アドレスは、クラスタ内のさまざまなリソースに割り当てられます。
ノード
Pod
コンテナ
Service
これらの IP アドレス範囲は、さまざまなリソースタイプ用に予約されています。サブネット化することで、必要な範囲サイズを調整できます。クラスタへの不要な外部アクセスを制限することが推奨されています。
デフォルトでは、Pod はクラスタ全体で通信できます。
Pod で実行中のアプリケーションを公開するには、Service が必要です。
クラスタ IP は Service に割り当てられます。
DNS の解決には、kube-dns のようなネイティブ オプションを使用することも、GKE クラスタ内で Google Cloud DNS を活用することもできます。
ロードバランサは、クラスタの内部および外部で使用可能で、アプリケーションを公開しトラフィックを分散します。
Ingress は HTTP(S) トラフィックを処理します。処理には Google Cloud が提供する HTTP(S) ロードバランサ サービスを活用します。Ingress は、内部構成と外部構成に使用できます。
GKE ネットワーキングに関する詳細は、以下をご覧ください。
ご質問やご不明な点、ご意見は、私の Linkedin または Twitter（@ammettw）にご連絡ください。
- デベロッパー リレーションズ エンジニア Ammett Williams
- Cloud デベロッパー アドボケイト Abdelfettah Sghiouar
