Creating a StatefulSet

Scenario

StatefulSets are a type of workloads whose data or status is stored while they are running. For example, MySQL is a StatefulSet because it needs to store new data.

A container can be migrated between different hosts, but data is not stored on the hosts. To store StatefulSet data persistently, mount HA storage volumes provided by CCE to the container.

Constraints

• When you delete or scale a StatefulSet, the system does not delete the storage volumes associated with the StatefulSet to ensure data security.
• When you delete a StatefulSet, reduce the number of replicas to 0 before deleting the StatefulSet so that pods in the StatefulSet can be stopped in order.
• When you create a StatefulSet, a headless Service is required for pod access. For details, see Headless Service.

Prerequisites

• You already have an available cluster before you create a workload. For details about how to create a cluster, see Buying a CCE Autopilot Cluster.
• You have configured the VPC endpoints for accessing the image center and OBS. When you create a cluster, the system automatically creates VPC endpoints. You can go to the Overview page of the cluster and check whether VPC endpoints have been configured for Image Access in the Networking Configuration area. If no VPC endpoint is configured for the cluster, configure one by following the instructions in Configuring a VPC Endpoint for Accessing the Image Center.

Using the CCE Console

1. Log in to the CCE console.
2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and then click the Create Workload in the upper right corner.
3. Set basic information about the workload.
   Basic Info

   • Workload Type: Select StatefulSet.
   • Workload Name: Enter a name for the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a lowercase letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.
   • Namespace: Select a namespace. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
   • Pods: Enter the number of pods of the workload.
   Container Settings

   • Container Information
     A pod can have more than one container. You can click Add Container on the right to configure multiple containers.

     • Basic Info: Configure basic information about each container.

       Table 1 Basic container information

       Parameter	Description
       Container Name	Enter a name for the container.
       Pull Policy	Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, an existing local image is preferentially used. If there is no existing image, an image will be pulled from the image repository.
       Image Name	Click Select Image and select the image used by the container. To use a third-party image, see Using Third-Party Images.
       Image Tag	Select the image tag to be deployed.
       CPU Quota	CPU limit, which is the maximum CPU available for the container to prevent excessive resource usage.
       Memory Quota	Memory limit, which is the maximum memory available for the container. When the container's memory usage exceeds the memory limit, the container will be terminated.
       (Optional) Init Container	Whether the container will be used as an init container. An init container does not support health check. An init container is a special container that runs before other app containers in a pod are started. Each pod can contain multiple containers. In addition, a pod can contain one or more init containers. Application containers in a pod are started and run only after the running of all init containers completes. For details, see Init Containers.
       (Optional) Run Option	Add run options for the container. For details, see Pod. CCE Autopilot supports the following run options: stdin: allows containers to receive input from external sources, such as terminals or other input streams. tty: allocates a pseudo terminal to containers, allowing you to send commands to them as if you were using a local terminal. In most cases, tty is enabled along with stdin, indicating that the terminal (tty) is associated with the standard input (stdin) of the container. This allows for interactive operations, similar to the kubectl exec -i -t command. The difference is that this parameter has been configured when the pod is launched.

     • (Optional) Lifecycle: Configure operations to be performed in a specific phase of the container lifecycle, such as startup command, PostStart, and PreStop. For details, see Configuring the Container Lifecycle.
     • (Optional) Health Check: Set the liveness probe, ready probe, and startup probe as required. For details, see Setting Health Check for a Container.
     • (Optional) Environment Variables: Configure variables for the container running environment using key-value pairs. These variables transfer external information to containers running in pods and can be flexibly modified after application deployment. For details, see Configuring Environment Variables.
     • (Optional) Data Storage: Mount local storage or cloud storage to the container. The application scenarios and the ways for mounting the volumes vary with the storage type.
       

       • StatefulSets allow you to mount storage volumes dynamically.

         Dynamic mounting is achieved by using the volumeClaimTemplates field and depends on the dynamic creation capability of StorageClass. A StatefulSet associates each pod with a PVC using the volumeClaimTemplates field, and the PVC is bound to the corresponding PV. Therefore, after the pod is rescheduled, the original data can still be mounted based on the PVC name.

       • After a workload is created, the storage that is dynamically mounted cannot be updated.
     • (Optional) Security Context: Assign container permissions to protect the system and other containers from being affected. Enter the user ID to assign container permissions and prevent systems and other containers from being affected.
   • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR. For details about default-secret, see default-secret.

   Headless Service Parameters

   A headless Service is used to solve the problem of mutual access between pods in a StatefulSet. The headless Service provides a fixed access domain name for each pod. For details, see Headless Service.

   (Optional) Service Settings

   A Service provides external access for pods. With a static IP address, a Service forwards the traffic to pods and automatically balances load for these pods.

   You can also create a Service after creating a workload. For details about Services of different types, see Services.

   (Optional) Advanced Settings

   • Upgrade: Specify the upgrade mode and upgrade parameters of the workload. Rolling upgrade and Replace upgrade are supported. For details, see Configuring the Workload Upgrade Policy.
   • Pod Management Policies

     For some distributed systems, the StatefulSet sequence is unnecessary and/or should not occur. These systems require only uniqueness and identifiers.

     • OrderedReady: The StatefulSet will deploy, delete, or scale pods in order and one by one. (The StatefulSet continues only after the previous pod is ready or deleted.) This is the default policy.
     • Parallel: The StatefulSet will create pods in parallel to match the desired scale without waiting, and will delete all pods at once.
   • Labels and Annotations: Add labels or annotations for pods using key-value pairs. After entering the key and value, click Confirm. For details about how to use and configure labels and annotations, see Configuring Labels and Annotations.
   • DNS: Configure a DNS policy for the workload. For details, see DNS Configuration.
   • APM Settings: Use Application Performance Management (APM) to provide more accurate problem analysis and location for Java programs. For details, see Configuring APM.
   • Network configuration:
     • Whether to enable the network configuration of a specified container: You can enable the specified container network configuration. The workload is created using the container subnet and security group in the specified container network configuration. For details, see Associating a Subnet and Security Group with a Namespace or Workload Using a Container Network Configuration.
     • Specify the container network configuration name: Only the custom container network configuration whose associated resource type is workload can be selected.

4. On the Confirm page, ensure that the ephemeral storage of a single pod meets the container requirements. For details, see Increasing the Ephemeral Storage Space of a Pod. Confirm the information and select I have read and agree to the pricing policy. Click Create Workload in the lower right corner.

Using kubectl

Node affinity and anti-affinity are not available for CCE Autopilot clusters. When you use kubectl to create a workload, do not configure the affinity field to prevent pod creation failures.

1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
2. Create and edit the nginx-statefulset.yaml file.

   nginx-statefulset.yaml is an example file name. You can change it as required.

   vi nginx-statefulset.yaml

   The following provides an example of the file contents. For more information on StatefulSet, see the Kubernetes documentation.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: nginx
   spec:
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
           - name: container-1
             image: nginx:latest
             imagePullPolicy: IfNotPresent
             resources:
               requests:
                 cpu: 250m
                 memory: 512Mi
               limits:
                 cpu: 250m
                 memory: 512Mi
         imagePullSecrets:
           - name: default-secret
         dnsPolicy: ClusterFirst
     serviceName: nginx-svc
     replicas: 2
     updateStrategy:
       type: RollingUpdate

   vi nginx-headless.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx-svc
     namespace: default
     labels:
       app: nginx
   spec:
     selector:
       app: nginx
       version: v1
     clusterIP: None
     ports:
       - name: nginx
         targetPort: 80
         nodePort: 0
         port: 80
         protocol: TCP
     type: ClusterIP

3. Create a workload and the corresponding headless service.

   kubectl create -f nginx-statefulset.yaml

   If the following information is displayed, the StatefulSet has been successfully created.

   statefulset.apps/nginx created

   kubectl create -f nginx-headless.yaml

   If the following information is displayed, the headless service has been successfully created.

   service/nginx-svc created

4. If the workload will be accessed (either within the cluster or from the external network), set the corresponding workload access type. For details, see Services.