GKE クラスタの接続性を構成するための、柔軟かつシンプルでより安全な新しい手法
Ninad Desai
Sr Product Manager, Google
Dima Berkovich
Staff Software Engineer
※この投稿は米国時間 2025 年 1 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Kubernetes Engine（GKE）では、クラスタ ネットワークの構成に関して多数のオプションを利用することができます。ただ、昨今の環境はきわめて動的であり、構成の変更に関して、より柔軟な手法が必要であるという声を GKE プラットフォーム オペレーターからいただいています。そこで Google は、GKE クラスタとコントロール プレーン ネットワークをより柔軟で、構成しやすいものとすることを目的とした、一連の機能を発表いたします。
具体的には、GKE コントロール プレーンへのアクセスをノードプール IP 構成から分離して、それぞれの側面をきめ細かく制御できるようにしました。また、各サブコンポーネントに次のような機能強化を追加しました。
-
クラスタのコントロール プレーンへのアクセス
-
コントロール プレーンへのアクセスに DNS ベースの手法を追加しました。また、コントロール プレーン エンドポイントへの IP ベースまたは DNS ベースのアクセスをいつでも有効または無効にできるようになりました。
-
IP ベースのアクセス制御では、プライベート IP エンドポイントを選択済み RFC-1918 アドレスに、承認済みネットワーク経由でロックダウンできるようになりました。これは、VPC ピアリング ベースおよび Private Service Connect ベースのクラスタの両方を対象としています。
-
ノードプールと IP アドレスの柔軟性
-
それぞれのノードプールに独自の構成が適用されるようになり、また、各ノードプール用のパブリック IP の接続を実行または解除できるようになりました。なお、接続の実行および解除は独立した形で、ノードプールのライフサイクル中にいつでも行えます。
-
新しくプロビジョニングされたノードプールにおけるパブリック IP の接続に関して、クラスタのデフォルト構成をいつでも変更できるようになりました。この構成変更のために、クラスタを再作成する必要はありません。
クラスタのコントロール プレーンへのアクセスをどのように構成するかにかかわらず、また、ノードプールでパブリック IP への接続をどのように実行するのかや解除するのかにかかわらず、ノードとクラスタのコントロール プレーン間のトラフィックが、どのような状況においても常にプライベートになります。
このような変更が加えられることで、今後次のようになります。
-
GKE プラットフォームの管理者およびオペレーターは、制限がより緩いネットワーク構成（例: インターネットからコントロール プレーンやノードにアクセス可能）と、制限が最も厳しい構成（承認されたユーザーのみがコントロール プレーンにアクセスでき、ノードがインターネットに公開されていない）を簡単に切り替えられるようになります。クラスタをパブリックにするかプライベートにするかの設定を後から変更できるようになるため、柔軟性が高まり、前もって決定を確定する必要がなくなります。
-
GKE コントロール プレーンに接続する方法が増えます。IP ベースのアクセスに加え、コントロール プレーンへの DNS ベースのアクセスを導入しました。また、IAM ベースおよび認証ベースのポリシーを使用して、GKE コントロール プレーンにアクセスするためのポリシーベースの動的セキュリティを追加できます。
これまでの課題
お客様のワークロードやユースケースは複雑であり、多種多様です。そのため、GKE コントロール プレーンおよび GKE ノードへの接続性を構成および運用するための、シンプルで柔軟性がある手法をお客様に提供することが重要になります。
コントロール プレーンの接続性とノードプールの構成は、GKE の構成の主要な部分を担います。Google は、お客様の懸念事項に対応するために、安全で柔軟性がある接続性を実現する選択肢を増やす形で、GKE のネットワーク機能を継続的に強化してきました。これには、プライベート クラスタ、VPC ピアリング ベースの接続性、Private Service Connect ベースの接続性、プライベート / パブリック ノードプールなどがあります。
構成、ユーザビリティ、安全な接続に関して多くの改善がこれまでなされてきましたが、複雑性、ユーザビリティ、規模に関する以下のような構成の課題はいまだ存在します。
-
柔軟性が低い GKE コントロール プレーンとノードへのアクセスの構成: GKE のお客様は、クラスタを作成するプロセスの段階で、プライベート クラスタとパブリック クラスタのどちらを作成するかを先に自ら決定して確定させる必要があります。この構成は、クラスタを再作成する場合を除き、変更することができませんでした。
-
ノードプールのネットワーク IP と ネットワーク タイプの構成を、クラスタを作成した後に変更することができませんでした。
-
パブリック / プライベート クラスタなどの紛らわしい用語のために、構成がコントロール プレーン へのアクセスのためのものなのか、ノードプールの構成なのか、わかりにくくなっています。
新機能のメリット
GKE ネットワークにこのたびの変更が加えられることで、お客様が次のような領域でメリットを享受できるようになると Google は期待しています。
柔軟性:
-
クラスタが統合され、柔軟に構成できるようになります。外部エンドポイントの有無にかかわらず、クラスタはすべて同じアーキテクチャを共有し、同じ機能をサポートします。ニーズを満たす管理策とベスト プラクティスに基づいてクラスタへのアクセスを保護できます。クラスタ内のノードとコントロール プレーン間のすべての通信でプライベート内部 IP アドレスが使用されます。
-
コントロール プレーンへのアクセスとクラスタノードの構成の設定は、クラスタを再作成することなくいつでも変更できます。
セキュリティ:
-
VPC Service Controls を使用する DNS ベースのエンドポイントは、不正なネットワークや、コントロール プレーンにアクセスする不正な ID からクラスタを保護する多層セキュリティ モデルを実現します。VPC Service Controls は、Cloud Audit Logs とのインテグレーションにより、コントロール プレーンへのアクセスをモニタリングします。
-
プライベート ノード、およびその上で実行されているワークロードには、公共のインターネットから直接アクセスできません。そのため、お客様のワークロードを標的にする外部からの攻撃の可能性を大幅に削減できます。
-
Google Cloud の外部 IP アドレスまたは外部 IP アドレスからのコントロール プレーンへのアクセスをブロックして、クラスタ コントロール プレーンを完全に分離し、潜在的なセキュリティ脅威への露出を減らすことができます。
コンプライアンス: データアクセスとストレージに関する厳格な規制がある業界で働いている場合に、プライベート ノードを活用して、機密データをプライベート ネットワーク内に確実に保持することができます。
制御: プライベート ノードを使用すると、クラスタとの間で送受信されるトラフィックの流れをきめ細かく制御できます。承認された通信のみを許可するように、ファイアウォール ルールとネットワーク ポリシーを構成できます。マルチクラウド環境で運用している場合に、プライベート ノードを活用することで、異なる環境間に安全で制御された通信を確立できます。
使ってみる
クラスタ コントロール プレーンへのアクセス
クラスタのコントロール プレーンにアクセスするための手法が増え、従来のパブリック IP またはプライベート IP ベースのエンドポイントを介した手法に加え、新しい DNS ベースのエンドポイントを介した手法も使用できるようになりました。IP ベースのエンドポイントの場合、面倒な IP アドレスの構成（静的な承認済みネットワーク構成、さまざまな地域からのプライベート アクセスの許可など）が必要になります。DNS ベースのエンドポイントの場合はシンプルかつ柔軟であり、動的でもある、より安全な IAM ポリシーベースの手法を使ってクラスタのコントロール プレーンにアクセスできるようになります。
この変更のおかげで、クラスタのコントロール プレーンを 3 つのすべてのエンドポイント（DNS ベース、パブリック IP ベース、プライベート IP ベース）から同時にアクセスできるように構成することが可能になるため、クラスタを単一のエンドポイントの粒度に、任意の配列でロックダウンできます。望ましい構成をクラスタの作成時に適用することも、後から調整することもできます。
例:
DNS ベースのエンドポイントのみを有効にする（最適）:
3 つのエンドポイントすべてでアクセスを有効にする:
DNS ベースのエンドポイントとプライベート IP を介したアクセスを有効にして、RFC1918 アドレスの小規模な範囲からのアクセスを制限する:
ノードプール
GKE ノードプールのアクセスを構成する方法は以下のとおりです。
GKE Standard モード:GKE Standard 運用モードの場合、どのような状況においてもプライベート IP が常にすべてのノードに接続されます。このプライベート IP は、クラスタのコントロール プレーンへのプライベート接続で使用されます。
ノードプールの作成時、パブリック IP をノードプール内のすべてのノードに追加または削除できます。この構成は、各ノードプールで独立して実行できます。
また、ノードプールの作成後にパブリック IP を追加または削除できます。
各クラスタにはノードプールの作成時に使用されるデフォルトの動作フラグがあります。このフラグは、ノードプールの作成時にあらかじめ明示的に設定されていない場合に使用されます。
注: クラスタのデフォルトの状態を変更しても、既存のノードプールの動作は変更されません。新しい状態は、新しいノードプールが作成中のときにのみ使用されます。
GKE Autopilot 運用モード:パブリック IP の有無にかかわらず、ノードで実行されているすべてのワークロードがクラスタのデフォルトの動作に基づきます。以下の nodeSelector を Pod 仕様に追加することで、各ワークロードにおいて、クラスタのデフォルトの動作を独立した形でオーバーライドできます。
ただし、クラスタのデフォルトの動作をオーバーライドすると、再スケジュールするように動作が明示的に設定されていないすべてのワークロードが、クラスタのデフォルトの動作と一致するノードで実行されることになります。
まとめ
GKE 上で実行されるワークロードは複雑であり、多種多様です。そのため、GKE コントロール プレーンおよびノードへの接続性を構成して運用するための、シンプルで柔軟な手法を用意することが重要になります。今回紹介した GKE コントロール プレーンの接続性およびノードプール構成の強化のおかげで、GKE オペレーターが新しい水準の柔軟性とシンプルさを獲得できるようになると Google は期待しています。詳細およびドキュメントについては、以下をご覧ください:
