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 %}}
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.