作成されると、StatefulSet により、選択された数の Pod オブジェクトが実行され、いつでも利用できるようになります。StatefulSet は、障害が発生した Pod オブジェクトやノードから削除された Pod オブジェクトを自動的に置き換え、新しい Pod オブジェクトを StatefulSet オブジェクトの Pod 仕様で定義されたストレージ リソース、リソースのリクエストと制限、その他の構成に関連付けます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003e\u003ccode\u003eStatefulSet\u003c/code\u003e objects are used to manage stateful applications that require persistent storage, ensuring each \u003ccode\u003ePod\u003c/code\u003e has a unique identity and stable hostname.\u003c/p\u003e\n"],["\u003cp\u003eCreating a \u003ccode\u003eStatefulSet\u003c/code\u003e involves defining a \u003ccode\u003ePod\u003c/code\u003e template, which specifies the containers, volumes, labels, and selectors for the \u003ccode\u003ePod\u003c/code\u003e objects within the \u003ccode\u003eStatefulSet\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eTo ensure clients can stably send requests to the \u003ccode\u003eStatefulSet\u003c/code\u003e pods, a corresponding \u003ccode\u003eService\u003c/code\u003e object must also be created and referenced within the \u003ccode\u003eStatefulSet\u003c/code\u003e definition.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eStatefulSet\u003c/code\u003e objects use \u003ccode\u003evolumeClaimTemplates\u003c/code\u003e to automatically create \u003ccode\u003ePersistentVolumeClaim\u003c/code\u003e objects, providing each replica with its own persistent storage volume, dynamically provisioned when needed.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eStatefulSet\u003c/code\u003e ensures the desired number of \u003ccode\u003ePod\u003c/code\u003e objects are running, replacing any that fail and maintaining their configurations.\u003c/p\u003e\n"]]],[],null,["# Create stateful workloads\n\nThis page explains how to create and manage stateful workloads within a\nGoogle Distributed Cloud (GDC) air-gapped appliance Kubernetes cluster. Stateful workloads let you\nscale your application deployment with persistent storage. Persistent storage\nprovides your application with consistent identities and stable hostnames,\nregardless of where its workloads are scheduled.\n\nThis page is for developers within the application operator group, who are\nresponsible for creating application workloads for their organization.\n\nBefore you begin\n----------------\n\nTo run commands against the pre-configured bare metal Kubernetes cluster, make sure you have the\nfollowing resources:\n\n1. Locate the Kubernetes cluster name, or ask your Platform\n Administrator what the cluster name is.\n\n2. [Sign in and generate](/distributed-cloud/hosted/docs/latest/appliance/application/ao-user/iam/sign-in#kubernetes-cluster-kubeconfig) the\n kubeconfig file for the Kubernetes cluster if you don't have one.\n\n3. Use the kubeconfig path of the Kubernetes cluster to replace\n \u003cvar translate=\"no\"\u003eCLUSTER_KUBECONFIG\u003c/var\u003e in these instructions.\n\nTo get the required permissions to create stateful workloads, ask your\nOrganization IAM Admin to grant you the Namespace Admin role (`namespace-admin`)\nin your project namespace.\n\nCreate a `StatefulSet` resource\n-------------------------------\n\nCreate a `StatefulSet` object by writing a `StatefulSet` manifest and\nrunning `kubectl apply` to create the resource. To provide a stable way for\nclients to send requests to the pods of your `StatefulSet` resource, you must\nalso create a `Service` object.\n\nThe `kubectl apply` command uses manifest files to create, update, and delete\nresources in your cluster. This is a declarative method of object\nconfiguration. This method retains writes made to live objects without merging\nthe changes back into the object configuration files.\n\nTo create a `StatefulSet` and `Service` resource, run: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eCLUSTER_KUBECONFIG\u003c/var\u003e -n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e \\\n apply -f - \u003c\u003cEOF\n apiVersion: v1\n kind: Service\n metadata:\n name: \u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e\n labels:\n app: \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e\n spec:\n ports:\n - port: 80\n name: web\n clusterIP: None\n selector:\n app: \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e\n ---\n apiVersion: apps/v1\n kind: StatefulSet\n metadata:\n name: \u003cvar translate=\"no\"\u003eSTATEFULSET_NAME\u003c/var\u003e\n spec:\n selector:\n matchLabels:\n app: \u003cvar translate=\"no\"\u003eAPP_LABEL_NAME\u003c/var\u003e\n serviceName: \"\u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e\"\n replicas: \u003cvar translate=\"no\"\u003eNUMBER_OF_REPLICAS\u003c/var\u003e\n template:\n metadata:\n labels:\n app: \u003cvar translate=\"no\"\u003eAPP_LABEL_NAME\u003c/var\u003e\n spec:\n terminationGracePeriodSeconds: 10\n containers:\n - name: \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e\n image: \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE\u003c/var\u003e\n resources:\n requests:\n nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1\n limits:\n nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1\n ports:\n - containerPort: 80\n name: web\n volumeMounts:\n - name: www\n mountPath: \u003cvar translate=\"no\"\u003eCONTAINER_STORAGE_VOLUME_PATH\u003c/var\u003e\n volumeClaimTemplates:\n - metadata:\n name: www\n spec:\n accessModes: [ \"ReadWriteOnce\" ]\n resources:\n requests:\n storage: 1Gi\n EOF\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_KUBECONFIG\u003c/var\u003e: the kubeconfig file for\n the Kubernetes cluster to which you're deploying container workloads.\n\n- \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e: the project namespace in which to deploy the container workloads.\n\n- \u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e: the name of the `Service` object.\n Ensure the `StatefulSet` object sets the `Service` object in its `serviceName`\n as well.\n\n- \u003cvar translate=\"no\"\u003eAPP_NAME\u003c/var\u003e: the name of the application to run within\n the deployment.\n\n- \u003cvar translate=\"no\"\u003eAPP_LABEL_NAME\u003c/var\u003e: the label selector that determines\n which pods belong to the `StatefulSet` object.\n\n- \u003cvar translate=\"no\"\u003eSTATEFULSET_NAME\u003c/var\u003e: the name of the `StatefulSet`\n object.\n\n- \u003cvar translate=\"no\"\u003eNUMBER_OF_REPLICAS\u003c/var\u003e: the number of replicated `Pod`\n objects that the deployment manages.\n\n- \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e: the name of the container.\n\n- \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE\u003c/var\u003e: the name of the container image. You\n must include the container registry path and version of the image, such as\n \u003cvar class=\"readonly\" translate=\"no\"\u003eREGISTRY_PATH\u003c/var\u003e`/nginx:1.23`.\n\n- \u003cvar translate=\"no\"\u003eCONTAINER_STORAGE_VOLUME_PATH\u003c/var\u003e: the path within the\n container at which a storage volume is mounted.\n\n| **Note:** You can also use `kubectl apply -f `\u003cvar translate=\"no\"\u003eDIRECTORY\u003c/var\u003e to create new objects defined by configuration files stored in a directory.\n\nAs an example, the following `StatefulSet` object and corresponding `Service`\nobject create stateful container workloads: \n\n apiVersion: v1\n kind: Service\n metadata:\n name: nginx\n labels:\n app: nginx\n spec:\n ports:\n - port: 80\n name: web\n clusterIP: None\n selector:\n app: nginx\n ---\n apiVersion: apps/v1\n kind: StatefulSet\n metadata:\n name: web\n spec:\n selector:\n matchLabels:\n app: nginx\n serviceName: \"nginx\"\n replicas: 3\n template:\n metadata:\n labels:\n app: nginx\n spec:\n terminationGracePeriodSeconds: 10\n containers:\n - name: nginx\n image: \u003cvar class=\"readonly\" translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eREGISTRY_PATH\u003c/span\u003e\u003c/var\u003e/nginx:1.23\n resources:\n requests:\n nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1\n limits:\n nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1\n ports:\n - containerPort: 80\n name: web\n volumeMounts:\n - name: www\n mountPath: /usr/share/nginx/html\n volumeClaimTemplates:\n - metadata:\n name: www\n spec:\n accessModes: [ \"ReadWriteOnce\" ]\n resources:\n requests:\n storage: 1Gi\n\n| **Important:** If you're deploying GPU workloads to your containers, see [Manage GPU container workloads](/distributed-cloud/hosted/docs/latest/appliance/application/ao-user/containers/deploy-gpu-container-workloads) for more information.\n\nIn this example:\n\n- A `Service` object named `nginx` is created, indicated by the `metadata: name` field. The `Service` object targets an app called `nginx`, indicated by `labels.app: nginx` and `selector.app: nginx`. The `Service` object exposes port 80 and names it `web`. This `Service` object controls the network domain and routes internet traffic to the containerized application deployed by the `StatefulSet` object.\n- A `StatefulSet` named `web` is created with three replicated `Pod` objects, as set by the field `replicas: 3`.\n- The `Pod` template, set by the section `.spec.template`, indicates that its `Pod` objects are labelled `app: nginx`.\n- The `Pod` specification, set by the section `.template.spec`, indicates that the pods of the `StatefulSet` run one container, `nginx`, which runs the `nginx` image at version `1.23`.\n- The `Pod` specification uses the web port opened by the `Service` object.\n- The `.template.spec.volumeMounts` section specifies a `mountPath` field, which is named `www`. The `mountPath` is the path in the container where a storage volume is mounted.\n- The `StatefulSet` provisions three `PersistentVolumeClaim` objects, named `web-www-0`, `web-www-1`, and `web-www-2`, with 1GB of provisioned storage each.\n\nAfter it's created, the `StatefulSet` ensures that the chosen number of `Pod`\nobjects are running and available at all times. The `StatefulSet` automatically\nreplaces `Pod` objects that fail or are evicted from their nodes, and associates\nnew `Pod` objects with the storage resources, resource requests and limits, and\nother configurations defined in the `Pod` specification of the `StatefulSet`\nobject.\n\nRequest persistent storage in a `StatefulSet` resource\n------------------------------------------------------\n\nPersistent storage can be dynamically provisioned so that the underlying volumes\nare created on demand. Applications can request persistent storage with a\n`PersistentVolumeClaim` object.\n\nTypically, you must create `PersistentVolumeClaim` objects in addition to\ncreating the `Pod` object. However, `StatefulSet` objects include a\n`volumeClaimTemplates` array which generates the `PersistentVolumeClaim`\nobjects. Each `StatefulSet` replica gets its own `PersistentVolumeClaim` object.\n\nFor more information, see\n[Configure container storage](/distributed-cloud/hosted/docs/latest/appliance/application/ao-user/containers/access-multi-writer-storage)."]]