{"id":590,"date":"2021-06-17T07:14:00","date_gmt":"2021-06-17T07:14:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=590"},"modified":"2021-06-17T07:14:00","modified_gmt":"2021-06-17T07:14:00","slug":"persistent-volume-google-kubernetes-engine","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=590","title":{"rendered":"How to Add Persistent Volume in Google Kubernetes Engine"},"content":{"rendered":"

In this blog, you will learn how to setup Persistent Volume For the GKE Kubernetes cluster.<\/a><\/p>\n

If you want to preserve the data even after a pod deletion or pod failures, you should use persistent volumes.<\/p>\n

About GKE Persistent Volumes<\/h2>\n

In GKE, you can provision a Google Cloud Persistent disk (Compute Engine Disks) to be used as a persistent volume in the Kubernetes cluster<\/a>.<\/p>\n

You can dynamically provision the persistent volumes on demand using the Kubernbetes persistent volume claim manifests.<\/p>\n

Based on the type of persistent disk storage class, GKE will ensure the volume is provisioned and makes it available for use in the cluster.<\/p>\n

Following are some important concepts you need to be aware of when using persistent volumes with GKE.<\/p>\n

    \n
  1. You can use both google persistent disk and Google Filestore (NFS) as persistent volumes for GKE.<\/li>\n
  2. Persistent disks can be regional (offers high durability) or zonal based on the requirements.<\/li>\n
  3. You can also use a pre-existing persistent disk with data as a GKE persistent volume.<\/li>\n
  4. By default, dynamic provisioning uses the pd-standard<\/code> disk type as a storage class. It is one of the four standard persistent disk types<\/a> offered by Google Cloud.<\/li>\n
  5. You can back up the persistent volumes using a Volume snapshot. This feature works only if you have the Compute Engine persistent disk CSI Driver enabled in the cluster.<\/li>\n<\/ol>\n

    Setup Persistent Volume For GKE<\/h2>\n

    We will do the following.<\/p>\n

      \n
    1. Create a storage class<\/li>\n
    2. Provision a Persistent volume using the storage class.<\/li>\n
    3. Test a deployment with the persistent volume.<\/li>\n<\/ol>\n

      Lets gets started with the setup.<\/p>\n

      Create a storage class for GKE<\/h2>\n

      Storage class is a simple way of segregating the storage options.<\/p>\n

      To put simply, a storage class defines what type of storage to be provisioned.<\/p>\n

      For example, we can classify our storage class as gold<\/code> and silver<\/code>. These names are arbitrary and use a name that is meaningful to you.<\/p>\n

      Gold storage class uses the pd-ssd<\/code> persistent disk type for high IOPS applications (to be used with databases). While silver storage class uses the pd-standard<\/code> volume type to be used for backups and normal disk operations.<\/p>\n

      These storage class segregations are completely based on the project requirements.<\/p>\n

      \n
      Note: There are default storage classes available in GKE which are backed by pd-standard<\/code> disks. If you don’t specify a storage class while provisioning a PV, the default storage class is considered.<\/div>\n<\/div>\n

      Lets create a gold storage class.<\/p>\n

      Save the following manifest as storage-class.yaml<\/code>.<\/p>\n

      apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: gold\nprovisioner: kubernetes.io\/gce-pd\nvolumeBindingMode: Immediate\nallowVolumeExpansion: true\nreclaimPolicy: Delete\nparameters:\n  type: pd-standard\n  fstype: ext4\n  replication-type: none<\/code><\/pre>\n
      Create the storage class.<\/p>\n
      kubectl apply -f storage-class.yaml<\/code><\/pre>\n
      A little explanation about the parameters.<\/p>\n
        \n
      1. Type: <\/strong> supports pd-standard<\/code> & pd-ssd<\/code>. If you don’t specify anything, it defaults pd-standard<\/code><\/li>\n
      2. fstype:<\/strong> supports ext4<\/code> and xfs<\/code>. Defaults to ext4<\/code>.<\/li>\n
      3. replication-type: <\/strong>This decides whether the disk is zonal or regional. If you don’t specify regional-pd<\/code>, it defaults to a zonal disk.<\/li>\n
      4. allowVolumeExpansion:<\/strong> With this parameter, you can expand the persistent volume if required.<\/li>\n
      5. volumeBindingMode:<\/strong> There are two modes. Immediate<\/code> and WaitForFirstConsumer<\/code>. In cases where the storage is not accessible from all the nodes, use WaitForFirstConsumer<\/code> so that volume binding will happen after the pod gets created.<\/li>\n<\/ol>\n
        Create a Persistent Volume using PVC on GKE<\/h2>\n
        To create a persistent volume you need to create a Persistent Volume claim.<\/p>\n
        persistentVolumeClaim<\/code> is the way to request storage based on a storage class and use it with a pod. The pod to Persistent volume mapping happens through PVC.<\/p>\n
        Meaning, when you request for a PVC, a persistent volume (google persistent disk) will be dynamically provisioned based on the pd-standard<\/code> or pd-ssd<\/code> the parameter you specified in the storage class.<\/p>\n
        So PVC (Request) –> Storage Class (Defines Type of disk) –> Persistent Volume (Google Persistent Disk)<\/p>\n
        The accessModes<\/strong> in persistentVolume<\/strong> defines how a volume should be mounted. There are 4 access modes available:<\/p>\n
          \n
        1. ReadWriteOnce<\/code> (RWO): This access mode allows the volume to be mounted as read-write by a single worker node at a time. All the pods on that specific node can access the volume.<\/li>\n
        2. ReadWriteMany<\/code> (RWX): It defines that the volume can be concurrently mounted to multiple worker nodes with read-write access for any Pod.<\/li>\n
        3. ReadOnlyMany<\/code> (ROX): This access mode allows multiple worker nodes to mount the volume simultaneously, but only in read-only mode.<\/li>\n
        4. ReadWriteOncePod<\/code> (RWOP): Only a single pod in the entire cluster can gain access to the volume.<\/li>\n<\/ol>\n
          \n
          \ud83d\udca1<\/div>\n
          Note:<\/strong><\/b> ReadWriteMany option is not supported in persistent volumes backed by Google persistent disk. If you have a use case to use ReadWriteMany volumes, you can consider google filestore backed persistent volumes for GKE.<\/div>\n<\/div>\n
          In our example, we are creating a PVC<\/code> using gold storage class with 50GB<\/code> storage in the default<\/code> namespace. You can also assign a custom namespace under metadata<\/code><\/p>\n
          Save the manifest as pvc.yaml<\/code><\/p>\n
          apiVersion: v1\n kind: PersistentVolumeClaim\n metadata:\n   name: webapps-storage\n spec:\n   storageClassName: gold\n   accessModes:\n     - ReadWriteOnce\n   resources:\n     requests:\n       storage: 50Gi<\/code><\/pre>\n
          Now, create the PVC.<\/p>\n
          kubeactl apply -f pvc.yaml<\/code><\/pre>\n
          You can check the pv and pvc using the following commands.<\/p>\n
          kubectl get pv\nkubectl get pvc<\/code><\/pre>\n
          If you check the compute engine disks, you will see a 50GB disk created as shown below.<\/p>\n
          \"\"
          Click to view in HD<\/span><\/figcaption><\/figure>\n
          Since the gold storage class volumeBindingMode<\/code> is immediate, you will see the volume provisioned and the claim available for pods to use.<\/p>\n
          If your storage class binding mode is WaitForFirstConsumer<\/code> , after deploying the PVC, you will see PVC status in a pending state. Because only after a pod is created with a PVC request, kubernetes creates the persistent volume<\/p>\n
          The following image shows the difference between immediate<\/code> and WaitForFirstConsumer<\/code> modes.<\/p>\n
          \"\"
          Click to view in HD<\/span><\/figcaption><\/figure>\n
          Creating Persistent Volumes From Existing Google Compute Disks<\/h2>\n
          You can create persist volumes volumes from existing google compute disks.<\/p>\n
          For demonstration purpose, I am creating a compute disk named gke-pv<\/code> of size 50GB<\/p>\n
          gcloud compute disks create gke-pv  --zone=us-central1-a --size=50GB<\/code><\/pre>\n
          Now we have a disk available to be used as PV in GKE.<\/p>\n
          Next step is to,<\/p>\n
            \n
          1. Create a Persistent volume named app-storage<\/code> from the gke-pv<\/code> disk<\/li>\n
          2. To use the persistent volume with the pod, we will create a persistent volume claim with the same name we use in the PV claimRef<\/code>, ie app-storage-claim<\/code><\/li>\n<\/ol>\n
            Save the following manifest as disk-pv.yaml<\/code><\/p>\n
            apiVersion: v1\nkind: PersistentVolume\nmetadata:\n  name: app-storage\nspec:\n  storageClassName: \"apps\"\n  capacity:\n    storage: 50\n  accessModes:\n    - ReadWriteOnce\n  claimRef:\n    namespace: default\n    name: app-storage-claim\n  gcePersistentDisk:\n    pdName: gke-pv\n    fsType: ext4\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: app-storage-claim\nspec:\n  storageClassName: \"apps\"\n  accessModes:\n    - ReadWriteOnce\n  resources:\n    requests:\n      storage: 50<\/code><\/pre>\n
            Create the PV & PVC.<\/p>\n
            kubectl apply -f disk-pv.yaml<\/code><\/pre>\n
            You can check the pv and pvc using the following commands.<\/p>\n
            kubectl get pv\nkubectl get pvc<\/code><\/pre>\n
            Example GKE Pod With Persistent Volume<\/h2>\n
            Now that we know the two ways to use google persistent disk as GKE persistent volumes, we will look at using the persistent volume in a pod.<\/p>\n
            To mount a persistent volume to the pod, we use the Persistent volume claim<\/strong> name in the volumes<\/code> section, and we use the volume name in the volumeMounts<\/code> section with the container path to mount.<\/p>\n
            In out example, we will be mounting the  \/usr\/share\/nginx\/html<\/code> path to the persistent volume.<\/p>\n
            apiVersion: v1\nkind: Pod\nmetadata:\n  name: nginx-app-pod\nspec:\n  volumes:\n    - name: app-storage\n      persistentVolumeClaim:\n        claimName: app-storage-claim\n  containers:\n    - name: nginx-app-container\n      image: nginx\n      ports:\n        - containerPort: 80\n          name: \"http-server\"\n      volumeMounts:\n        - mountPath: \"\/usr\/share\/nginx\/html\"\n          name: app-storage<\/code><\/pre>\n
            Example GKE Deployment With Persistent Volume Claim<\/h2>\n
            Lets try using the persistent volume on a Jenkins delployment.<\/p>\n
            This Jenkins deployment<\/a> creates a pod with all its data mounted to the persistent volume. So, even if you delete the pod, a new pod will come up and mount itself to the persistent volume keeping the same old state of Jenkins.<\/p>\n
            Here is a little explanation about the deployment<\/p>\n
              \n
            1. Create a Persistent volume claim with the gold<\/code> storage class.<\/li>\n
            2. In deployment, Create a  Volumes<\/code> definition named jenkins-data<\/code> and add the jenkins-pv-claim<\/code> to be added as a volume to the container<\/li>\n
            3. In container spec<\/code>, under volumeMounts<\/code>, we define the volume name and mount path \/var\/jenkins_home<\/code> for the container.<\/li>\n
            4. A service will expose Jenkins on NodePort 32000<\/code><\/li>\n<\/ol>\n
              Save the following manifest as jenkins.yaml<\/code>. It has the PVC, deployment and service definitions.<\/p>\n
              # Persistent Volume Claim\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: jenkins-pv-claim\nspec:\n  storageClassName: gold\n  accessModes:\n    - ReadWriteOnce\n  resources:\n    requests:\n      storage: 50Gi\n\n# Deployment Config\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: jenkins-deployment\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: jenkins\n  template:\n    metadata:\n      labels:\n        app: jenkins\n    spec:\n      securityContext:\n            fsGroup: 1000 \n            runAsUser: 1000\n      containers:\n        - name: jenkins\n          image: jenkins\/jenkins:lts\n          resources:\n            limits:\n              memory: \"2Gi\"\n              cpu: \"1000m\"\n            requests:\n              memory: \"500Mi\"\n              cpu: \"500m\"\n          ports:\n            - name: httpport\n              containerPort: 8080\n            - name: jnlpport\n              containerPort: 50000\n          livenessProbe:\n            httpGet:\n              path: \"\/login\"\n              port: 8080\n            initialDelaySeconds: 90\n            periodSeconds: 10\n            timeoutSeconds: 5\n            failureThreshold: 5\n          readinessProbe:\n            httpGet:\n              path: \"\/login\"\n              port: 8080\n            initialDelaySeconds: 60\n            periodSeconds: 10\n            timeoutSeconds: 5\n            failureThreshold: 3\n          volumeMounts:\n            - name: jenkins-data\n              mountPath: \/var\/jenkins_home         \n      volumes:\n        - name: jenkins-data\n          persistentVolumeClaim:\n              claimName: jenkins-pv-claim\n\n# Service Config\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: jenkins-service\n  annotations:\n      prometheus.io\/scrape: 'true'\n      prometheus.io\/path:   \/\n      prometheus.io\/port:   '8080'\nspec:\n  selector: \n    app: jenkins\n  type: NodePort  \n  ports:\n    - port: 8080\n      targetPort: 8080\n      nodePort: 32000<\/code><\/pre>\n
              Create the deployment.<\/p>\n
              kubectl apply -f jenkins.yaml<\/code><\/pre>\n
              Once the deployment is up and running, you will be able to access the Jenkins server on any of the Node port 32000<\/code><\/p>\n
              Conclusion<\/h2>\n
              We have see how to setup persistent volume on a GKE cluster with few examples using pods and deployments.<\/p>\n
              Hope this article helps.<\/p>\n
              Let me know in the comment section, if you face any issues,<\/p>\n
              \n
              Ngu\u1ed3n:<\/strong> How to Add Persistent Volume in Google Kubernetes Engine \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
              Source: https:\/\/devopscube.com\/persistent-volume-google-kubernetes-engine\/<\/p>\n","protected":false},"author":1,"featured_media":591,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-590","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/590","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=590"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/590\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/591"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}