storage

Docker Storage

When we install docker: /var/lib/docker aufs containers image volume

Docker layered architecture

• layers are reused
• Only new built layer is downloaded
• saving time
• One of them is the container layer which has read/write access, rest are read-only.
• The container layer exists as long as the container exists. Once the container is deleted, all changes made are gone.
• Copy-on-write mechanism: When changes are required by the application, the source code is copied from the image layer to the container layer and changes are made there.

Volume Mounting:

• To keep the changes persist even after the container is destroyed, we need persistent volume.

/var/lib/docker aufs containers image volume data_volume //creating apersistent volume for docker //docker volume create data_volume //mounting volume to the docker container //docker run -v data_volume:/var/lib/mysql mysql //This will create a mysql instance in read-write container layer. //Even after the container is destroyed, the data will be preserved and when a new instance is created, the old changes will reflect in the new container.

Bind mounting: //In case the data is present already in some other location on docker host, we can mount it using: //docker run -v /data/mysql:/var/lib/mysql mysql

NOTE: use mount option instead of -v.

//docker run –mount type=bind,source=/data/mysql,target=/var/lib/mysql mysql

This copying of data is done using Strorage drivers. SOme of the examples are:

• AUFS
• ZFS
• BTRFS
• Device Mapper
• Overlay
• Overlay2

  Volume Drivers

• Local
• Azure File Storage
• Convoy
• DigitalOcean Block Storage
• Flocker
• gce-docker
• GlusterFS
• NetApp
• RexRaY
• Portworx
• VMware vSphere Storage

These support different storage providers.

One can choose which volume driver to be used while running a container. //docker run -it –name mysql –volume-driver rexray/ebs –mount src=ebs-vol,target=/var/lib/mysql mysql //This will create a volume and attack the container from AWS EBS cloud.

Container Storage Interface: It is a universal standard and drivers are available.

Persistent Volume Claim: Is a cluster-wide pool of storage volumes configured by an administrator to be used by users to deploy applications on the cluster.

//persistent-volume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv-vol1
spec:
    accesModes:
        - ReadWriteOnce
    capacity:
        storage: 1Gi
    hostPath:
        path: /tmp/data
//kubectl create -f persistent-volume.yaml
//kubectl get persistentvolume 

//using PVC in pod
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Storage Class

With storage class one can define a provisioner such as GCP that can automatically provision storage on the cloud and attach to that pod when the claim is made. This is called dynamic provisioning of volumes.

stprage-class-yaml


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: google-storage
provisioner: kubernetes.io/gce-pd

PV is not required in case a storage class is used. We directly can use PVC ny passing in the spec.storageClassName PV is created automatically by the storage class.