Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

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

始める前に

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

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

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

環境を準備する

事前構成済みのベアメタル Kubernetes クラスタに対してコマンドを実行するには、次のリソースが必要です。

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

`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: コンテナワークロードをデプロイするプロジェクトの名前空間。
SERVICE_NAME: Service オブジェクトの名前。 StatefulSet オブジェクトの serviceName に Service オブジェクトも設定されていることを確認します。
APP_NAME: デプロイ内で実行するアプリケーションの名前。
APP_LABEL_NAME: StatefulSet オブジェクトに属する Pod を決定するラベルセレクタ。
STATEFULSET_NAME: StatefulSet オブジェクトの名前。
NUMBER_OF_REPLICAS: デプロイが管理する複製された Pod オブジェクトの数。
CONTAINER_NAME: コンテナの名前。
CONTAINER_IMAGE: コンテナイメージの名前。コンテナレジストリのパスとイメージのバージョン（REGISTRY_PATH/nginx:1.23など）を含める必要があります。コンテナレジストリのパスの設定の詳細については、 Managed Harbor Service の概要をご覧ください。
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

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

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 セクションでは、mountPath フィールド（www という名前）を指定します。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 オブジェクトが割り当てられます。

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