WTD: Projected volumes (#3856)
* Update projected volume task - Rename file - Build out steps - Create separate yaml file for pod configuration - Add new page to the sidenav * Add projected volume type to volumes concept page
This commit is contained in:
Jesse Seldess
committed by
Andrew Chen
Andrew Chen
parent
f58b3d11d9
commit
3a8a465028
@@ -82,6 +82,7 @@ Kubernetes supports several types of Volumes:
|
||||
* `secret`
|
||||
* `persistentVolumeClaim`
|
||||
* `downwardAPI`
|
||||
* `projected`
|
||||
* `azureFileVolume`
|
||||
* `azureDisk`
|
||||
* `vsphereVolume`
|
||||
@@ -441,6 +442,99 @@ It mounts a directory and writes the requested data in plain text files.
|
||||
|
||||
See the [`downwardAPI` volume example](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) for more details.
|
||||
|
||||
### projected
|
||||
|
||||
A `projected` volume maps several existing volume sources into the same directory.
|
||||
|
||||
Currently, the following types of volume sources can be projected:
|
||||
|
||||
- [`secret`](#secret)
|
||||
- [`downwardAPI`](#downardapi)
|
||||
- `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/{{page.githubbranch}}/contributors/design-proposals/all-in-one-volume.md).
|
||||
|
||||
#### Example pod with a secret, a downward API, and a configmap
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- downwardAPI:
|
||||
items:
|
||||
- path: "labels"
|
||||
fieldRef:
|
||||
fieldPath: metadata.labels
|
||||
- path: "cpu_limit"
|
||||
resourceFieldRef:
|
||||
containerName: container-test
|
||||
resource: limits.cpu
|
||||
- configMap:
|
||||
name: myconfigmap
|
||||
items:
|
||||
- key: config
|
||||
path: my-group/my-config
|
||||
```
|
||||
|
||||
#### Example pod with multiple secrets with a non-default permission mode set
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- secret:
|
||||
name: mysecret2
|
||||
items:
|
||||
- key: password
|
||||
path: my-group/my-password
|
||||
mode: 511
|
||||
```
|
||||
|
||||
Each projected volume source is listed in the spec under `sources`. The
|
||||
parameters are nearly the same with two exceptions:
|
||||
|
||||
* For secrets, the `secretName` field has been changed to `name` to be consistent
|
||||
with config maps naming.
|
||||
* The `defaultMode` can only be specified at the projected level and not for each
|
||||
volume source. However, as illustrated above, you can explicitly set the `mode`
|
||||
for each individual projection.
|
||||
|
||||
### FlexVolume
|
||||
|
||||
A `FlexVolume` enables users to mount vendor volumes into a pod. It expects vendor
|
||||
@@ -464,7 +558,7 @@ More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{
|
||||
|
||||
### vsphereVolume
|
||||
|
||||
__Prerequisite: Kubernetes with vSphere Cloud Provider configured.
|
||||
__Prerequisite: Kubernetes with vSphere Cloud Provider configured.
|
||||
For cloudprovider configuration please refer [vSphere getting started guide](http://kubernetes.io/docs/getting-started-guides/vsphere/).__
|
||||
|
||||
A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents
|
||||
@@ -475,7 +569,7 @@ __Important: You must create VMDK using one of the following method before using
|
||||
#### Creating a VMDK volume
|
||||
|
||||
* Create using vmkfstools.
|
||||
|
||||
|
||||
First ssh into ESX and then use following command to create vmdk,
|
||||
|
||||
```shell
|
||||
@@ -553,9 +647,9 @@ __Important: Make sure you have an existing PortworxVolume with name `pxvol` bef
|
||||
More details and examples can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/portworx/README.md)
|
||||
|
||||
### ScaleIO
|
||||
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
|
||||
volumes (or it can dynamically provision new volumes for persistent volume claims, see
|
||||
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
|
||||
volumes (or it can dynamically provision new volumes for persistent volume claims, see
|
||||
[ScaleIO Persistent Volumes](/docs/user-guide/persistent-volumes/#scaleio)).
|
||||
|
||||
__Important: You must have an existing ScaleIO cluster already setup and running with the volumes created
|
||||
|
||||
Reference in New Issue
Block a user