whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Typo fix: formated->formatted and proper noun in capital (#8332)

Browse Source 
* 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
This commit is contained in:
AdamDang
2018-05-12 02:53:29 +08:00
committed by k8s-ci-robot
parent 034a7c3fb9
commit 8fcea2d268
1 changed files with 91 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/storage/volumes.md
+91 -91
View File
@@ -10,14 +10,14 @@ content_template: templates/concept
{{% capture overview %}} {{% capture overview %}}
On-disk files in a container are ephemeral, which presents some problems for On-disk files in a Container are ephemeral, which presents some problems for
non-trivial applications when running in containers. First, when a container non-trivial applications when running in Containers. First, when a Container
crashes, kubelet will restart it, but the files will be lost - the crashes, kubelet will restart it, but the files will be lost - the
container starts with a clean state. Second, when running containers together 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 in a `Pod` it is often necessary to share files between those Containers. The
Kubernetes `Volume` abstraction solves both of these problems. 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 %}} {{% /capture %}}
@@ -30,27 +30,27 @@ Familiarity with [pods](/docs/user-guide/pods) is suggested.
Docker also has a concept of Docker also has a concept of
[volumes](https://docs.docker.com/engine/admin/volumes/), though it is [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 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 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 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). parameters to volumes).
A Kubernetes volume, on the other hand, has an explicit lifetime - the same as 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 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 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 importantly than this, Kubernetes supports many types of volumes, and a Pod can
use any number of them simultaneously. use any number of them simultaneously.
At its core, a volume is just a directory, possibly with some data in it, which 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 medium that backs it, and the contents of it are determined by the particular
volume type used. 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` `spec.volumes`
field) and where to mount those into containers (the field) and where to mount those into Containers (the
`spec.containers.volumeMounts` `spec.containers.volumeMounts`
field). field).
@@ -59,7 +59,7 @@ image and volumes. The [Docker
image](https://docs.docker.com/userguide/dockerimages/) is at the root of the 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 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 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. mount each volume.
## Types of Volumes ## Types of Volumes
@@ -98,11 +98,11 @@ We welcome additional contributions.
### awsElasticBlockStore ### awsElasticBlockStore
An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS) [EBS 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 `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 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" EBS volume can be pre-populated with data, and that data can be "handed off"
between pods. between Pods.
{{< caution >}} {{< caution >}}
**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it. **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: 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 * 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 * EBS only supports a single EC2 instance mounting a volume
#### Creating an EBS 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 ```shell
aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 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 ### cephfs
A `cephfs` volume allows an existing CephFS volume to be 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 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 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. writers simultaneously.
{{< caution >}} {{< caution >}}
@@ -219,7 +219,7 @@ keyed with `log_level`.
{{< /caution >}} {{< /caution >}}
{{< note >}} {{< 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. receive ConfigMap updates.
{{< /note >}} {{< /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. It mounts a directory and writes the requested data in plain text files.
{{< note >}} {{< 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. receive Downward API updates.
{{< /note >}} {{< /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 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 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 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. any reason, the data in the `emptyDir` is deleted forever.
{{< note >}} {{< 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 >}} {{< /note >}}
Some uses for an `emptyDir` are: Some uses for an `emptyDir` are:
* scratch space, such as for a disk-based merge sort * scratch space, such as for a disk-based merge sort
* checkpointing a long computation for recovery from crashes * checkpointing a long computation for recovery from crashes
* holding files that a content-manager container fetches while a webserver * holding files that a content-manager Container fetches while a webserver
container serves the data Container serves the data
By default, `emptyDir` volumes are stored on whatever medium is backing the 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 node - that might be disk or SSD or network storage, depending on your
environment. However, you can set the `emptyDir.medium` field to `"Memory"` environment. However, you can set the `emptyDir.medium` field to `"Memory"`
to tell Kubernetes to mount a tmpfs (RAM-backed filesystem) for you instead. 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 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. memory limit.
#### Example pod #### Example Pod
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -284,7 +284,7 @@ spec:
### fc (fibre channel) ### 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 You can specify single or multiple target World Wide Names using the parameter
`targetWWNs` in your volume configuration. If multiple WWNs are specified, `targetWWNs` in your volume configuration. If multiple WWNs are specified,
targetWWNs expect that those WWNs are from multi-path connections. 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
[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. 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 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 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 reattached by Flocker to the node that the Pod is scheduled. This means data
can be "handed off" between pods as required. can be "handed off" between Pods as required.
{{< caution >}} {{< caution >}}
**Important:** You must have your own Flocker installation running before you can use it. **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 ### gcePersistentDisk
A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) [Persistent 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 `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 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 >}} {{< caution >}}
**Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it. **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`: 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 * 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 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 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 PDs can only be mounted by a single consumer in read-write mode - no
simultaneous writers allowed. 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. the PD is read-only or the replica count is 0 or 1.
#### Creating a PD #### 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 ```shell
gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk
``` ```
#### Example pod #### Example Pod
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -371,7 +371,7 @@ spec:
### gitRepo ### gitRepo
A `gitRepo` volume is an example of what can be done as a volume plugin. It 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, 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. rather than extending the Kubernetes API for every such use case.
@@ -399,11 +399,11 @@ spec:
### glusterfs ### glusterfs
A `glusterfs` volume allows a [Glusterfs](http://www.gluster.org) (an open 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 `emptyDir`, which is erased when a Pod is removed, the contents of a
`glusterfs` volume are preserved and the volume is merely unmounted. This `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 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. simultaneously.
{{< caution >}} {{< caution >}}
@@ -415,16 +415,16 @@ See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< para
### hostPath ### hostPath
A `hostPath` volume mounts a file or directory from the host node's filesystem 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. powerful escape hatch for some applications.
For example, some uses for a `hostPath` are: 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` of `/var/lib/docker`
* running cAdvisor in a container; use a `hostPath` of `/sys` * running cAdvisor in a Container; use a `hostPath` of `/sys`
* allowing a pod to specify whether a given `hostPath` should exist prior to the * 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 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. 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: 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 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 * when Kubernetes adds resource-aware scheduling, as is planned, it will not be
able to account for resources used by a `hostPath` able to account for resources used by a `hostPath`
* the files or directories created on the underlying hosts are only writable by root. You * 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 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 permissions on the host to be able to write to a `hostPath` volume
#### Example pod #### Example Pod
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -479,10 +479,10 @@ spec:
### iscsi ### iscsi
An `iscsi` volume allows an existing iSCSI (SCSI over IP) volume to be mounted 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 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 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 >}} {{< caution >}}
**Important:** You must have your own iSCSI server running with the volume created before you can use it. **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 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 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 iSCSI volumes can only be mounted by a single consumer in read-write mode - no
simultaneous writers allowed. simultaneous writers allowed.
@@ -514,12 +514,12 @@ Local volumes can only be used as a statically created PersistentVolume. Dynamic
provisioning is not supported yet. provisioning is not supported yet.
Compared to `hostPath` volumes, local volumes can be used in a durable and 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. 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 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, 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 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 reduced availability, as well as potential data loss, depending on the
durability characteristics of the underlying disk. durability characteristics of the underlying disk.
@@ -554,7 +554,7 @@ spec:
``` ```
PersistentVolume `nodeAffinity` is required when using local volumes. It enables 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. correct node.
PersistentVolume `volumeMode` can now be set to "Block" (instead of the default 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 `volumeBindingMode` set to `WaitForFirstConsumer`. See the
[example](storage-classes.md#local). Delaying volume binding ensures [example](storage-classes.md#local). Delaying volume binding ensures
that the PersistentVolumeClaim binding decision will also be evaluated with any that the PersistentVolumeClaim binding decision will also be evaluated with any
other node constraints the pod may have, such as node resource requirements, node other node constraints the Pod may have, such as node resource requirements, node
selectors, pod affinity, and pod anti-affinity. selectors, Pod affinity, and Pod anti-affinity.
An external static provisioner can be run separately for improved management of An external static provisioner can be run separately for improved management of
the local volume lifecycle. Note that this provisioner does not support dynamic the local volume lifecycle. Note that this provisioner does not support dynamic
@@ -582,10 +582,10 @@ lifecycle.
### nfs ### nfs
An `nfs` volume allows an existing NFS (Network File System) share to be 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 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 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. writers simultaneously.
{{< caution >}} {{< caution >}}
@@ -597,7 +597,7 @@ See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "git
### persistentVolumeClaim ### persistentVolumeClaim
A `persistentVolumeClaim` volume is used to mount a 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 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. 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) - [`downwardAPI`](#downwardapi)
- `configMap` - `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 ```yaml
apiVersion: v1 apiVersion: v1
@@ -656,7 +656,7 @@ spec:
path: my-group/my-config 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 ```yaml
apiVersion: v1 apiVersion: v1
@@ -698,7 +698,7 @@ parameters are nearly the same with two exceptions:
for each individual projection. for each individual projection.
{{< note >}} {{< 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. receive updates for those volume sources.
{{< /note >}} {{< /note >}}
@@ -710,8 +710,8 @@ and aggregates capacity across multiple servers. Portworx runs in-guest in virtu
machines or on bare metal Linux nodes. machines or on bare metal Linux nodes.
A `portworxVolume` can be dynamically created through Kubernetes or it can also A `portworxVolume` can be dynamically created through Kubernetes or it can also
be pre-provisioned and referenced inside a Kubernetes pod. be pre-provisioned and referenced inside a Kubernetes Pod.
Here is an example pod referencing a pre-provisioned PortworxVolume: Here is an example Pod referencing a pre-provisioned PortworxVolume:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -735,7 +735,7 @@ spec:
{{< caution >}} {{< caution >}}
**Important:** Make sure you have an existing PortworxVolume with name `pxvol` **Important:** Make sure you have an existing PortworxVolume with name `pxvol`
before using it in the pod. before using it in the Pod.
{{< /caution >}} {{< /caution >}}
More details and examples can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). 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 ### quobyte
A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to
be mounted into your pod. be mounted into your Pod.
{{< caution >}} {{< caution >}}
**Important:** You must have your own Quobyte setup running with the volumes **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 An `rbd` volume allows a [Rados Block
Device](http://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your 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 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 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 >}} {{< caution >}}
**Important:** You must have your own Ceph installation running before you can use RBD. **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 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 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 RBD volumes can only be mounted by a single consumer in read-write mode - no
simultaneous writers allowed. 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 ScaleIO is a software-based storage platform that can use existing hardware to
create clusters of scalable shared block networked storage. The `scaleIO` volume 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 volumes (or it can dynamically provision new volumes for persistent volume claims, see
[ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)). [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. running with the volumes created before you can use them.
{{< /caution >}} {{< /caution >}}
The following is an example pod configuration with ScaleIO: The following is an example Pod configuration with ScaleIO:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -818,8 +818,8 @@ For further detail, please the see the [ScaleIO examples](https://github.com/kub
### secret ### secret
A `secret` volume is used to pass sensitive information, such as passwords, to 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 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 use by Pods without coupling to Kubernetes directly. `secret` volumes are
backed by tmpfs (a RAM-backed filesystem) so they are never written to backed by tmpfs (a RAM-backed filesystem) so they are never written to
non-volatile storage. non-volatile storage.
@@ -828,7 +828,7 @@ non-volatile storage.
{{< /caution >}} {{< /caution >}}
{{< note >}} {{< 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. receive Secret updates.
{{< /note >}} {{< /note >}}
@@ -837,20 +837,20 @@ Secrets are described in more detail [here](/docs/user-guide/secrets).
### storageOS ### storageOS
A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) 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. or attached storage accessible from any node within the Kubernetes cluster.
Data can be replicated to protect against node failure. Thin provisioning and Data can be replicated to protect against node failure. Thin provisioning and
compression can improve utilization and reduce cost. 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. A free developer license is available.
{{< caution >}} {{< 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. access StorageOS volumes or that will contribute storage capacity to the pool.
For installation instructions, consult the For installation instructions, consult the
[StorageOS documentation](https://docs.storageos.com). [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. of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore.
{{< caution >}} {{< 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 >}} {{< /caution >}}
#### Creating a VMDK volume #### Creating a VMDK volume
@@ -951,10 +951,10 @@ More examples can be found [here](https://github.com/kubernetes/examples/tree/ma
## Using subPath ## 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. 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: The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder:
```yaml ```yaml
@@ -990,8 +990,8 @@ spec:
The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the
medium of the filesystem holding the kubelet root dir (typically medium of the filesystem holding the kubelet root dir (typically
`/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or `/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 `hostPath` volume can consume, and no isolation between Containers or between
pods. Pods.
In the future, we expect that `emptyDir` and `hostPath` volumes will be able to 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) 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 may use the `csi` volume type to attach, mount, etc. the volumes exposed by the
CSI driver. CSI driver.
The `csi` volume type does not support direct reference from pod and may only be The `csi` volume type does not support direct reference from Pod and may only be
referenced in a pod via a `PersistentVolumeClaim` object. referenced in a Pod via a `PersistentVolumeClaim` object.
The following fields are available to storage administrators to configure a CSI The following fields are available to storage administrators to configure a CSI
persistent volume: persistent volume:
@@ -1055,7 +1055,7 @@ persistent volume:
`ControllerPublishVolumeRequest`. `ControllerPublishVolumeRequest`.
- `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used - `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 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. 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 This value is passed to the CSI driver via the `VolumeCapability` field of
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
@@ -1122,7 +1122,7 @@ Its values are:
In other words, if the host mounts anything inside the volume mount, the In other words, if the host mounts anything inside the volume mount, the
Container will see it mounted there. 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 volume mounts anything there, the Container with `HostToContainer` mount
propagation will see it. propagation will see it.