ネットワーク サービス ティアを使用して外部トラフィックを構成する

このページでは、ネットワーク サービス ティアを使用して、Google Kubernetes Engine（GKE）クラスタの Service に外部トラフィックが到達する方法を制御する方法について説明します。Network Service Tiers を使用すると、ネットワーク トラフィックをパフォーマンス（プレミアム ティア）またはコスト削減（スタンダード ティア）のいずれかに最適化できます。

プレミアム ティアは、優れた速度と信頼性を実現するために、Google のプレミアム バックボーン ネットワークでトラフィックを配信します。一方、スタンダード ティアは、費用対効果の高いソリューションを提供する通常のインターネット サービス プロバイダ（ISP）ネットワークを使用します。

このページは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストの方々を対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

GKE でのネットワーク サービス ティアの仕組み

このセクションでは、GKE で Network Service Tiers を管理する方法について説明します。

  • プロジェクト レベルでネットワーク ティアを設定する: Google Cloud プロジェクトで使用するデフォルトのネットワーク ティアをスタンダード ティアまたはプレミアム ティアに設定できます。新しいクラスタはすべて network-default 設定で作成され、プロジェクト レベルの階層設定が継承されます。この設定は、クラスタのアップグレード後も保持されます。クラスタ内に作成されたノードプールは、プロジェクト レベルの構成からネットワーク ティアを継承します。

  • 新しいクラスタの作成時にネットワーク階層を設定する: Google Cloud プロジェクトの階層設定に関係なく、新しいクラスタの作成時にネットワーク階層を構成できます。新しいノードプールはクラスタレベルのネットワーク ティアを使用します。この構成は、ノードプールをアップグレードした後も保持されます。

  • クラスタの更新時にネットワーク階層を設定する: 既存のクラスタを更新するときに、ネットワーク階層を構成できます。新しいノードプールと新しい LoadBalancer Service は更新された階層構成を継承しますが、既存のノードプールと Service は引き続き元のネットワーク ティア構成を使用します。更新された階層構成は、クラスタをアップグレードした後も保持されます。

  • LoadBalancer Service の更新時にネットワーク ティアを設定する: LoadBalancer Service はクラスタのネットワーク ティアを継承します。ただし、この設定をオーバーライドして、Service マニフェストでネットワーク ティアを更新できます。

ネットワーク サービス ティアとロード バランシング

デフォルトでは、外部パススルー ネットワーク ロードバランサはプレミアム ティアを使用します。LoadBalancer Service が代わりにスタンダード ティアを使用するように、この構成を更新できます。

Gateway でアプリケーション ロードバランサを使用する場合、ネットワーク サービス ティアを構成することはできません。Gateway の Network Service Tiers は、GatewayClass リソースによって制御されます。詳細については、ゲートウェイの IP アドレスをご覧ください。

外部アプリケーション ロードバランサ用の GKE Ingress は、トラフィック ルーティングのスタンダード ティアをサポートしていません。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

制限事項

次の制限が適用されます。

  • ネットワーク ティアの設定は、プロジェクト レベルまたはクラスタレベルでのみ構成できます。ノードプールのネットワーク ティアを直接構成することはできません。
  • スタンダード ティアは、グローバル外部デュアルスタック IPv4 アドレスまたは IPv6 アドレスではサポートされていません。IP アドレスのタイプについて詳しくは、IP アドレスをご覧ください。

ネットワーク サービス ティアを使用してクラスタを作成する

クラスタを作成してネットワーク ティアを指定するには、次のコマンドを実行します。

 gcloud container clusters create CLUSTER_NAME \
     --network-tier=NETWORK_TIER \
     ...

次の値を置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • NETWORK_TIER: ネットワーク ティアの設定。 Google Cloud プロジェクトと同じティア設定の場合は network-default、スタンダード ティアの場合は Standard、プレミアム ティアの場合は Premium を使用します。

既存のクラスタを別の階層に移行する

クラスタのネットワーク階層を更新しても、既存のリソースのネットワーク階層には影響しません。既存のリソースは、引き続き古いネットワーク ティアに関連付けられた IP アドレスを使用します。サービスの中断を回避するには、クラスタを新しいネットワーク ティアに移行する際に、次の手順に沿って操作します。

  1. クラスタを更新する: ネットワーク ティアを使用して既存のクラスタを更新するには、次のコマンドを実行します。

    gcloud container clusters update CLUSTER_NAME \
    --network-tier=NETWORK_TIER \
    ...

    次の値を置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • NETWORK_TIER: ネットワーク ティアの設定。 Google Cloud プロジェクトと同じティア設定の場合は network-default、スタンダード ティアの場合は Standard、プレミアム ティアの場合は Premium を使用します。

  2. 新しいノードプールと Service を作成する: 外部クライアントが新しいネットワーク ティアに関連付けられた新しい IP アドレスを使用できるようにするには、新しいノードプールと新しい LoadBalancer Service を作成する必要があります。新しいノードプールと新しい LoadBalancer Service は、更新されたティア構成を継承しますが、既存のノードプールと Service は引き続き元のネットワーク ティア構成を使用します。

  3. DNS レコードを更新する: DNS レコードを変更して、新しい LoadBalancer Service の新しい IP アドレスを指すようにします。

  4. DNS の伝播を待つ: DNS の有効期間（TTL）が切れるまで待機し、クライアントが新しいサービスに転送されるようにして、古いレコードの提供を回避します。

Network Service Tiers を使用して外部ロードバランサを更新する

外部パススルー ネットワーク ロードバランサの場合、GKE はデフォルトで、外部転送ルールと IP アドレスに対してクラスタで構成されているネットワーク ティアを使用します。クラスタのネットワーク ティアが network-default に設定されている場合、ロードバランサはプレミアム ティアを使用します。この設定をオーバーライドするには、Service マニフェストで cloud.google.com/network-tier アノテーションを構成します。次に例を示します。

    ```yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: store-v1-lb-svc
      annotations:
        cloud.google.com/l4-rbs: "enabled"
        cloud.google.com/network-tier: Standard
    spec:
      type: LoadBalancer
      selector:
        app: store
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
        targetPort: 8080
    ```

LoadBalancer Service に使用されるパラメータの詳細については、Service パラメータをご覧ください。

静的 IP アドレス: 静的 IP アドレスを使用して Service を作成する場合、静的 IP アドレスのネットワーク ティアは LoadBalancer Service のネットワーク ティアと一致する必要があります。不一致がある場合は、kubectl describe service コマンドを実行すると次のエラー メッセージが表示されます。

Error syncing load balancer: failed to ensure load balancer: requested ip "standard-service" is neither static nor assigned to the LB

次のステップ