![148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}](https://documents.yumpu.com/000/065/726/563/004114de54e45591c9e60ff7561f9a6a79b64780/3936726d307573422b67724e435173486158323441413d3d/7658304e483454323730722b496362757950733837773d3d.jpg?AWSAccessKeyId=AKIAICNEWSPSEKTJ5M3Q&Expires=1726574400&Signature=SUazWMcy40wQF%2B%2FNdeh7QWxgR4c%3D)
148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}
CHAPTER 6Using VolumesKubernetes pods are invariably associated with data, and the data can either be made integral to a Dockercontainer via its Docker image or decoupled from the Docker container.ProblemIf data (in on-disk files) is made integral to a Docker container, the following issues could result:Solution• The data is not persistent. The data is removed when a Docker container is restarted,which could also be due to a container crash.• The data is container-specific and cannot be shared with other containers as such.One of the principles of modular design is the Single Responsibility Principle (SRP). Kubernetes volumesimplement the SRP by decoupling the data from a container. A volume is just a directory with or withoutdata on some medium, which is different for different volume types. A volume is specified in a pod’s specand shared across different containers in the pod. A volume must be mounted in each container in a pod’sspec independently, although it may be mounted in the different containers at the same (or different)file/directory path. A container in a pod has access to the filesystem inherited from its Docker image andthe filesystem from a Kubernetes volume. A Docker image’s filesystem is still at the root of the filesystemhierarchy, and a volume can only be mounted on a directory path within the root filesystem. Since volumesprovide access to data outside a pod, volumes mounted in different pods are able to share the same datafrom the host or other external storage such as AWS EBS or a GitHub repository. Two types of volumeabstractions or plugins are available: Volume and PersistentVolume. While a Volume is coupled with a pod, aPersistentVolume is provisioned on the networked cluster and is independent of a pod. Figure 6-1 shows anexample of using an Amazon EBS Volume in a pod.© Deepak Vohra 2017D. Vohra, Kubernetes Management Design Patterns, DOI 10.1007/978-1-4842-2598-1_6135
Chapter 6 ■ Using VolumesPodDockerContainersAWSEBSVolumeVolume IDvol-62a59dc8volumeMounts:mountPath:/aws-ebs1volumeMounts:mountPath:/aws-ebs2spec:volumes:/awsElastic BlockStore:volumeID:”aws://us-east-1c/vol-62a59dc8”volumeMounts:mountPath:/aws-ebs1Figure 6-1. Using a volume in a podOverviewKubernetes volumes are storage units associated with pods. A volume can be shared by pod replicas ordedicated to a single pod. Several types of volumes are supported for different types of storage, such asAWS volume, GitHub repository, or directory on the host, to list a few. The different types of volumes aredescribed in Table 6-1.Table 6-1. Types of VolumesVolume TypeemptyDirhostPathgcePersistentDiskDescriptionA per-pod volume that is initially empty and shared by containers in a pod.Each container may mount the volume at the same or different path. Bydefault, the volume is stored on the medium backing the machine, whichcould be SSD or network storage. Alternatively, the medium could be set tomemory. When a pod is deleted the volume is deleted also, which meansthe volume is not persistent.Mounts a file or a directory form the host node’s file system into the pod.Writable by root only the volume data persists even if the pod is deleted. Allcontainers in the pod can access the volume. Designed for single node testonly and supported in a multi-node cluster.Mounts a Google Compute Engine Persistent Disk into a pod. The GCE PD’scontents are not deleted if a pod is deleted and the volume is unmounted.Supported only for nodes of type GCE VMs in the same GCE project.(continued)136
- Page 99 and 100: Chapter 3 ■ Kubernetes on Google
- Page 101 and 102: Chapter 3 ■ Kubernetes on Google
- Page 103 and 104: Chapter 3 ■ Kubernetes on Google
- Page 105 and 106: PART IIAdministration andConfigurat
- Page 107 and 108: Chapter 4 ■ Using Multiple ZonesS
- Page 109 and 110: Chapter 4 ■ Using Multiple ZonesF
- Page 111 and 112: Chapter 4 ■ Using Multiple ZonesF
- Page 113 and 114: Chapter 4 ■ Using Multiple ZonesA
- Page 115 and 116: Chapter 4 ■ Using Multiple ZonesF
- Page 117 and 118: Chapter 4 ■ Using Multiple ZonesR
- Page 119 and 120: Chapter 4 ■ Using Multiple ZonesF
- Page 121 and 122: Chapter 4 ■ Using Multiple ZonesF
- Page 123 and 124: Chapter 4 ■ Using Multiple ZonesL
- Page 125 and 126: Chapter 4 ■ Using Multiple ZonesF
- Page 127 and 128: Chapter 4 ■ Using Multiple ZonesI
- Page 129 and 130: Chapter 4 ■ Using Multiple ZonesC
- Page 131 and 132: Chapter 4 ■ Using Multiple ZonesA
- Page 133 and 134: Chapter 5 ■ Using the Tectonic Co
- Page 135 and 136: Chapter 5 ■ Using the Tectonic Co
- Page 137 and 138: Chapter 5 ■ Using the Tectonic Co
- Page 139 and 140: Chapter 5 ■ Using the Tectonic Co
- Page 141 and 142: Chapter 5 ■ Using the Tectonic Co
- Page 143 and 144: Chapter 5 ■ Using the Tectonic Co
- Page 145 and 146: Chapter 5 ■ Using the Tectonic Co
- Page 147 and 148: Chapter 5 ■ Using the Tectonic Co
- Page 149: Chapter 5 ■ Using the Tectonic Co
- Page 153 and 154: Chapter 6 ■ Using VolumesObtain t
- Page 155 and 156: Chapter 6 ■ Using VolumesFigure 6
- Page 157 and 158: Chapter 6 ■ Using VolumesThe prec
- Page 159 and 160: Chapter 6 ■ Using VolumesFigure 6
- Page 161 and 162: Chapter 6 ■ Using VolumesFigure 6
- Page 163 and 164: Chapter 6 ■ Using VolumesThe kube
- Page 165 and 166: Chapter 6 ■ Using Volumesvolumes:
- Page 167 and 168: Chapter 6 ■ Using VolumesChange d
- Page 169 and 170: Chapter 7 ■ Using ServicesAnother
- Page 171 and 172: Chapter 7 ■ Using ServicesCreatin
- Page 173 and 174: Chapter 7 ■ Using ServicesSimilar
- Page 175 and 176: Chapter 7 ■ Using ServicesList th
- Page 177 and 178: Chapter 7 ■ Using ServicesFigure
- Page 179 and 180: Chapter 7 ■ Using ServicesInvoke
- Page 181 and 182: Chapter 7 ■ Using ServicesFigure
- Page 183 and 184: Chapter 7 ■ Using ServicesFigure
- Page 185 and 186: Chapter 7 ■ Using ServicesIn addi
- Page 187 and 188: Chapter 8 ■ Using Rolling Updates
- Page 189 and 190: Chapter 8 ■ Using Rolling Updates
- Page 191 and 192: Chapter 8 ■ Using Rolling Updates
- Page 193 and 194: Chapter 8 ■ Using Rolling Updates
- Page 195 and 196: Chapter 8 ■ Using Rolling Updates
- Page 197 and 198: Chapter 8 ■ Using Rolling Updates
- Page 199 and 200: Chapter 8 ■ Using Rolling Updates
Chapter 6 ■ Using Volumes
Pod
Docker
Containers
AWS
EBS
Volume
Volume ID
vol-
62a59dc8
volumeMounts:
mountPath:
/aws-ebs1
volumeMounts:
mountPath:
/aws-ebs2
spec:
volumes:
/awsElastic BlockStore:
volumeID:”aws://us-
east-1c/vol-
62a59dc8”
volumeMounts:
mountPath:
/aws-ebs1
Figure 6-1. Using a volume in a pod
Overview
Kubernetes volumes are storage units associated with pods. A volume can be shared by pod replicas or
dedicated to a single pod. Several types of volumes are supported for different types of storage, such as
AWS volume, GitHub repository, or directory on the host, to list a few. The different types of volumes are
described in Table 6-1.
Table 6-1. Types of Volumes
Volume Type
emptyDir
hostPath
gcePersistentDisk
Description
A per-pod volume that is initially empty and shared by containers in a pod.
Each container may mount the volume at the same or different path. By
default, the volume is stored on the medium backing the machine, which
could be SSD or network storage. Alternatively, the medium could be set to
memory. When a pod is deleted the volume is deleted also, which means
the volume is not persistent.
Mounts a file or a directory form the host node’s file system into the pod.
Writable by root only the volume data persists even if the pod is deleted. All
containers in the pod can access the volume. Designed for single node test
only and supported in a multi-node cluster.
Mounts a Google Compute Engine Persistent Disk into a pod. The GCE PD’s
contents are not deleted if a pod is deleted and the volume is unmounted.
Supported only for nodes of type GCE VMs in the same GCE project.
(continued)
136
Change language