From 8fcea2d268b8a8e558fefce4ec4f32328f03304f Mon Sep 17 00:00:00 2001 From: AdamDang Date: Sat, 12 May 2018 02:53:29 +0800 Subject: [PATCH] Typo fix: formated->formatted and proper noun in capital (#8332) * Typo fix: formated->formatted and proper noun in capital formated->formatted Pod and Container are proper noun, in this doc, someplace are in capital, some are in lowercase. It's better to keep consistency. * Update volumes.md --- content/en/docs/concepts/storage/volumes.md | 182 ++++++++++---------- 1 file changed, 91 insertions(+), 91 deletions(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 38b49204d5..3b8476ef24 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -10,14 +10,14 @@ content_template: templates/concept {{% capture overview %}} -On-disk files in a container are ephemeral, which presents some problems for -non-trivial applications when running in containers. First, when a container +On-disk files in a Container are ephemeral, which presents some problems for +non-trivial applications when running in Containers. First, when a Container crashes, kubelet will restart it, but the files will be lost - the -container starts with a clean state. Second, when running containers together -in a `Pod` it is often necessary to share files between those containers. The +Container starts with a clean state. Second, when running Containers together +in a `Pod` it is often necessary to share files between those Containers. The Kubernetes `Volume` abstraction solves both of these problems. -Familiarity with [pods](/docs/user-guide/pods) is suggested. +Familiarity with [Pods](/docs/user-guide/pods) is suggested. {{% /capture %}} @@ -30,27 +30,27 @@ Familiarity with [pods](/docs/user-guide/pods) is suggested. Docker also has a concept of [volumes](https://docs.docker.com/engine/admin/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 +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 +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 +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 types 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 +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 +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 +field) and where to mount those into Containers (the `spec.containers.volumeMounts` field). @@ -59,7 +59,7 @@ image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/) 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 +other volumes. Each Container in the Pod must independently specify where to mount each volume. ## Types of Volumes @@ -98,11 +98,11 @@ We welcome additional contributions. ### awsElasticBlockStore An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS) [EBS -Volume](http://aws.amazon.com/ebs/) into your pod. Unlike +Volume](http://aws.amazon.com/ebs/) into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of an EBS volume are preserved and the volume is merely unmounted. This means that an EBS volume can be pre-populated with data, and that data can be "handed off" -between pods. +between Pods. {{< caution >}} **Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it. @@ -110,13 +110,13 @@ between pods. There are some restrictions when using an `awsElasticBlockStore` volume: -* the nodes on which pods are running must be AWS EC2 instances +* 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 an EBS volume with a pod, you need to create it. +Before you can use an EBS volume with a Pod, you need to create it. ```shell aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 @@ -163,10 +163,10 @@ More details can be found [here](https://github.com/kubernetes/examples/tree/{{< ### cephfs A `cephfs` volume allows an existing CephFS volume to be -mounted into your pod. Unlike `emptyDir`, which is erased when a Pod is +mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `cephfs` volume are preserved and the volume is merely unmounted. This means that a CephFS volume can be pre-populated with data, and -that data can be "handed off" between pods. CephFS can be mounted by multiple +that data can be "handed off" between Pods. CephFS can be mounted by multiple writers simultaneously. {{< caution >}} @@ -219,7 +219,7 @@ keyed with `log_level`. {{< /caution >}} {{< note >}} -**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not +**Note:** A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not receive ConfigMap updates. {{< /note >}} @@ -229,7 +229,7 @@ A `downwardAPI` volume is used to make downward API data available to applicatio It mounts a directory and writes the requested data in plain text files. {{< note >}} -**Note:** A container using Downward API as a [subPath](#using-subpath) volume mount will not +**Note:** A Container using Downward API as a [subPath](#using-subpath) volume mount will not receive Downward API updates. {{< /note >}} @@ -239,31 +239,31 @@ See the [`downwardAPI` volume example](/docs/tasks/inject-data-application/downw 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 +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 +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 >}} -**Note:** a container crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes. +**Note:** a Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes. {{< /note >}} Some uses for an `emptyDir` are: * scratch space, such as for a disk-based merge sort * checkpointing a long computation for recovery from crashes -* holding files that a content-manager container fetches while a webserver - container serves the data +* 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 node - 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 -node reboot and any files you write will count against your container's +node reboot and any files you write will count against your Container's memory limit. -#### Example pod +#### Example Pod ```yaml apiVersion: v1 @@ -284,7 +284,7 @@ spec: ### fc (fibre channel) -An `fc` volume allows an existing fibre channel volume to be mounted in a pod. +An `fc` volume allows an existing fibre channel volume to be mounted in a Pod. You can specify single or multiple target World Wide Names using the parameter `targetWWNs` in your volume configuration. If multiple WWNs are specified, targetWWNs expect that those WWNs are from multi-path connections. @@ -297,14 +297,14 @@ See the [FC example](https://github.com/kubernetes/examples/tree/{{< param "gith ### flocker -[Flocker](https://github.com/ClusterHQ/flocker) is an open-source clustered container data volume manager. It provides management +[Flocker](https://github.com/ClusterHQ/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 +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 first created with the Flocker CLI or by using the Flocker API. If the dataset already exists it will be -reattached by Flocker to the node that the pod is scheduled. This means data -can be "handed off" between pods as required. +reattached by Flocker to the node that the Pod is scheduled. This means data +can be "handed off" between Pods as required. {{< caution >}} **Important:** You must have your own Flocker installation running before you can use it. @@ -315,10 +315,10 @@ See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param ### gcePersistentDisk A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) [Persistent -Disk](http://cloud.google.com/compute/docs/disks) into your pod. Unlike +Disk](http://cloud.google.com/compute/docs/disks) 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. +pre-populated with data, and that data can be "handed off" between Pods. {{< caution >}} **Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it. @@ -326,27 +326,27 @@ pre-populated with data, and that data can be "handed off" between pods. There are some restrictions when using a `gcePersistentDisk`: -* the nodes on which pods are running must be GCE VMs +* 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, +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 +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. +Before you can use a GCE PD with a Pod, you need to create it. ```shell gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk ``` -#### Example pod +#### Example Pod ```yaml apiVersion: v1 @@ -371,7 +371,7 @@ spec: ### 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 +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. @@ -399,11 +399,11 @@ spec: ### glusterfs A `glusterfs` volume allows a [Glusterfs](http://www.gluster.org) (an open -source networked filesystem) volume to be mounted into your pod. Unlike +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 +be "handed off" between Pods. GlusterFS can be mounted by multiple writers simultaneously. {{< caution >}} @@ -415,16 +415,16 @@ See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< para ### 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 +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` +* 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 `/sys` -* 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 +* running cAdvisor in a Container; use a `hostPath` of `/sys` +* 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 In addition to the required `path` property, user can optionally specify a `type` for a `hostPath` volume. @@ -444,16 +444,16 @@ The supported values for field `type` are: Watch out when using this type of volume, because: -* pods with identical configuration (such as created from a podTemplate) may +* 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` * the files or directories created on the underlying hosts are only writable by root. You either need to run your process as root in a - [privileged container](/docs/user-guide/security-context) or modify the file + [privileged Container](/docs/user-guide/security-context) or modify the file permissions on the host to be able to write to a `hostPath` volume -#### Example pod +#### Example Pod ```yaml apiVersion: v1 @@ -479,10 +479,10 @@ spec: ### iscsi 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 +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. +that data can be "handed off" between Pods. {{< caution >}} **Important:** You must have your own iSCSI server running with the volume created before you can use it. @@ -490,7 +490,7 @@ that data can be "handed off" between pods. 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, +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. @@ -514,12 +514,12 @@ Local volumes can only be used as a statically created PersistentVolume. Dynamic provisioning is not supported yet. 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 +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. However, local volumes are still subject to the availability of the underlying node and are not suitable for all applications. If a node becomes unhealthy, -then the local volume will also become inaccessible, and a pod using it will not +then the local volume will also become inaccessible, and a Pod using it will not be able to run. Applications using local volumes must be able to tolerate this reduced availability, as well as potential data loss, depending on the durability characteristics of the underlying disk. @@ -554,7 +554,7 @@ spec: ``` PersistentVolume `nodeAffinity` is required when using local volumes. It enables -the Kubernetes scheduler to correctly schedule pods using local volumes to the +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 @@ -565,8 +565,8 @@ When using local volumes, it is recommended to create a StorageClass with `volumeBindingMode` set to `WaitForFirstConsumer`. See the [example](storage-classes.md#local). Delaying volume binding ensures that the PersistentVolumeClaim binding decision will also be evaluated with any -other node constraints the pod may have, such as node resource requirements, node -selectors, pod affinity, and pod anti-affinity. +other node constraints the Pod may have, such as node resource requirements, node +selectors, Pod affinity, and Pod anti-affinity. An external static provisioner can be run separately for improved management of the local volume lifecycle. Note that this provisioner does not support dynamic @@ -582,10 +582,10 @@ lifecycle. ### nfs An `nfs` volume allows an existing NFS (Network File System) share to be -mounted into your pod. Unlike `emptyDir`, which is erased when a Pod is +mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of an `nfs` volume are preserved and the volume is merely unmounted. This means that an NFS volume can be pre-populated with data, and -that data can be "handed off" between pods. NFS can be mounted by multiple +that data can be "handed off" between Pods. NFS can be mounted by multiple writers simultaneously. {{< caution >}} @@ -597,7 +597,7 @@ See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "git ### persistentVolumeClaim A `persistentVolumeClaim` volume is used to mount a -[PersistentVolume](/docs/concepts/storage/persistent-volumes/) into a pod. PersistentVolumes are a +[PersistentVolume](/docs/concepts/storage/persistent-volumes/) 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. @@ -614,9 +614,9 @@ Currently, the following types of volume sources can be projected: - [`downwardAPI`](#downwardapi) - `configMap` -All sources are required to be in the same namespace as the pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). +All sources are required to be in the same namespace as the Pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). -#### Example pod with a secret, a downward API, and a configmap. +#### Example Pod with a secret, a downward API, and a configmap. ```yaml apiVersion: v1 @@ -656,7 +656,7 @@ spec: path: my-group/my-config ``` -#### Example pod with multiple secrets with a non-default permission mode set. +#### Example Pod with multiple secrets with a non-default permission mode set. ```yaml apiVersion: v1 @@ -698,7 +698,7 @@ parameters are nearly the same with two exceptions: for each individual projection. {{< note >}} -**Note:** A container using a projected volume source as a [subPath](#using-subpath) volume mount will not +**Note:** A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not receive updates for those volume sources. {{< /note >}} @@ -710,8 +710,8 @@ and aggregates capacity across multiple servers. Portworx runs in-guest in virtu machines or on bare metal Linux nodes. A `portworxVolume` can be dynamically created through Kubernetes or it can also -be pre-provisioned and referenced inside a Kubernetes pod. -Here is an example pod referencing a pre-provisioned PortworxVolume: +be pre-provisioned and referenced inside a Kubernetes Pod. +Here is an example Pod referencing a pre-provisioned PortworxVolume: ```yaml apiVersion: v1 @@ -735,7 +735,7 @@ spec: {{< caution >}} **Important:** Make sure you have an existing PortworxVolume with name `pxvol` -before using it in the pod. +before using it in the Pod. {{< /caution >}} More details and examples can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). @@ -743,7 +743,7 @@ More details and examples can be found [here](https://github.com/kubernetes/exam ### quobyte A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to -be mounted into your pod. +be mounted into your Pod. {{< caution >}} **Important:** You must have your own Quobyte setup running with the volumes @@ -756,10 +756,10 @@ See the [Quobyte example](https://github.com/kubernetes/examples/tree/{{< param An `rbd` volume allows a [Rados Block Device](http://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your -pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of +Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `rbd` volume are preserved and the volume is merely unmounted. This means that a RBD volume can be pre-populated with data, and that data can -be "handed off" between pods. +be "handed off" between Pods. {{< caution >}} **Important:** You must have your own Ceph installation running before you can use RBD. @@ -767,7 +767,7 @@ be "handed off" between pods. 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, +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. @@ -777,7 +777,7 @@ See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "git ScaleIO is a software-based storage platform that can use existing hardware to create clusters of scalable shared block networked storage. The `scaleIO` volume -plugin allows deployed pods to access existing ScaleIO +plugin allows deployed Pods to access existing ScaleIO volumes (or it can dynamically provision new volumes for persistent volume claims, see [ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)). @@ -786,7 +786,7 @@ volumes (or it can dynamically provision new volumes for persistent volume claim running with the volumes created before you can use them. {{< /caution >}} -The following is an example pod configuration with ScaleIO: +The following is an example Pod configuration with ScaleIO: ```yaml apiVersion: v1 @@ -818,8 +818,8 @@ For further detail, please the see the [ScaleIO examples](https://github.com/kub ### 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 +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. @@ -828,7 +828,7 @@ non-volatile storage. {{< /caution >}} {{< note >}} -**Note:** A container using a Secret as a [subPath](#using-subpath) volume mount will not +**Note:** A Container using a Secret as a [subPath](#using-subpath) volume mount will not receive Secret updates. {{< /note >}} @@ -837,20 +837,20 @@ Secrets are described in more detail [here](/docs/user-guide/secrets). ### storageOS A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) -volume to be mounted into your pod. +volume to be mounted into your Pod. -StorageOS runs as a container within your Kubernetes environment, making local +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. -At its core, StorageOS provides block storage to containers, accessible via a file system. +At its core, StorageOS provides block storage to Containers, accessible via a file system. -The StorageOS container requires 64-bit Linux and has no additional dependencies. +The StorageOS Container requires 64-bit Linux and has no additional dependencies. A free developer license is available. {{< caution >}} -**Important:** You must run the StorageOS container on each node that wants to +**Important:** You must run the StorageOS Container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool. For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com). @@ -898,7 +898,7 @@ A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The con of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore. {{< caution >}} -**Important:** You must create VMDK using one of the following method before using with POD. +**Important:** You must create VMDK using one of the following method before using with Pod. {{< /caution >}} #### Creating a VMDK volume @@ -951,10 +951,10 @@ More examples can be found [here](https://github.com/kubernetes/examples/tree/ma ## Using subPath -Sometimes, it is useful to share one volume for multiple uses in a single pod. The `volumeMounts.subPath` +Sometimes, it is useful to 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. -Here is an example of a pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume. +Here is an example of a Pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume. The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder: ```yaml @@ -990,8 +990,8 @@ spec: 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. +`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](/docs/user-guide/compute-resources) @@ -1033,8 +1033,8 @@ 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. +The `csi` volume type does not support direct reference from Pod and may only be +referenced in a Pod via a `PersistentVolumeClaim` object. The following fields are available to storage administrators to configure a CSI persistent volume: @@ -1055,7 +1055,7 @@ persistent volume: `ControllerPublishVolumeRequest`. - `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used to specify the filesystem that should be used to mount the volume. If the - volume has not been formated and formating is supported, this value will be + volume has not been formatted and formating is supported, this value will be used to format the volume. If a value is not specified, `ext4` is assumed. This value is passed to the CSI driver via the `VolumeCapability` field of `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and @@ -1122,7 +1122,7 @@ Its values are: In other words, if the host mounts anything inside the volume mount, the Container will see it mounted there. - Similarly, if any pod with `Bidirectional` mount propagation to the same + Similarly, if any Pod with `Bidirectional` mount propagation to the same volume mounts anything there, the Container with `HostToContainer` mount propagation will see it.