ステートフル ワークロードを作成する

共有 標準

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ Kubernetes クラスタ内でステートフル ワークロードを作成して管理する方法について説明します。ステートフル ワークロードを使用すると、永続ストレージを使用してアプリケーションのデプロイをスケーリングできます。永続ストレージは、ワークロードがスケジュールされている場所に関係なく、一貫した ID と安定したホスト名をアプリケーションに提供します。

このドキュメントは、組織のアプリケーション ワークロードの作成を担当するアプリケーション オペレーター グループのデベロッパーを対象としています。詳細については、GDC エアギャップ ドキュメントの対象読者をご覧ください。

始める前に

このドキュメントのタスクを完了するには、必要な権限をリクエストして環境を準備する必要があります。

IAM ロールをリクエストする

ステートフル ワークロードの作成に必要な権限を取得するには、特定のロールが必要です。必要なロールは、組織スコープの共有クラスタとプロジェクト スコープの標準クラスタのどちらで作業しているかによって異なります。詳細については、Kubernetes クラスタの構成をご覧ください。

共有クラスタロール

共有クラスタでステートフル ワークロードを作成、削除、編集、表示するには、IAM プロジェクト管理者にNamespace 管理者（namespace-admin）ロールを付与するよう依頼します。このロールはプロジェクトの名前空間にバインドされます。

標準クラスタロール

標準クラスタでステートフル ワークロードを作成、削除、編集、表示するには、IAM プロジェクト管理者にクラスタ デベロッパー（cluster-developer）ロールを付与するよう依頼します。このロールはプロジェクトの名前空間にバインドされます。

環境を準備する

API を使用して Kubernetes クラスタに対してコマンドを実行するには、次のリソースがあることを確認してください。

• Kubernetes クラスタ名を確認するか、プラットフォーム管理者グループのメンバーにクラスタ名を確認します。

• ログインして、Kubernetes クラスタの kubeconfig ファイルを生成します。

• これらの手順では、Kubernetes クラスタの kubeconfig パスを使用して KUBERNETES_CLUSTER_KUBECONFIG を置き換えます。

StatefulSet リソースを作成する

StatefulSet マニフェストを作成し、kubectl apply を実行してリソースを作成することで、StatefulSet オブジェクトを作成します。クライアントが StatefulSet リソースの Pod にリクエストを安定して送信するには、Service オブジェクトも作成する必要があります。

kubectl apply コマンドは、マニフェスト ファイルを使用して、Kubernetes クラスタ内のリソースを作成、更新、削除します。これは、宣言型のオブジェクト構成方法です。この方法では、ライブ オブジェクトに対して行われた書き込みが保持され、オブジェクトの構成ファイルに変更がマージされません。

StatefulSet リソースと Service リソースを作成するには、次のコマンドを実行します。

kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

次のように置き換えます。

• KUBERNETES_CLUSTER_KUBECONFIG: コンテナ ワークロードをデプロイするクラスタの kubeconfig ファイル。

• NAMESPACE: コンテナ ワークロードをデプロイする Namespace。共有クラスタの場合、これはプロジェクトの名前空間にする必要があります。標準クラスタの場合は、任意の Namespace を指定できます。

• SERVICE_NAME: Service オブジェクトの名前。StatefulSet オブジェクトが serviceName に Service オブジェクトも設定していることを確認します。

• APP_NAME: デプロイ内で実行するアプリケーションの名前。

• APP_LABEL_NAME: StatefulSet オブジェクトに属する Pod を決定するラベルセレクタ。

• STATEFULSET_NAME: StatefulSet オブジェクトの名前。

• NUMBER_OF_REPLICAS: Deployment で管理される複製 Pod オブジェクトの数。

• CONTAINER_NAME: コンテナの名前。

• CONTAINER_IMAGE: コンテナ イメージの名前。コンテナ レジストリのパスとイメージのバージョン（REGISTRY_PATH/nginx:1.23 など）を含める必要があります。コンテナ レジストリパスの設定の詳細については、Managed Harbor Service の概要をご覧ください。

• CONTAINER_STORAGE_VOLUME_PATH: ストレージ ボリュームがマウントされるコンテナ内のパス。

注: kubectl apply -f DIRECTORY を使用して、ディレクトリに保存されている構成ファイルで定義された新しいオブジェクトを作成することもできます。

たとえば、次の StatefulSet オブジェクトと対応する Service オブジェクトは、ステートフル コンテナ ワークロードを作成します。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

重要: GPU ワークロードをコンテナにデプロイする場合は、GPU コンテナ ワークロードを管理するをご覧ください。

この例では、次のようになります。

• nginx という名前の Service オブジェクトが作成されます。これは metadata: name フィールドで示されます。Service オブジェクトは、labels.app: nginx と selector.app: nginx で示される nginx というアプリをターゲットにしています。Service オブジェクトはポート 80 を公開し、web という名前を付けます。この Service オブジェクトは、ネットワーク ドメインを制御し、StatefulSet オブジェクトによってデプロイされたコンテナ化されたアプリケーションにインターネット トラフィックをルーティングします。
• replicas: 3 フィールドで設定された 3 つの複製 Pod オブジェクトを含む web という名前の StatefulSet が作成されます。
• セクション .spec.template で設定された Pod テンプレートは、その Pod オブジェクトに app: nginx というラベルが付けられていることを示します。
• .template.spec セクションで設定された Pod 仕様は、StatefulSet の Pod が 1 つのコンテナ nginx を実行し、そのコンテナがバージョン 1.23 の nginx イメージを実行するように指定します。
• Pod 仕様では、Service オブジェクトによって開かれたウェブポートが使用されます。
• .template.spec.volumeMounts セクションでは、www という名前の mountPath フィールドを指定します。mountPath は、ストレージ ボリュームがマウントされるコンテナ内のパスです。
• StatefulSet は、web-www-0、web-www-1、web-www-2 という名前の 3 つの PersistentVolumeClaim オブジェクトをプロビジョニングします。各オブジェクトには 1 GB のプロビジョニング済みストレージがあります。

作成された StatefulSet は、ターゲット数の Pod オブジェクトが実行されており、いつでも利用できることを保証します。StatefulSet は、障害が発生した Pod オブジェクトやノードから強制排除された Pod オブジェクトを自動的に置き換え、新しい Pod オブジェクトを、StatefulSet オブジェクトの Pod 仕様で定義されたストレージ リソース、リソース リクエストと上限、その他の構成に関連付けます。

StatefulSet リソースで永続ストレージをリクエストする

永続ストレージは動的にプロビジョニングできるため、基盤となるボリュームはオンデマンドで作成されます。アプリケーションは、PersistentVolumeClaim オブジェクトを使用して永続ストレージをリクエストできます。

通常は、Pod オブジェクトの作成に加えて、PersistentVolumeClaim オブジェクトを作成する必要があります。ただし、StatefulSet オブジェクトには、PersistentVolumeClaim オブジェクトを生成する volumeClaimTemplates 配列が含まれています。各 StatefulSet レプリカは独自の PersistentVolumeClaim オブジェクトを取得します。

詳細については、コンテナ ストレージを構成するをご覧ください。

次のステップ

• ステートフル ワークロードを検査する
• ステートフル ワークロードを更新する
• ノードプールを管理する