GKE でワークロードの分離を構成する

このページでは、Pod を一緒に、個別に、または特定のロケーションでスケジュールするように Google Kubernetes Engine（GKE）に指示する方法を説明します。

ワークロードの分離では、taint と toleration を使用して、Pod を別のノードに分離するよう GKE に指示し、特定の条件を満たすノードに Pod を配置することや、特定のワークロードをまとめてスケジュールすることができます。ワークロードの分離を構成するために必要なことは、GKE クラスタの構成によって異なります。この違いを次の表に示します。

ワークロードの分離の構成

特定の Key-Value ペアの toleration を Pod 仕様に追加し、nodeSelector を使用してその Key-Value ペアを選択します。GKE によってノードが作成され、対応するノード taint が適用されて、ノードで Pod がスケジュールされます。

手順については、このページの Autopilot クラスタの個々のワークロードをご覧ください。
標準（ノードの自動プロビジョニングなし）
  1. ノード taint とノードラベルを使用してノードプールを作成する
  2. その taint の toleration を Pod の仕様に追加する

手順については、ワークロードを専用ノードプールに分離するをご覧ください。

このガイドでは、2 つのワークロード（バッチジョブとウェブサーバー）があり、互いに分離する必要があるというサンプル シナリオを使用します。

GKE でワークロードの分離を使用するタイミング

ワークロードの分離は、異なるロールを実行するワークロードがあり、同じ基盤となるマシンで実行すべきではない場合に便利です。いくつかのサンプル事例としては、次のようなものがあります。

  • 分離したままにするジョブを作成するバッチ コーディネーター ワークロードがある。
  • セッション Pod から分離するマッチメイキング ワークロードでゲームサーバーを実行する。
  • データベースからサーバーを分離するなど、スタックの一部を分離する。
  • コンプライアンスやポリシー上の理由から一部のワークロードを分離する。

料金

Autopilot クラスタでは、実行中に Pod がリクエストしたリソースに対して課金されます。詳細については、Autopilot の料金をご覧ください。ワークロードの分離を使用する Pod では、通常の Pod よりも最小リソース リクエスト数が増加します。

Standard クラスタでは、Pod がノードで実行されているかどうかにかかわらず、各ノードのハードウェア構成とサイズに基づいて課金されます。詳しくは、標準料金をご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

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

Autopilot クラスタの個別のワークロード

ワークロードを互いに分離するには、ワークロードを実行するノードを定義する各ワークロード仕様に toleration とノードセレクタを追加します。この方法は、ノードの自動プロビジョニングが有効になっている Standard クラスタでも使用できます。

  1. 次のマニフェストを web-server.yaml として保存します。

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 6
  selector:
    matchLabels:
      pod: nginx-pod
  template:
    metadata:
      labels:
        pod: nginx-pod
    spec:
      tolerations:
      - key: group
        operator: Equal
        value: "servers"
        effect: NoSchedule
      nodeSelector:
        group: "servers"
      containers:
      - name: web-server
        image: nginx

    このマニフェストには次のフィールドがあります。

    • spec.tolerations: GKE は、group=servers:NoSchedule taint が設定されているノードに Pod を配置できます。GKE は、これらのノードでこの toleration のない Pod をスケジュールできません。
    • spec.nodeSelector: GKE は、group: servers ノードラベルを持つノードに Pod を配置する必要があります。

    GKE は、これらの Pod を実行するために GKE が自動的にプロビジョニングするノードに、対応するラベルと taint を追加します。

  2. 次のマニフェストを batch-job.yaml として保存します。

    apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5
  backoffLimit: 3
  ttlSecondsAfterFinished: 120
  template:
    metadata:
      labels:
        pod: pi-pod
    spec:
      restartPolicy: Never
      tolerations:
      - key: group
        operator: Equal
        value: "jobs"
        effect: NoSchedule
      nodeSelector:
        group: "jobs"
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]

    このマニフェストには次のフィールドがあります。

    • spec.tolerations: GKE は、group=jobs:NoSchedule taint が設定されているノードに Pod を配置できます。GKE は、これらのノードでこの toleration のない Pod をスケジュールできません。
    • spec.nodeSelector: GKE は、group: jobs ノードラベルを持つノードに Pod を配置する必要があります。

    GKE は、これらの Pod を実行するために GKE が自動的にプロビジョニングするノードに、対応するラベルと taint を追加します。

  3. ワークロードをデプロイします。

    kubectl apply -f batch-job.yaml web-server.yaml

ワークロードをデプロイすると、GKE はワークロードごとに次の処理を行います。

  1. GKE は、マニフェストで指定された対応するノード taint とノードラベルを持つ既存のノードを検索します。ノードが存在し、使用可能なリソースがある場合、GKE はノードにワークロードをスケジューリングします。
  2. ワークロードをスケジュールする有効なノードが見つからない場合、GKE は新しいノードを作成し、マニフェストに基づいて対応するノード taint とノードラベルを適用します。GKE は Pod を新しいノードに配置します。

ノード taint に NoSchedule 効果があると、toleration のないワークロードがノードに配置されません。

ワークロードの分離を確認する

Pod の一覧を表示してノードの名前を確認します。

kubectl get pods --output=wide

出力は次のようになります。

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

この出力は、batch-job Pod と web-server Pod が常に異なるノードで実行されることを示しています。

taint と toleration によるワークロードの分離の制限

ワークロードの分離に次のキー接頭辞は使用できません。

  • GKE と Kubernetes 固有のキー
  • *cloud.google.com/
  • *kubelet.kubernetes.io/
  • *node.kubernetes.io/

ワークロードの分離には、独自の一意のキーを使用する必要があります。

ノード自動プロビジョニングのない Standard クラスタでの個別のワークロード

ノードの自動プロビジョニングを行わずに Standard クラスタでワークロードを分離するには、ワークロードに対応する適切なノード taint とノードラベルを持つノードプールを手動で作成する必要があります。手順については、ワークロードを専用ノードプールに分離するをご覧ください。この方法は、ノードプールの手動管理が必要となる特定の要件がある場合にのみ使用してください。

次のステップ