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

このドキュメントでは、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 である必要があります。Standard クラスタの場合は、任意の 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
        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 セクションでは、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 オブジェクトを取得します。

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

次のステップ