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

merge master to 1.10, with fixes (#7682)

Browse Source
This commit is contained in:
Jennifer Rondeau
2018-03-08 14:03:55 -05:00
committed by k8s-ci-robot
parent bb8c59a640
commit 44b51d6056
548 changed files with 11634 additions and 318622 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/storage/dynamic-provisioning.md
+2 -2
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- saad-ali
title: Dynamic Volume Provisioning
---
@@ -30,7 +30,7 @@ that provisioner when provisioning.
A cluster administrator can define and expose multiple flavors of storage (from
the same or different storage systems) within a cluster, each with a custom set
of parameters. This design also ensures that end users don’t have to worry
about the the complexity and nuances of how storage is provisioned, but still
about the complexity and nuances of how storage is provisioned, but still
have the ability to select from multiple storage options.
More information on storage classes can be found
docs/concepts/storage/persistent-volumes.md
+15 -13
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- jsafrane
- mikedanese
- saad-ali
@@ -121,17 +121,24 @@ Events: <none>
When a user is done with their volume, they can delete the PVC objects from the API which allows reclamation of the resource. The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted.
#### Retaining
#### Retain
The Retain reclaim policy allows for manual reclamation of the resource. When the `PersistentVolumeClaim` is deleted, the `PersistentVolume` still exists and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.
The `Retain` reclaim policy allows for manual reclamation of the resource. When the `PersistentVolumeClaim` is deleted, the `PersistentVolume` still exists and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.
1. Delete the `PersistentVolume`. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.
1. Manually clean up the data on the associated storage asset accordingly.
1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new `PersistentVolume` with the storage asset definition.
#### Recycling
#### Delete
If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
#### Recycle
**Warning:** The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
{: .warning}
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
However, an administrator can configure a custom recycler pod template using the Kubernetes controller manager command line arguments as described [here](/docs/admin/kube-controller-manager/). The custom recycler pod template must contain a `volumes` specification, as shown in the example below:
@@ -158,11 +165,6 @@ spec:
However, the particular path specified in the custom recycler pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled.
#### Deleting
For volume plugins that support the Delete reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as deleting the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to Delete. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
### Expanding Persistent Volumes Claims
Kubernetes 1.8 added Alpha support for expanding persistent volumes. In v1.9, the following volume types support expanding Persistent volume claims:
@@ -194,10 +196,10 @@ parameters:
allowVolumeExpansion: true
```
Once both feature gate and aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
by simply editing the claim and requesting bigger size. This in turn will trigger expansion of volume that is backing underlying `PersistentVolume`.
Once both feature gate and the aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
by simply editing the claim and requesting a larger size. This in turn will trigger expansion of the volume that is backing the underlying `PersistentVolume`.
Under no circumstances a new `PersistentVolume` gets created to satisfy the claim. Kubernetes will attempt to resize existing volume to satisfy the claim.
Under no circumstances will a new `PersistentVolume` be created to satisfy the claim. Kubernetes will instead attempt to resize the existing volume.
For expanding volumes containing a file system, file system resizing is only performed when a new Pod is started using the `PersistentVolumeClaim` in
ReadWrite mode. In other words, if a volume being expanded is used in a pod or deployment, you will need to delete and recreate the pod for file system
docs/concepts/storage/storage-classes.md
+5 -3
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- jsafrane
- mikedanese
- saad-ali
@@ -476,7 +476,9 @@ parameters:
When `kind` is `shared`, all unmanaged disks are created in a few shared
storage accounts in the same resource group as the cluster. When `kind` is
`dedicated`, a new dedicated storage account will be created for the new
unmanaged disk in the same resource group as the cluster.
unmanaged disk in the same resource group as the cluster. When `kind` is
`managed`, all managed disks are created in the same resource group as
the cluster.
- Premium VM can attach both Standard_LRS and Premium_LRS disks, while Standard
VM can only attach Standard_LRS disks.
@@ -636,7 +638,7 @@ and referenced with the `adminSecretNamespace` parameter. Secrets used by
pre-provisioned volumes must be created in the same namespace as the PVC that
references it.
#### Local
### Local
{% assign for_k8s_version="v1.10" %}{% include feature-state-beta.md %}
docs/concepts/storage/volumes.md
+55 -37
View File
@@ -1,5 +1,5 @@
---
approvers:
reviewers:
- jsafrane
- mikedanese
- saad-ali
@@ -49,7 +49,7 @@ volume type used.
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).
@@ -211,43 +211,19 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`"
Note that this path is derived from the volume's `mountPath` and the `path`
keyed with `log_level`.
### csi
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
a specification attempting to establish an industry standard interface that
Container Orchestration Systems (COs) can use to expose arbitrary storage systems
to their container workloads.
For more information about the details, please check the
[design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md).
<!-- TODO: add link to the kubernetes extension section -->
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
with external CSI volume drivers running on the same node.
After having deployed a CSI compatible volume driver, users can use `csi` as the
volume type to mount the storage provided by the driver.
CSI persistent volume support is introduced in Kubernetes v1.9 as an alpha feature
which has to be explicitly enabled by the cluster administrator. In other words,
the cluster administrator needs to add "`CSIPersistentVolume=true`" to the
"`--feature-gates=`" flag for the apiserver, the controller-manager and the kubelet
components.
A CSI persistent volume has the following fields for users to specify:
- `driver`: A string value that specifies the name of the volume driver to use.
It has to be less than 63 characters and starts with a character. The driver
name can have '`.`', '`-`', '`_`' or digits in it.
- `volumeHandle`: A string value that uniquely identify the volume name returned
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
used in all subsequent calls to the the volume driver for referencing the volume.
- `readOnly`: An optional boolean value indicating whether the volume is to be
published as read only. Default is false.
**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
receive ConfigMap updates.
{: .note}
### downwardAPI
A `downwardAPI` volume is used to make downward API data available to applications.
It mounts a directory and writes the requested data in plain text files.
**Note:** A container using Downward API as a [subPath](#using-subpath) volume mount will not
receive Downward API updates.
{: .note}
See the [`downwardAPI` volume example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) for more details.
### emptyDir
@@ -703,6 +679,10 @@ parameters are nearly the same with two exceptions:
volume source. However, as illustrated above, you can explicitly set the `mode`
for each individual projection.
**Note:** A container using a projected volume source as a [subPath](#using-subpath) volume mount will not
receive updates for those volume sources.
{: .note}
### portworxVolume
A `portworxVolume` is an elastic block storage layer that runs hyperconverged with
@@ -823,6 +803,10 @@ non-volatile storage.
**Important:** You must create a secret in the Kubernetes API before you can use it.
{: .caution}
**Note:** A container using a Secret as a [subPath](#using-subpath) volume mount will not
receive Secret updates.
{: .note}
Secrets are described in more detail [here](/docs/user-guide/secrets).
### storageOS
@@ -880,7 +864,7 @@ For more information including Dynamic Provisioning and Persistent Volume Claims
### vsphereVolume
**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider
configuration please refer [vSphere getting started guide](/docs/getting-started-guides/vsphere/).
configuration please refer [vSphere getting started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/).
{: .note}
A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents
@@ -990,16 +974,50 @@ several media types.
## Out-of-Tree Volume Plugins
In addition to the previously listed volume types, storage vendors may create
custom plugins without adding it to the Kubernetes repository. This can be
achieved by using the `FlexVolume` plugin.
achieved by using either the `CSI` plugin or the `FlexVolume` plugin.
For storage vendors looking to create an out-of-tree volume plugin, [please refer to this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for choosing between the plugin options.
### CSI
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
a specification attempting to establish an industry standard interface that
container orchestration systems can use to expose arbitrary storage systems
to their container workloads.
Please read
[CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for further information.
<!-- TODO: add link to the kubernetes extension section -->
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
with external CSI volume drivers running on the same node.
After having deployed a CSI compatible volume driver, users can use `csi` as the
volume type to mount the storage provided by the driver.
CSI persistent volume support is an alpha feature in Kubernetes v1.9 and requires a
cluster administrator to enable it. To enable CSI persistent volume support, the
cluster administrator adds `CSIPersistentVolume=true` to the `--feature-gates` flag
for apiserver, controller-manager, and kubelet.
The following fields are available to storage administrators to configure a CSI
persistent volume:
- `driver`: A string value that specifies the name of the volume driver to use.
It has to be less than 63 characters and starts with a character. The driver
name can have '`.`', '`-`', '`_`' or digits in it.
- `volumeHandle`: A string value that uniquely identify the volume name returned
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
used in all subsequent calls to the volume driver for referencing the volume.
- `readOnly`: An optional boolean value indicating whether the volume is to be
published as read only. Default is false.
### FlexVolume
`FlexVolume` enables users to mount vendor volumes into a pod. The vendor plugin
is implemented using a driver, an executable supporting a list of volume commands
defined by the `FlexVolume` API. Drivers must be installed in a pre-defined
volume plugin path on each node.
volume plugin path on each node. Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).
## Mount propagation
**Note:** Mount propagation is an alpha feature in Kubernetes 1.8 and may be