Private Service Connect について

Autopilot Standard

このドキュメントでは、Google Kubernetes Engine（GKE）クラスタでの Private Service Connect の概要を説明します。先に進む前に、VPC ネットワークとネットワーキングの基本（IP アドレスなど）を理解しておいてください。

概要

Private Service Connect（PSC）は Google Cloud のネットワーキングインフラストラクチャの一部であり、Google Cloud またはオンプレミス環境でホストされているサービスを、一般公開することなく、安全かつ非公開で GKE クラスタが利用できるようにします。PSC を使用すると、Google Cloud はコントロールプレーンに内部 IP アドレスを割り当て、GKE クラスタ管理 API にリクエストを転送します。これにより、トラフィックがパブリックインターネットを経由することなくクラスタを管理できます。PSC は、サービスネットワーキングアプローチによって異なるネットワークの接続を支援する一貫したフレームワークを提供し、サービスプロデューサーとコンシューマが VPC 内部の内部 IP アドレスを使って通信できるようにします。

PSC インフラストラクチャを使用する GKE クラスタでは、クラスタコントロールプレーンとノード間のすべての通信が非公開で行われます。また、複雑な VPC ピアリング構成を管理しなくても、コントロールプレーンレベルとノードプールレベルでクラスタを分離することもできます。

Private Service Connect で有効にしたクラスタのメリット

セキュリティ: PSC は、GKE クラスタコントロールプレーンとノードの間にプライベート接続を確立し、トラフィックを完全に Google のネットワーク内に保持して、公共のインターネットから隔離します。これにより、不正アクセスのリスクを最小限に抑えることができます。

接続の簡素化: PSC クラスタの場合、コントロールプレーンエンドポイントの特定のサブネットを管理する必要はありません。PSC エンドポイントはクラスタネットワーク内に完全に配置されるため、複雑なネットワーク構成は不要です。

スケーラビリティ: 最大 1,000 個のクラスタを作成して PSC で有効にし、難しいリソース要件を満たすことができます。一方、VPC ネットワークピアリングを使用するクラスタの場合は、ゾーンまたはリージョンあたり最大 75 個のクラスタしか作成できません。

カスタマイズ可能な構成: PSC を使用すると、クラスタのコントロールプレーン、ノードプール、ワークロードの分離を個別に制御できるため、クラスタのスケーラビリティとセキュリティが向上します。クラスタ内にプライベートとパブリックのノードプールが混在する構成も可能です。

柔軟性: クラスタの作成後、いつでも分離設定を変更できます。新しいクラスタを作成しなくても、コントロールプレーンへのパブリックアクセスとプライベートアクセスの切り替えや、ノードプールとワークロードへのインターネットからのアクセスの変更が可能です。

制限事項

コントロールプレーンには、内部エンドポイントと外部エンドポイントの両方があります。コントロールプレーンの内部エンドポイントは、構成した Webhook の URL の内部 IP アドレスをサポートしていません。URL に内部 IP アドレスを含む Webhook がある場合は、次の手順でこの非互換性を軽減できます。

セレクタなしでヘッドレスサービスを作成して、この Service がトラフィックを転送するエンドポイントを手動で管理します。次の例は、ポート 3000 でリッスンしている Webhook を含む Service を示しています。
```
apiVersion: v1
kind: Service
metadata:
  name: <service-name>
spec:
  clusterIP: None
  ports:
  - port: 3000
    targetPort: 3000
```
必要な宛先に対応するエンドポイントを作成します。たとえば、Webhook が URL で内部 IP アドレス 10.0.0.1 を使用する場合は、次のエンドポイントを作成できます。
```
apiVersion: v1
kind: Endpoints
metadata:
  name: <service-name>
subsets:
- addresses:
  - ip: 10.0.0.1
  ports:
  - port: 3000
```
Webhook 構成を更新する: Webhook 構成で、内部 IP アドレスを含む URL を削除し、最初の手順で作成した Service を追加します。例:
```
...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    service:
      name: <service-name>
      namespace: <namespace>
      path: "/validate"
      port: 3000
```
上の例では、Webhook のパスは /validate で、ポート 3000 でリッスンしています。
Webhook を確認する: Webhook が API サーバーリクエストを引き続き受信でき、カスタムロジックに基づいてリクエストを承認、拒否、または変更できることを確認します。Webhook の検証中にエラーが発生した場合は、新しい証明書を作成し、新しい証明書の詳細を使用して Webhook の構成を更新する必要があります。次に例を示します。
```
...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    ...
    caBundle: <new-certificate>
...
```

アーキテクチャ

次の図は、PSC を使用するクラスタのアーキテクチャの概要を示しています。

PSC で有効にされたクラスタのコアコンポーネントは次のとおりです。

コントロールプレーン: すべての GKE クラスタには、コントロールプレーンによって管理される Kubernetes API サーバーがあります。コントロールプレーンは、Google が管理するプロジェクトの VPC ネットワーク内の仮想マシン（VM）上で動作します。リージョンクラスタには、コントロールプレーンの複数のレプリカがあり、それぞれが独自の VM で実行されます。

コントロールプレーンには、内部クラスタ通信用の内部エンドポイント（Private Service Connect エンドポイント）と外部エンドポイントの両方があります。外部エンドポイントは無効にすることもできます。ノードとコントロールプレーンの間のトラフィックは、すべて内部 IP アドレスを使用してルーティングされます。クラスタ構成の詳細については、コントロールプレーンの構成を確認するをご覧ください。

VPC ネットワーク: クラスタのノードと Pod 専用の内部 IP アドレス範囲を持つサブネットを作成する仮想ネットワークです。

Private Service Connect エンドポイント: プロジェクトの VPC ネットワークにあるクラスタコントロールプレーンの内部エンドポイントです。PSC エンドポイントは、クラスタコントロールプレーンにアクセスするためのエントリポイントとして機能します。

サービスアタッチメント: VPC ネットワークとプロデューサー VPC ネットワークの間に安全なプライベート接続を確立するリソースです。上の図に示すように、PSC エンドポイントはプライベート接続を介してサービスアタッチメントにアクセスし、ノードとコントロールプレーン間でトラフィックが流れるようにします。

クラスタアクセスの構成

PSC 対応クラスタでコントロールプレーンアクセスとノードアクセスを構成するには、いくつか方法があります。これらの構成は、クラスタの作成後にいつでも変更できます。クラスタアクセスを構成するには、ネットワーク分離をカスタマイズするをご覧ください。

コントロールプレーンアクセス

DNS ベースのエンドポイントのみを使用してコントロールプレーンにアクセスします（推奨）。コントロールプレーンへのアクセスをリクエストするには、IAM 許可ポリシーを作成します。
IP ベースのエンドポイントのみを使用してコントロールプレーンにアクセスします。コントロールプレーンの外部エンドポイントと内部エンドポイントの両方を使用するか、外部エンドポイントを無効にして Google が予約した IP アドレス（クラスタ管理用）と GKE クラスタの内部 IP アドレスからのアクセスのみを許可するかを選択できます。

IP アドレスを使用している場合は、承認済みネットワークを使用して、クラスタのコントロールプレーンへのアクセスを制限することをおすすめします。承認済みネットワークを使用すると、Google Cloud 外部 IP をソースとする Google Cloud VM、Cloud Run、Cloud Run functions からのコントロールプレーンへのアクセスをブロックすることもできます。
DNS ベースのエンドポイントと IP ベースのエンドポイントを使用してコントロールプレーンにアクセスします。

クラスタノードへのアクセス

PSC 対応クラスタを使用すると、混在モードのクラスタを構成できます。内部または外部アクセスのあるノードを持つようにクラスタを構成できます。また、使用するクラスタのタイプに応じて、ノードネットワーク構成を変更することもできます。

Autopilot クラスタでは、一部のワークロードをプライベートノードで実行し、他のワークロードをパブリックノードで実行するように構成できます。たとえば、クラスタ内でインターネットアクセスを必要とするワークロードとそうでないワークロードが混在しているような場合です。外部 IP アドレスを持つノードにワークロードをデプロイし、そのようなワークロードのみにパブリックへのアクセスを許可できます。
Standard クラスタでは、一部のノードに内部 IP アドレスをプロビジョニングしつつ、他のノードで外部 IP アドレスを使用できます。

Private Service Connect を使用したクラスタ

クラスタが Private Service Connect を使用しているかどうかを確認するには、gcloud container clusters describe コマンドを実行します。クラスタで Private Service Connect を使用している場合、privateClusterConfig リソースには次の値が設定されています。

peeringName フィールド: 空、または存在しません。
privateEndpoint フィールド: 値が割り当てられています。

PSC でクラスタを有効にするには、バージョン 1.29 以降でクラスタを作成します。それ以外の場合は、バージョン 1.28 以前で、プライベートノードを有効化せずにクラスタを作成します。この設定は、クラスタの作成後にいつでも更新してプライベートノードを有効にできます。

次のステップ

GKE でネットワーク分離をカスタマイズする方法を確認する。