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

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

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

始める前に

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

  1. Kubernetes クラスタ名を確認するか、プラットフォーム管理者にクラスタ名を確認します。

  2. まだ Kubernetes クラスタの kubeconfig ファイルがない場合は、ログインして生成します。

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

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

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。

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

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

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

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

  • NUMBER_OF_REPLICAS: Deployment が管理する複製 Pod オブジェクトの数。

  • CONTAINER_NAME: コンテナの名前。

  • CONTAINER_IMAGE: コンテナ イメージの名前。REGISTRY_PATH/nginx:1.23 など、コンテナ レジストリのパスとイメージのバージョンを含める必要があります。

  • 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
        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: nginxselector.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.23nginx イメージを実行するように指定します。
  • Pod 仕様では、Service オブジェクトによって開かれたウェブポートが使用されます。
  • .template.spec.volumeMounts セクションでは、www という名前の mountPath フィールドを指定します。mountPath は、ストレージ ボリュームがマウントされるコンテナ内のパスです。
  • StatefulSet は、それぞれ 1 GB のプロビジョニング済みストレージがある web-www-0web-www-1web-www-2 という名前の 3 つの PersistentVolumeClaim オブジェクトをプロビジョニングします。

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

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

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

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

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