Introduction to Volume and volumeMounts

In this part of our Kubernetes 101 series, we will bring persistence into play. You will learn how to provide persistent storage in the form of different volumes to the Pods. This allows containers within the Pods or other distributed instances in the cluster to have access to the same data by mounting the created volume inside a container.

The topics below will be covered as well as hands-on practice to show you a real-time scenario on how these components work:

  • Definitions of  Volumes and volumeMount
  • What types of Volumes are available?
  • How to use simple Volumes and volumeMount inside a Pod
  • Hands-on practice

This document applies to the HEAD of the source tree

If you are using a released version of Kubernetes, you should
refer to the docs that go with that version.

Documentation for other releases can be found at
releases. k8s.

Familiarity with pods is suggested.

Table of Contents

Background

Docker also has a concept of
volumes, though it is
somewhat looser and less managed. In Docker, a volume is simply a directory on
disk or in another container. Lifetimes are not managed and until very
recently there were only local-disk-backed volumes. Docker now provides volume
drivers, but the functionality is very limited for now (e.g. as of Docker 1.7
only one volume driver is allowed per container and there is no way to pass
parameters to volumes).

A Kubernetes volume, on the other hand, has an explicit lifetime — the same as
the pod that encloses it. Consequently, a volume outlives any containers that run
within the Pod, and data is preserved across Container restarts. Of course, when a
Pod ceases to exist, the volume will cease to exist, too. Perhaps more
importantly than this, Kubernetes supports many type of volumes, and a Pod can
use any number of them simultaneously.

At its core, a volume is just a directory, possibly with some data in it, which
is accessible to the containers in a pod. How that directory comes to be, the
medium that backs it, and the contents of it are determined by the particular
volume type used.

To use a volume, a pod specifies what volumes to provide for the pod (the
spec.volumes
field) and where to mount those into containers(the
spec.containers.volumeMounts
field).

A process in a container sees a filesystem view composed from their Docker
image and volumes. The Docker
image is at the root of the
filesystem hierarchy, and any volumes are mounted at the specified paths within
the image. Volumes can not mount onto other volumes or have hard links to
other volumes. Each container in the Pod must independently specify where to
mount each volume.

Types of Volumes

Kubernetes supports several types of Volumes:

  • emptyDir
  • hostPath
  • gcePersistentDisk
  • nfs
  • iscsi
  • flocker
  • glusterfs
  • rbd
  • gitRepo
  • secret
  • persistentVolumeClaim
  • downwardAPI

We welcome additional contributions.

EmptyDir

An emptyDir volume is first created when a Pod is assigned to a Node, and
exists as long as that Pod is running on that node. As the name says, it is
initially empty. Containers in the pod can all read and write the same
files in the emptyDir volume, though that volume can be mounted at the same
or different paths in each container. When a Pod is removed from a node for
any reason, the data in the emptyDir is deleted forever. NOTE: a container
crashing does NOT remove a pod from a node, so the data in an emptyDir
volume is safe across container crashes.

Some uses for an emptyDir are:

  • scratch space, such as for a disk-based mergesortcw
  • checkpointing a long computation for recovery from crashes
  • holding files that a content-manager container fetches while a webserver
    container serves the data

By default, emptyDir volumes are stored on whatever medium is backing the
machine — that might be disk or SSD or network storage, depending on your
environment. However, you can set the emptyDir.medium field to «Memory»
to tell Kubernetes to mount a tmpfs (RAM-backed filesystem) for you instead.
While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on
machine reboot and any files you write will count against your container’s
memory limit.

Читайте также:  «Невозможно записать внутри пути среды TEMP».

HostPath

A hostPath volume mounts a file or directory from the host node’s filesystem
into your pod. This is not something that most Pods will need, but it offers a
powerful escape hatch for some applications.

For example, some uses for a hostPath are:

  • running a container that needs access to Docker internals; use a hostPath
    of /var/lib/docker
  • running cAdvisor in a container; use a hostPath of /dev/cgroups

Watch out when using this type of volume, because:

  • pods with identical configuration (such as created from a podTemplate) may
    behave differently on different nodes due to different files on the nodes
  • when Kubernetes adds resource-aware scheduling, as is planned, it will not be
    able to account for resources used by a hostPath

GcePersistentDisk

A gcePersistentDisk volume mounts a Google Compute Engine (GCE) Persistent
Disk into your pod. Unlike
emptyDir, which is erased when a Pod is removed, the contents of a PD are
preserved and the volume is merely unmounted. This means that a PD can be
pre-populated with data, and that data can be «handed off» between pods.

Important: You must create a PD using gcloud or the GCE API or UI
before you can use it

There are some restrictions when using a gcePersistentDisk:

  • the nodes on which pods are running must be GCE VMs
  • those VMs need to be in the same GCE project and zone as the PD

A feature of PD is that they can be mounted as read-only by multiple consumers
simultaneously. This means that you can pre-populate a PD with your dataset
and then serve it in parallel from as many pods as you need. Unfortunately,
PDs can only be mounted by a single consumer in read-write mode — no
simultaneous writers allowed.

Using a PD on a pod controlled by a ReplicationController will fail unless
the PD is read-only or the replica count is 0 or 1.

Creating a PD

Before you can use a GCE PD with a pod, you need to create it.

gcloud compute disks create —size=500GB —zone=us-central1-a my-data-disk

Example pod

:
:
:
:
:
:
— :
:
:
— :
:
:
— :
This GCE PD must already exist.
:
:
:

AwsElasticBlockStore

Important: You must create an EBS volume using aws ec2 create-volume or
the AWS API before you can use it

  • the nodes on which pods are running must be AWS EC2 instances
  • those instances need to be in the same region and availability-zone as the EBS volume
  • EBS only supports a single EC2 instance mounting a volume

Creating an EBS volume

Before you can use a EBS volume with a pod, you need to create it.

aws ec2 create-volume —availability-zone eu-west-1a —size 10 —volume-type gp2

Make sure the zone matches the zone you brought up your cluster in. (And also check that the size and EBS volume
type are suitable for your use!)

AWS EBS Example configuration

:
:
:
:
:
:
— :
:
:
— :
:
:
— :
This AWS EBS volume must already exist.
:
:
:

(Note: the syntax of volumeID is currently awkward; #10181 fixes it)

Nfs

An iscsi volume allows an existing iSCSI (SCSI over IP) volume to be mounted
into your pod. Unlike emptyDir, which is erased when a Pod is removed, the
contents of an iscsi volume are preserved and the volume is merely
unmounted. This means that an iscsi volume can be pre-populated with data, and
that data can be «handed off» between pods.

Important: You must have your own iSCSI server running with the volume
created before you can use it

A feature of iSCSI is that it can be mounted as read-only by multiple consumers
simultaneously. This means that you can pre-populate a volume with your dataset
and then serve it in parallel from as many pods as you need. Unfortunately,
iSCSI volumes can only be mounted by a single consumer in read-write mode — no
simultaneous writers allowed.

Flocker

Flocker is an open-source clustered container data volume manager. It provides management
and orchestration of data volumes backed by a variety of storage backends.

A flocker volume allows a Flocker dataset to be mounted into a pod. If the
dataset does not already exist in Flocker, it needs to be created with Flocker
CLI or the using the Flocker API. If the dataset already exists it will
reattached by Flocker to the node that the pod is scheduled. This means data
can be «handed off» between pods as required.

Important: You must have your own Flocker installation running before you can use it

Читайте также:  Объяснение важности индексных страниц сайта

Glusterfs

A glusterfs volume allows a Glusterfs (an open
source networked filesystem) volume to be mounted into your pod. Unlike
emptyDir, which is erased when a Pod is removed, the contents of a
glusterfs volume are preserved and the volume is merely unmounted. This
means that a glusterfs volume can be pre-populated with data, and that data can
be «handed off» between pods. GlusterFS can be mounted by multiple writers
simultaneously.

Important: You must have your own GlusterFS installation running before you
can use it

Rbd

Important: You must have your own Ceph installation running before you
can use RBD

A feature of RBD is that it can be mounted as read-only by multiple consumers
simultaneously. This means that you can pre-populate a volume with your dataset
and then serve it in parallel from as many pods as you need. Unfortunately,
RBD volumes can only be mounted by a single consumer in read-write mode — no
simultaneous writers allowed.

GitRepo

A gitRepo volume is an example of what can be done as a volume plugin. It
mounts an empty directory and clones a git repository into it for your pod to
use. In the future, such volumes may be moved to an even more decoupled model,
rather than extending the Kubernetes API for every such use case.

Here is a example for gitRepo volume:

:
:
:
:
:
:
— :
:
:
— :
:
:
— :
:
:
:

Secret

A secret volume is used to pass sensitive information, such as passwords, to
pods. You can store secrets in the Kubernetes API and mount them as files for
use by pods without coupling to Kubernetes directly. secret volumes are
backed by tmpfs (a RAM-backed filesystem) so they are never written to
non-volatile storage.

Important: You must create a secret in the Kubernetes API before you can use
it

Secrets are described in more detail here.

PersistentVolumeClaim

A downwardAPI volume is used to make downward API data available to applications.
It mounts a directory and writes the requested data in plain text files.

Resources

The storage media (Disk, SSD, etc) of an emptyDir volume is determined by the
medium of the filesystem holding the kubelet root dir (typically
/var/lib/kubelet). There is no limit on how much space an emptyDir or
hostPath volume can consume, and no isolation between containers or between
pods.

In the future, we expect that emptyDir and hostPath volumes will be able to
request a certain amount of space using a resource
specification, and to select the type of media to use, for clusters that have
several media types.

One of the advantages of hostPath volume over EmptyDir is the ability to outlive the Pod lifecycle. We want to show you the practical steps of this scenario by deleting the Pod and then ssh into the Node once again to check the file and the data.

Step 1: Delete the Pod using kubectl delete command:

$ kubectl delete pod myapp
pod deleted

Step 2: Check the status of the Pod:

$ kubectl get pod
No resources found in default namespace.

Step 3: Now that the Pod has been deleted, ssh into the Node and perform step 8 and 9.

You can see that the data stored in a file which was initially created in a Pod remains intact and can be accessed through the Node even when the Pod has been deleted. This affirms the ability of hostPath volume type to outlive the lifecycle of a Pod.

Now that you have seen and practiced how to create a volume using emptyDir and hostPath volume types, and mount the volume into a container in a Pod , we are going to look at  Secret and ConfigMap which are ephemeral volume types in our next blog post. What is a Kubernetes Secret and configMap? What are their similarities, differences and functionalities? These and many more questions will be our focus in the next parts of this series.

Volume Types Category

Volume types are classified into two categories:

Learn More

A Volume in Kubernetes represents a directory with data that is accessible across multiple containers in a Pod. The container data in a Pod is deleted or lost when a container crashes or restarts, but when you use a volume, the new container can pick up the data at the state before the container crashes. The volume outlives the containers in a Pod and can be consumed by any number of containers within that Pod.

A volumeMount, on the other hand, entails mounting of the declared volume into a container in the same Pod. A “volumeMounts” property (spec.container.volumeMounts), as well as the “name” property which is the volume name to be mounted and the mountPath field where the volume will be mounted, are declared in the container in a Pod. The configuration will look like this:

Читайте также:  Полное руководство: управление компьютером с другого устройства

Volume and volumeMounts go hand in hand. You can not create a volume without mounting it or mount a volume that has not been created.

Below is a configuration example of a volume declaration in a Pod and mounting of the declared volume in a container:

NOTE: It is vital that the name of the volume to be mounted in the container under the volumeMounts.name property is the same as the name of the volume.

EmptyDir Volume Type

An emptyDir volume is a volume type that is first created when a Pod is assigned to a Node. Its lifespan is dependent on the lifecycle of the Pod on that Node but recreates when the containers crash or restart. When a Pod dies, crashes, or is removed from a Node, the data in the emptyDir volume is deleted and lost. This type of volume is suitable for temporary data storage.

How to Create an emptyDir Volume

The steps below will walk you through how to create a Pod that uses emptyDir volume type.

Step 1: Create a Pod with the below manifest file:

Step 2: Create the Pod using kubectl create command:

$ kubectl create -f emptyDir.yaml
pod/myapp created

Step 3: Check the status of the Pod to see if it is running:

$ kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp 1/1 Running 15s

Step 5: Exec into the Pod and perform some basic commands:

Step 6: Check the volume in the directory for existing data. In this case, it should be empty.

Step 7: Create a file and write some data into it:

Step 8: Check to see if the data is stored:

Now that you can see that it is stored, display the content of the data using the below command:

$ cat app/new-file
I love Kubermatic

Step 9: Exit the Pod and perform a clean up by deleting the Pod using kubectl delete command:

HostPath Volume Type

hostPath volume type is a durable volume type that mounts a directory from the host Node’s filesystem into a Pod. The file in the volume remains intact even if the Pod crashes, is terminated or is deleted. It is important that the directory and the Pod are created or scheduled on the same Node.

The below manifest represents a hostPath configuration inside a Pod:

— # The name of the volume

# directory location on host

How to Create and use a hostPath Volume in a Pod

You can create a hostPath volume and just like the emptyDir volume type. However, the volume type name, hostPath, will replace the emptyDir in the Pod manifest file. You will also declare a path property which is the directory location on the host and a child of hostPath property. The complete configuration will look like this:

Now that the manifest file is ready, the below steps will guide you on how to create a hostPath volume and mount it into a Pod; after that, we will test the functionalities.

Step 1: Create a Pod with the manifest file above:

$ kubectl create -f hostpath-volume.yaml
pod/myapp created

Step 2: Check the status of the Pod using kubectl get command:

get pod
NAME READY STATUS RESTARTS AGE
myapp 1/1 Running 10m

Step 3: Exec into the Pod and create a file in the directory:

Step 4: Change to the /app directory:

Step 6: Check to see if the data is created and stored in the file:

Now, ssh into the Node to check if the data created in the /app directory in the Pod can be found in the /mnt/vpath in the Node.

Change to the /mnt/vpath directory, which is the value of the hostpath path in the YAML manifest file.

Step 9: Check to confirm if the file and data created in the Pod above are available in the directory:

Now, create another file and store some data in the file inside the Node. Exit the Node and login into the Pod using kubectl exec. Then perform Step 6 once again to view the file and data created in the Node directly in the Pod and exit.

NOTE: The Pod must be running in the same Node.

Оцените статью
Хостинги