[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003e\u003ccode\u003eStatefulSet\u003c/code\u003e objects manage stateful applications that require unique, persistent identities, stable hostnames, and data saved to persistent storage.\u003c/p\u003e\n"],["\u003cp\u003eEach \u003ccode\u003eStatefulSet\u003c/code\u003e object uses a \u003ccode\u003ePod\u003c/code\u003e template to define how its \u003ccode\u003ePod\u003c/code\u003e objects should look, including container applications, mounted volumes, labels, and selectors.\u003c/p\u003e\n"],["\u003cp\u003eCreating a \u003ccode\u003eStatefulSet\u003c/code\u003e involves defining a manifest and using \u003ccode\u003ekubectl apply\u003c/code\u003e, and a \u003ccode\u003eService\u003c/code\u003e object must also be defined to provide stable access to the \u003ccode\u003eStatefulSet\u003c/code\u003e's pods.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eStatefulSet\u003c/code\u003e objects automatically manage the number of running \u003ccode\u003ePod\u003c/code\u003e objects, replacing failed or evicted ones while maintaining persistent storage and other configurations.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eStatefulSet\u003c/code\u003e objects use a \u003ccode\u003evolumeClaimTemplates\u003c/code\u003e array to dynamically provision persistent storage via \u003ccode\u003ePersistentVolumeClaim\u003c/code\u003e objects, ensuring each replica has its own claim.\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 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. For more\ninformation, see\n[Audiences for GDC air-gapped documentation](/distributed-cloud/hosted/docs/latest/gdch/resources/audiences).\n\nBefore you begin\n----------------\n\nTo run commands against a\n[Kubernetes cluster](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/clusters#cluster-architecture),\nmake sure you have the following resources:\n\n1. Locate the Kubernetes cluster name, or ask your Platform Administrator what\n the cluster name is.\n\n2. [Sign in and generate](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/iam/sign-in#zonal-cluster-kubeconfig)\n the 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\"\u003eKUBERNETES_CLUSTER_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 Kubernetes 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\"\u003eKUBERNETES_CLUSTER_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 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\"\u003eKUBERNETES_CLUSTER_KUBECONFIG\u003c/var\u003e: the kubeconfig file for\n the 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 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/gdch/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 desired 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/gdch/application/ao-user/containers/access-multi-writer-storage)."]]