Run a Single-Instance Stateful Application

    • Create a PersistentVolume referencing a disk in your environment.
    • Create a MySQL Deployment.
    • Expose MySQL to other pods in the cluster at a known DNS name.

    Before you begin

    • You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using or you can use one of these Kubernetes playgrounds:

      To check the version, enter .

    • You need to either have a dynamic PersistentVolume provisioner with a default StorageClass, or yourself to satisfy the PersistentVolumeClaims used here.

    You can run a stateful application by creating a Kubernetes Deployment and connecting it to an existing PersistentVolume using a PersistentVolumeClaim. For example, this YAML file describes a Deployment that runs MySQL and references the PersistentVolumeClaim. The file defines a volume mount for /var/lib/mysql, and then creates a PersistentVolumeClaim that looks for a 20G volume. This claim is satisfied by any existing volume that meets the requirements, or by a dynamic provisioner.

    Note: The password is defined in the config yaml, and this is insecure. See for a secure solution.

    application/mysql/mysql-deployment.yaml

    Run a Single-Instance Stateful Application - 图2

    1. apiVersion: v1
    2. kind: PersistentVolume
    3. metadata:
    4.   name: mysql-pv-volume
    5.   labels:
    6.     type: local
    7. spec:
    8.   storageClassName: manual
    9.   capacity:
    10.     storage: 20Gi
    11.   accessModes:
    12.     - ReadWriteOnce
    13.   hostPath:
    14.     path: "/mnt/data"
    15. ---
    16. apiVersion: v1
    17. kind: PersistentVolumeClaim
    18. metadata:
    19.   name: mysql-pv-claim
    20. spec:
    21.   storageClassName: manual
    22.     - ReadWriteOnce
    23.   resources:
    24.     requests:
    25.       storage: 20Gi
      1.  kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml

    2. Deploy the contents of the YAML file:

      1.  kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml

    3. Display information about the Deployment:

      The output is similar to this:

      2.  Namespace:            default
      3.  CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
      4.  Labels:               app=mysql
      5.  Annotations:          deployment.kubernetes.io/revision=1
      6.  Selector:             app=mysql
      7.  Replicas:             1 desired | 1 updated | 1 total | 0 available | 1 unavailable
      8.  StrategyType:         Recreate
      9.  MinReadySeconds:      0
      10.  Pod Template:
      11.    Labels:       app=mysql
      12.    Containers:
      13.     mysql:
      14.      Image:      mysql:5.6
      15.      Port:       3306/TCP
      16.      Environment:
      17.        MYSQL_ROOT_PASSWORD:      password
      18.      Mounts:
      19.        /var/lib/mysql from mysql-persistent-storage (rw)
      20.    Volumes:
      21.     mysql-persistent-storage:
      22.      Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
      23.      ClaimName:  mysql-pv-claim
      24.      ReadOnly:   false
      25.  Conditions:
      26.    Type          Status  Reason
      27.    Available     False   MinimumReplicasUnavailable
      28.    Progressing   True    ReplicaSetUpdated
      30.  NewReplicaSet:        mysql-63082529 (1/1 replicas created)
      31.  Events:
      32.    FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
      33.    ---------    --------    -----    ----                -------------    --------    ------            -------
      34.    33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1

    4. List the pods created by the Deployment:

      1.  kubectl get pods -l app=mysql

      The output is similar to this:

      1.  NAME                   READY     STATUS    RESTARTS   AGE
      2.  mysql-63082529-2z3ki   1/1       Running   0          3m

    5. Inspect the PersistentVolumeClaim:

      The output is similar to this:

      1.  Name:         mysql-pv-claim
      2.  Namespace:    default
      3.  StorageClass:
      4.  Status:       Bound
      5.  Volume:       mysql-pv-volume
      6.  Labels:       <none>
      7.  Annotations:    pv.kubernetes.io/bind-completed=yes
      8.                  pv.kubernetes.io/bound-by-controller=yes
      9.  Capacity:     20Gi
      10.  Access Modes: RWO
      11.  Events:       <none>

    Accessing the MySQL instance

    Run a MySQL client to connect to the server:

    1. kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword

    This command creates a new Pod in the cluster running a MySQL client and connects it to the server through the Service. If it connects, you know your stateful MySQL database is up and running.

    1. Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
    2. If you don't see a command prompt, try pressing enter.
    4. mysql>

    The image or any other part of the Deployment can be updated as usual with the kubectl apply command. Here are some precautions that are specific to stateful apps:

    • Don’t scale the app. This setup is for single-instance apps only. The underlying PersistentVolume can only be mounted to one Pod. For clustered stateful apps, see the .
    • Use strategy: type: Recreate in the Deployment configuration YAML file. This instructs Kubernetes to not use rolling updates. Rolling updates will not work, as you cannot have more than one Pod running at a time. The strategy will stop the first pod before creating a new one with the updated configuration.

    Deleting a deployment

    Delete the deployed objects by name:

    If you manually provisioned a PersistentVolume, you also need to manually delete it, as well as release the underlying resource. If you used a dynamic provisioner, it automatically deletes the PersistentVolume when it sees that you deleted the PersistentVolumeClaim. Some dynamic provisioners (such as those for EBS and PD) also release the underlying resource upon deleting the PersistentVolume.