コンテンツに移動
Containers & Kubernetes

GKE クラスタのための新しいコントロール プレーンへの接続と分離のオプション

2023年1月6日
https://storage.googleapis.com/gweb-cloudblog-publish/images/containers_2022.max-2500x2500.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 12 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

以前は、すべての Google Kubernetes Engine(GKE)クラスタは、ノードとコントロール プレーン間の通信にパブリック IP アドレス指定を使用していました。その後、セキュリティに関するお客様の声を聞き、VPC ピアリングで実現する限定公開クラスタを導入しました。

2022 年 3 月より、接続の種類を集約するため、新しい一般公開クラスタの GKE クラスタ コントロール プレーンとノード間の通信に Private Service Connect(PSC)を使用するようになり、GKE 環境の構成に大きな影響を与えることになりました。今回は、クラスタのノードから GKE コントロール プレーンへの接続を行うための、一貫性のある PSC ベースの新しいフレームワークを紹介します。さらに、新しい機能セットを発表いたします。コントロール プレーンとノードプール レベルでクラスタを分離することにより、GKE クラスタをよりスケーラブルで安全、かつ安価に利用できるようになります。

新しいアーキテクチャ

GKE バージョン 1.23 以降から、2022 年 3 月 15 日以降に作成されたすべての新しい一般公開クラスタにおいては、GKE クラスタ コントロール プレーンとノード間の通信に Google Cloud の PSC インフラストラクチャを使用するようになりました。PSC は、サービス ネットワーキング アプローチによって異なるネットワークの接続を支援する一貫したフレームワークを提供し、サービス プロデューサーとコンシューマが VPC 内部のプライベート IP アドレスを使って通信することを可能にします。

この変更の最大のメリットは、GKE クラスタに PSC 対応機能を使用するための土台を用意できることです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_control_plane_connectivity_122122.max-2000x2000.jpg
図 1: PSC を用いた GKE クラスタ用アーキテクチャの簡略図

よりスケーラブルで安全な GKE クラスタ体制に向けた進化の一環として、今回の新しいクラスタ分離機能セットを発表します。以前は、プライベート GKE クラスタは VPC ピアリングで実現されており、特定のネットワーク アーキテクチャを導入していました。この機能セットで、以下のことが可能になりました。

  • プライベート エンドポイントへのアクセスのみを許可するように GKE クラスタのコントロール プレーンを更新する

  • パブリック ノードまたはプライベート ノードによる GKE クラスタ ノードプールを作成または更新する

  • Google が所有する IP からの GKE クラスタ コントロール プレーンへのアクセスを有効または無効にする。

さらに、新しい PSC のインフラストラクチャを利用することで、費用削減を実現できます。従来、コントロール プレーンの通信は通常の下り(外向き)として処理され、一般公開クラスタでは通常のパブリック IP 料金が請求されていました。これは、プロビジョニングやその他の運用上の理由で kubectl を実行している場合も同様です。PSC インフラストラクチャでは、コントロール プレーンとお客様のクラスタノード間の通信費用が不要になり、その結果、ネットワークの下り(外向き)の請求の心配が一つ減りました。

では、この機能セットによって、どのような新しい機能が実現されているのかを見ていきましょう。

プライベート エンドポイント経由でのみコントロール プレーンへのアクセスを許可する

限定公開クラスタのユーザーは、以前からパブリック エンドポイントとプライベート エンドポイントの両方でコントロール プレーンを作成することが可能でした。今回、PSC をベースにした一般公開 GKE クラスタにも同じ柔軟性を拡張しました。これにより、GKE コントロール プレーンへのアクセスは限定公開にし、ノードプールをすべて一般公開にしたい場合は、そうすることができます。

このモデルでは、コントロール プレーンに対してより厳重なセキュリティ対策を提供する一方で、デプロイに応じて必要なクラスタノードの種類を選択できます。

コントロール プレーン上のプライベート エンドポイントのみへのアクセスを有効にするには、次の gcloud コマンドを使用します。

読み込んでいます...

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_control_plane_connectivity_122122.max-2000x2000.jpg

パブリック ノードプールとプライベート ノードプールの切り替えとミックスモード クラスタの許可

マネージド Kubernetes を提供するすべてのクラウド プロバイダは、一般公開クラスタと限定公開クラスタの両方を提供します。クラスタが一般公開であるか限定公開であるかは、クラスタレベルで強制され、一度作成すると変更できません。今回、ノードプールの IP アドレスをプライベートとパブリックの間で切り替えられるようになりました。

また、プライベートとパブリックのノードプールを混在させることも可能です。たとえば、クラスタ内でインターネット接続を必要とするワークロードとそうでないワークロードが混在しているような場合です。NAT ルールを設定する代わりに、パブリック IP アドレスを持つノードプールにワークロードをデプロイし、そのようなノードプールのデプロイのみにパブリックへのアクセスを許可できます。

既存のノードプールでプライベート専用の IP アドレスを有効にするには、次の gcloud コマンドを使用します。

読み込んでいます...

ノードプール作成時にプライベート専用 IP アドレスを有効にする場合は、以下の gcloud コマンドを使用します。

読み込んでいます...

Google Cloud からのアクセスを構成する 

たとえば、Cloud Run で実行されているアプリケーションや、Google Cloud のパブリック IP を発信元とする GCP VM がクラスタ コントロール プレーンに到達することが許可されるなど、ユーザーが GKE クラスタ外のワークロードを特定したシナリオもあります。潜在的なセキュリティ上の懸念を軽減するために、そのような発信元からのクラスタ コントロール プレーンへのアクセス許可を切り替えることができる機能も導入しました。

Google Cloud のパブリック IP からコントロール プレーンへのアクセスを削除するには、次の gcloud コマンドを使用します。

読み込んでいます...

同様に、このフラグはクラスタ作成時に使用できます。

プライベート エンドポイント アドレスを選択する

多くのお客様は、トラブルシューティングを容易にし、使用状況を追跡するために、IP をスタックにマッピングしています。たとえば、インフラストラクチャ用の IP ブロック x、サービス用の IP ブロック y、GKE コントロール プレーン用の IP ブロック z などです。デフォルトでは、PSC ベースの GKE クラスタのコントロール プレーン用のプライベート IP アドレスは、ノードのサブネットから取得されます。しかし、お客様によっては、ノード サブネットをインフラストラクチャとして扱い、それに対してセキュリティ ポリシーを適用している場合もあります。インフラストラクチャと GKE コントロール プレーンを区別するために、新しいカスタム サブネットを作成し、それをクラスタ コントロール プレーンに割り当てることができるようになりました。

読み込んでいます...

この新しい GKE アーキテクチャでできること

この新機能セットにより、基本的に GKE クラスタのパブリック IP 通信をすべて削除できます。つまり、GKE クラスタを完全に限定公開にできます。

現在、PSC を使用するためには一般公開としてクラスタを作成する必要がありますが、その後 gcloud を使用して --enable-private-endpoint フラグ、または UI を使用して、コントロール プレーンのプライベート エンドポイントのみによるアクセスや新しいプライベート ノードプールを作成するようにクラスタを更新することが可能です。

また、クラスタ作成時に --master-authorized-networks と --no-enable-google-cloud-access フラグでアクセスを制御し、パブリック アドレスからコントロール プレーンにアクセスできないようにすることもできます。

さらに、REST API や Terraform Providers を使って、実際に PSC ベースの GKE クラスタを新規に構築し、デフォルト(つまり最初の)のノードプールを使ってプライベート ノードを持つこともできます。これは、enablePrivateNodes フィールドを true に設定することで実現できます(現在 gcloud と UI 操作で必要なように、一般公開 GKE クラスタのデフォルトを活用して、その後更新する必要がありません)。

最後に、前述の特長は、Standard GKE クラスタだけでなく、GKE Autopilot クラスタにも拡張されています。.

これらの PSC ベースの GKE クラスタのタイプを移動して限定公開クラスタの分離を利用する準備ができたかどうかを評価する場合、コントロール プレーンのプライベート エンドポイントには次のような制限があることに留意してください。

  • 新規または既存の Webhook を構成する際、URL のプライベート アドレスを使用することはサポートされていません。この非互換性を緩和し、ウェブフック用の URL に内部 IP アドレスを割り当てる場合は、URL によるプライベート アドレスへの Webhook を設定し、セレクタなしのヘッドレス サービスと、必要な宛先に対応するエンドポイントを作成する必要があります。

  • コントロール プレーンのプライベート エンドポイントは、現在、オンプレミス システムからアクセスできません。

  • コントロール プレーンのプライベート エンドポイントは、現在グローバルにアクセス可能ではありません。クラスタ リージョンと異なるリージョンからのクライアント VM は、コントロール プレーンのプライベート エンドポイントに接続できません。

バージョン 1.25 以降の一般公開クラスタで、まだ PSC を使用していないクラスタは、現在新しい PSC インフラストラクチャに移行中です。したがって、お客様のクラスタはすでに PSC を使用してコントロール プレーンと通信している可能性があります。

PSC ベースのコントロール プレーン通信を行う GKE クラスタの詳細については、以下の参考資料をご覧ください。

ここでは、最新の Terraform Provider のより具体的な機能を紹介します。自動化パイプラインに統合するのに便利です。

Terraform Providers Google: リリース v4.45.0


- GKE、プロダクト マネージャー Cynthia Thomas
- GKE、スタッフ ソフトウェア エンジニア Dmitry Berkovich
投稿先