Volumes - Kubernetes - 0 views
-
On-disk files in a Container are ephemeral,
-
when a Container crashes, kubelet will restart it, but the files will be lost - the Container starts with a clean state
-
In Docker, a volume is simply a directory on disk or in another Container.
- ...105 more annotations...
-
A Kubernetes volume, on the other hand, has an explicit lifetime - the same as the Pod that encloses it.
-
a volume outlives any Containers that run within the Pod, and data is preserved across Container restarts.
-
-
Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously.
-
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.
-
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
-
localnfs
-
cephfs
-
awsElasticBlockStore
-
glusterfs
-
vsphereVolume
-
An awsElasticBlockStore volume mounts an Amazon Web Services (AWS) EBS Volume into your Pod.
-
the contents of an EBS volume are preserved and the volume is merely unmounted.
-
an EBS volume can be pre-populated with data, and that data can be “handed off” between Pods.
-
create an EBS volume using aws ec2 create-volume
-
the nodes on which Pods are running must be AWS EC2 instances
-
EBS only supports a single EC2 instance mounting a volume
-
check that the size and EBS volume type are suitable for your use!
-
A cephfs volume allows an existing CephFS volume to be mounted into your Pod.
-
the contents of a cephfs volume are preserved and the volume is merely unmounted.
-
-
CephFS can be mounted by multiple writers simultaneously.
-
have your own Ceph server running with the share exported
-
configMap
-
The configMap resource provides a way to inject configuration data into Pods
-
When referencing a configMap object, you can simply provide its name in the volume to reference it
-
volumeMounts: - name: config-vol mountPath: /etc/config volumes: - name: config-vol configMap: name: log-config items: - key: log_level path: log_level
-
create a ConfigMap before you can use it.
-
A Container using a ConfigMap as a subPath volume mount will not receive ConfigMap updates.
-
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.
-
When a Pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
-
By default, emptyDir volumes are stored on whatever medium is backing the node - that might be disk or SSD or network storage, depending on your environment.
-
you can set the emptyDir.medium field to "Memory" to tell Kubernetes to mount a tmpfs (RAM-backed filesystem)
-
volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}
-
An fc volume allows an existing fibre channel volume to be mounted in a Pod.
-
configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
-
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.
-
emptyDir
-
flocker
-
A flocker volume allows a Flocker dataset to be mounted into a Pod
-
have your own Flocker installation running
-
A gcePersistentDisk volume mounts a Google Compute Engine (GCE) Persistent Disk into your Pod.
-
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
-
A glusterfs volume allows a Glusterfs (an open source networked filesystem) volume to be mounted into your Pod.
-
have your own GlusterFS installation running
-
A hostPath volume mounts a file or directory from the host node’s filesystem into your Pod.
-
a powerful escape hatch for some applications
-
access to Docker internals; use a hostPath of /var/lib/docker
-
allowing a Pod to specify whether a given hostPath should exist prior to the Pod running, whether it should be created, and what it should exist as
-
specify a type for a hostPath volume
-
the files or directories created on the underlying hosts are only writable by root.
-
hostPath: # directory location on host path: /data # this field is optional type: Directory
-
An iscsi volume allows an existing iSCSI (SCSI over IP) volume to be mounted into your Pod.
-
have your own iSCSI server running
-
A feature of iSCSI is that it can be mounted as read-only by multiple consumers simultaneously.
-
A local volume represents a mounted local storage device such as a disk, partition or directory.
-
Local volumes can only be used as a statically created PersistentVolume.
-
Compared to hostPath volumes, local volumes can be used in a durable and portable manner without manually scheduling Pods to nodes, as the system is aware of the volume’s node constraints by looking at the node affinity on the PersistentVolume.
-
If a node becomes unhealthy, then the local volume will also become inaccessible, and a Pod using it will not be able to run.
-
PersistentVolume spec using a local volume and nodeAffinity
-
PersistentVolume nodeAffinity is required when using local volumes. It enables the Kubernetes scheduler to correctly schedule Pods using local volumes to the correct node.
-
PersistentVolume volumeMode can now be set to “Block” (instead of the default value “Filesystem”) to expose the local volume as a raw block device.
-
When using local volumes, it is recommended to create a StorageClass with volumeBindingMode set to WaitForFirstConsumer
-
An nfs volume allows an existing NFS (Network File System) share to be mounted into your Pod.
-
NFS can be mounted by multiple writers simultaneously.
-
have your own NFS server running with the share exported
-
A persistentVolumeClaim volume is used to mount a PersistentVolume into a Pod.
-
PersistentVolumes are a way for users to “claim” durable storage (such as a GCE PersistentDisk or an iSCSI volume) without knowing the details of the particular cloud environment.
-
A projected volume maps several existing volume sources into the same directory.
-
All sources are required to be in the same namespace as the Pod. For more details, see the all-in-one volume design document.
-
Each projected volume source is listed in the spec under sources
-
A Container using a projected volume source as a subPath volume mount will not receive updates for those volume sources.
-
RBD volumes can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed
-
A secret volume is used to pass sensitive information, such as passwords, to Pods
-
store secrets in the Kubernetes API and mount them as files for use by Pods
-
secret volumes are backed by tmpfs (a RAM-backed filesystem) so they are never written to non-volatile storage.
-
create a secret in the Kubernetes API before you can use it
-
A Container using a Secret as a subPath volume mount will not receive Secret updates.
-
StorageOS runs as a Container within your Kubernetes environment, making local or attached storage accessible from any node within the Kubernetes cluster.
-
Data can be replicated to protect against node failure. Thin provisioning and compression can improve utilization and reduce cost.
-
StorageOS provides block storage to Containers, accessible via a file system.
-
A vsphereVolume is used to mount a vSphere VMDK Volume into your Pod.
-
supports both VMFS and VSAN datastore.
-
create VMDK using one of the following methods before using with Pod.
-
share one volume for multiple uses in a single Pod.
-
The volumeMounts.subPath property can be used to specify a sub-path inside the referenced volume instead of its root.
-
volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME)
-
env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name
-
Use the subPathExpr field to construct subPath directory names from Downward API environment variables
-
enable the VolumeSubpathEnvExpansion feature gate
-
The subPath and subPathExpr properties are mutually exclusive.
-
There is no limit on how much space an emptyDir or hostPath volume can consume, and no isolation between Containers or between Pods.
-
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.
-
the Container Storage Interface (CSI) and Flexvolume. They enable storage vendors to create custom storage plugins without adding them to the Kubernetes repository.
-
all volume plugins (like volume types listed above) were “in-tree” meaning they were built, linked, compiled, and shipped with the core Kubernetes binaries and extend the core Kubernetes API.
-
Container Storage Interface (CSI) defines a standard interface for container orchestration systems (like Kubernetes) to expose arbitrary storage systems to their container workloads.
-
Once a CSI compatible volume driver is deployed on a Kubernetes cluster, users may use the csi volume type to attach, mount, etc. the volumes exposed by the CSI driver.
-
The csi volume type does not support direct reference from Pod and may only be referenced in a Pod via a PersistentVolumeClaim object.
-
This feature requires CSIInlineVolume feature gate to be enabled:--feature-gates=CSIInlineVolume=true
-
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented are listed in the “Types of Volumes” section above.
-
Mount propagation allows for sharing volumes mounted by a Container to other Containers in the same Pod, or even to other Pods on the same node.
-
Mount propagation of a volume is controlled by mountPropagation field in Container.volumeMounts.
-
HostToContainer - This volume mount will receive all subsequent mounts that are mounted to this volume or any of its subdirectories.
-
Bidirectional - This volume mount behaves the same the HostToContainer mount. In addition, all volume mounts created by the Container will be propagated back to the host and to all Containers of all Pods that use the same volume.
-
Edit your Docker’s systemd service file. Set MountFlags as follows:MountFlags=shared
