The spec section features a few interesting details.

Line 8: We set manual-ebs as the storage class name. We’ll see later what its function is. For now, just remember the name.

Line 9-10: We defined that the storage capacity is 5Gi. It does not need to be the same as the capacity of the EBS we created earlier, as long as it is not bigger. Kubernetes will try to match PersistentVolume with, in this case, EBS that has a similar, if not the same capacity. Since we have only one EBS volume with 10GB, it is the closest (and the only) match to the PersistentVolume request of 5Gi. Ideally, persistent volumes capacity should match EBS size, but we wanted to demonstrate that any value equal to or less then the actual size should do.

Line 11-12: We specified that the access mode should be ReadWriteOnce. That means that we’ll be able to mount the volume as read-write only once. Only one Pod will be able to use it at any given moment. Such a strategy fits us well since EBS cannot be mounted to multiple instances. Our choice of the access mode is not truly a choice, but more an acknowledgment of the way how EBS works. The alternative modes are ReadOnlyMany and ReadWriteMany. Both modes would result in volumes that could be mounted to multiple Pods, either as read-only or read-write. Those modes would be more suitable for NFS like, for example, EFS, which can be mounted by multiple instances.

Line 13-15: The spec fields we explored so far are common to all persistent volume types. Besides those, there are entries specific to the actual volume we are associating with a Kubernetes PersistentVolume. Since we’re going to use EBS, we specified awsElasticBlockStore with the volume ID and file system type. Since we could not know in advance what will be the ID of your EBS volume, the definition has the value set to REPLACE_ME. Later on, we’ll replace it with the ID of the EBS we created earlier.