このページは Cloud Translation API によって翻訳されました。

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

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

このページは、組織のアプリケーションワークロードの作成を担当するアプリケーションオペレーターグループ内のデベロッパーを対象としています。

始める前に

事前構成されたベアメタル Kubernetes クラスタに対してコマンドを実行するには、次のリソースがあることを確認します。

Kubernetes クラスタ名を確認するか、プラットフォーム管理者にクラスタ名を確認します。
まだ Kubernetes クラスタの kubeconfig ファイルがない場合は、ログインして生成します。
これらの手順では、Kubernetes クラスタの kubeconfig パスを使用して CLUSTER_KUBECONFIG を置き換えます。

ステートフルワークロードの作成に必要な権限を取得するには、プロジェクトの Namespace で Namespace 管理者ロール（namespace-admin）を付与するよう組織の IAM 管理者に依頼してください。

`StatefulSet` リソースを作成する

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

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

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

kubectl --kubeconfig 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
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
        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

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

CLUSTER_KUBECONFIG: コンテナワークロードをデプロイする Kubernetes クラスタの kubeconfig ファイル。
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 など、コンテナレジストリのパスとイメージのバージョンを含める必要があります。コンテナレジストリパスの設定の詳細については、マネージド Harbor サービスの概要をご覧ください。
CONTAINER_STORAGE_VOLUME_PATH: ストレージボリュームがマウントされるコンテナ内のパス。

たとえば、次の 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
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

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

metadata: name フィールドで指定された、nginx という名前の Service オブジェクトが作成されます。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 は、それぞれ 1 GB のプロビジョニング済みストレージがある web-www-0、web-www-1、web-www-2 という名前の 3 つの PersistentVolumeClaim オブジェクトをプロビジョニングします。

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

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

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

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

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

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

始める前に

StatefulSet リソースを作成する

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

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

`StatefulSet` リソースを作成する

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