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

Release 1.9 (#5978)

Browse Source 
* Trivial change to open release branch

* Undo trivial change

* add service ipvs overview

* Add instructions on how to setup kubectl

* Document conntrack dependency for kube-proxy

* Add an a

This is kind of jarring / missing an article. I'm guessing it should either be ' to a rack of bare metal servers.' or '...to racks of bare metal servers.'.

* adding example responses for common issues

 - support request
 - code bug report

* Trivial change to open release branch

* Undo trivial change

* Signed-off-by: Ziqi Zhao <zhaoziqi@qiniu.com> (#5366)

Fix the not-working test case yaml for /doc/concepts/storage/volumes.md

* kubectl-overview

* temp fix for broken pod and deployment links

* Update Table of Solutions for Juju

* Revise certificates documentation (#5965)

* Update review-issues.md

Some edits for clarity and condensed language.

* Update init-containers.md

Fix leading spaces in commands.

* Update kubectl-overview.md

Fix format.

* Update clc.md

Fix format.

* Update openstack-heat.md

The url no need. just  highlight.

* Typo

I believe this should be "users" not "uses"

* making explicit hostname uniq requirement

* Update scheduling-hugepages.md

* Update update-daemon-set.md

* fix redirection of PersistentVolume

* Update hpa.md

* update kubectl instruction

* Use the format of kubeadm init

* fix spelling error

guarnatees  to guarantees

* add matchLabels description (#6020)

* search and replace for k8s.github.io to website (#6019)

* fix scale command of object-management (#6011)

* Update replicaset.md (#6009)

* Update secret.md (#6008)

* specify password for mysql image (#5990)

* specify password for mysql image

* specify password for mysql image

* link error for run-stateless-application-deployment.md (#5985)

* link error for run-stateless-application-deployment.md

* link error for run-stateless-application-deployment.md

* Add performance implications of inter-pod affinity/anti-affinity (#5979)

* 404 monthly maintenance - October 2017 (#5977)

* Updated redirects

* More redirects

* Add conjure-up to Turnkey Cloud Solutions list (#5973)

* Add conjure-up to Turnkey Cloud Solutions list

* Changed wording slightly

* change the StatefulSet to ReplicaSet in reference (#5968)

* Clarification of failureThreshold of probes (#5963)

* Mention usage of block storage version param (#5925)

Mention usage of block storage version (bs-version) parameter to
workaround attachment issues using older K8S versions on an OpenStack
cloud with path-based endpoints.

Resolves: https://github.com/kubernetes/kubernetes.github.io/issues/5924

* Update sysctl-cluster.md (#5894)

Include guide on enabling unsafe sysctls in minikube

* Avoid Latin phrases & format note (#5889)

* Avoid Latin phrases & format note

according the Documentation Style Guide

* Update scratch.md

* Update scratch.md

* resolves jekyll rendering error (#5976)

- chinese isn't understood for keys in YAML frontmatter in jekyll, so
   replaced it with the english equivalent that doesn't throw the
following error on rendering:

Error reading file src/kubernetes.github.io/cn/docs/concepts/cluster-administration/device-plugins.md: (<unknown>): could not find expected ':' while scanning a simple key at line 4 column 1

* Change VM to pod. (#6022)

* Add link to custom metrics. (#6023)

* Rephrase core group. (#6024)

* Added explanation on context to when joining (#6018)

* Update create-cluster-kubeadm.md (#5761)

Update Canal version in pod network apply commands

* Fixes issue #5620 (#5869)

* Fixes issue #5620

Signed-off-by: Brad Topol <btopol@us.ibm.com>

* Restructured so that review process is for both current and upcoming
releases.  Added content describing the use of tech reviewers.

* Removed incorrect Kubernetes reviewer link.

* Fixed tech reviewer URL to now use website

* Update pod-priority-preemption.md

fix-wrong-link-to-pod-preemption

* pod-security-policy.md: add links to the page about admission plugins.

* Adding all files for BlaBlaCar case study (#5857)

* Adding all files for BlaBlaCar case study

* Update blablacar.html

* Fix changed URL for google containers

* Add /docs/reference/auto-generated directory

* correct the downwardapi redirect

* Remove links using "here"

* Rename to /docs/reference/generated directory

* add Concept template

* Change title to just Ingress

* Link mistake (#6038)

* link mistake

* link mistake

* skip title check for skip_title_check.txt

* skip title check for skip_title_check.txt

* remove doesn't exist link.

* Fix podpreset task (#5705)

* Add a simple pod manifest to pod overview (#5986)

* Split PodPreset concept out from task doc (#5984)

* Add selector spec description (#5789)

* Add selector spec description

* Fix selector field explanation

* Put orphaned topics in TOC. (#6051)

* static-pod example bad format in the final page (#6050)

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* static-pod example bad format in the final page

* Fix `backoffLimit` field misplacement (#6042)

It should be placed in JobSpec according to:
https://github.com/kubernetes/kubernetes/blob/master/api/swagger-spec/batch_v1.json#L1488-L1514

* Update addons.md (#6061)

* add info about VMware NSX-T CNI plugin (#5987)

* add info about VMware NSX-T CNI plugin

Hello,

I'm VMware Networking and Security Architect and would like to include short information about our CNI plugin implementation similar to what other vendors did

Best regards

Emil Gagala

* Update networking.md

* Update networking.md

* Update networking.md

* Update: Using universal zsh configuration (#5669)

* Update install-kubectl.md

Zsh is not only oh-my-zsh, so I added universal configuration for zsh that also can be used in prezto.

* fix merge error after rebase

* Operating etcd cluster for Kubernetes bad format in the final page (#6056)

* Operating etcd cluster for Kubernetes bad format in the final page

* Update configure-upgrade-etcd.md

* Update configure-upgrade-etcd.md

* Usage note and warning tags. (#6053)

* Usage note and warning tags.

* Update configure-upgrade-etcd.md

* Update configure-upgrade-etcd.md

* Document jekyll includes snippets

* Add jekyll includes to docs home toc

- Remove extra kubernetes home in toc

* document docker cgroupdriver req (#5937)

* Update test blacklists (#6063)

* Update toc check blacklist

* Update title check blacklist

* wip

* wip

* Fix typo

* Document unconfined apparmor profile

* Revert "Document the unconfined profile for AppArmor" (#6268)

* CRD Validation: remove alpha warning, change enable instructions to (#6066)

disable

* Documented service annotation for AWS ELB SSL policy

* kubeadm: add a note about the new `--print-join-command` flag.

This is a new flag for the `kubeadm token create` command.

* Add a note to PDB page

* Improve Kubeadm reference doc (#6103)

* automatically-generated kubeadm reference doc

* user-mantained kubeadm reference doc

* Documentation for CSIPersistentVolume

* change replicaset documentation to use apps/v1 APIs

* Update service.md

ipvs alpha version -> beta version

* Updated Deployment concept docs (#6494)

* Updated Deployment concept docs

* Addressed comments

* Documentation for volume scheduling alpha feature

* Update admission control docs for webhooks

* Improve DNS documentation (#6479)

* update ds for 1.9

* Update service.md

* Update service.md

* Revert "begin updating webhook documentation" (#6575)

* Update version numbers to include 1.9 (#6518)

* Update site versions for 1.9

* Removed 1.4 docs

* Update _config.yml

* Update _config.yml

* updates for raw block devices

* rbac: docs for aggregated cluster roles (#6474)

* Added IPv6 information for Kubelet arguments (#6498)

* Added IPv6 info to kube-proxy arguments

* Added IPv6 information for argument for kubelet

* Update PVC resizing documentation (#6487)

* Updates for Windows Server version 1709 with K8s v1.8 (#6180)

* Updated for WSv1709 and K8s v1.8

* Updated picture and CNI config

* Fixed formatting on CNI Config

* Updated docs to reference Microsoft/SDN GitHub docs

* fix typo

* Workaround for Jekyllr frontmatter

* Added section on features and limitations, with example yaml files.

* Update index.md

* Added kubeadm section, few other small fixes

* Few minor grammar fixes

* Update access-cluster.md with a comment that for IPv6
the user should use [::1] for the localhost

* Addressed a number of issues brought up against the base PR

* Fixed windows-host-setup link

* Rewrite PodSecurityPolicy guide

* Update index.md

Signed-off-by: Alin Balutoiu <abalutoiu@cloudbasesolutions.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>

* Spelling correction and sentence capitalization.

- Corrected the spelling error for storing, was put in as 'stoing'.
- Capitalized list items.
- Added '.' at end of sentences in the list items.

* Update index.md

* Update index.md

* Addressed comments and rebased

* Fixed formatting

* Fixed formatting

* Updated header link

* Updated hyperlinks

* Updated warning

* formatting

* formatting

* formatting

* Revert "Update access-cluster.md with a comment that for IPv6"

This reverts commit 31e4dbdc25.

* Revert "fix typo"

This reverts commit c05678752d.

* Revert "Workaround for Jekyllr frontmatter"

This reverts commit b84ac59624.

* Fixed grammatical issues and reverted non-related commits

* Revert "Rewrite PodSecurityPolicy guide"

This reverts commit 5d39cfeae4.

* Revert "Spelling correction and sentence capitalization."

This reverts commit 47eed4346e.

* Fixed auto-numbering

* Minor formatting updates

* CoreDNS feature documentation (#6463)

* Initial placeholder PR for CoreDNS feature documentation

* Remove from admin, add content

* Fix missing endcapture

* Add to tasks.yml

* Review feedback

* Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod (#6415)

* Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod

A new feature PVC Protection was added into K8s 1.9 that's why this documentation change is needed.

* Added tag at the top of each new area.

* Fix typo

* Fix: switched on in (all kubelets) -> (all K8s components).

* Added link to admission controller

* Moved PVC Protection configuration into Before you begin section.

* Added steps how to verify PVC Protection feature.

* Fixes for admission controller plugin description and for PVC Protection description in PVC lifecycle.

* Testing official rendering of enumerations (1., 2., 3., etc.)

* Re-write to address comments from review.

* Fixed definition when a PVC is in active use by a pod.

* Change auditing docs page for 1.9 release (#6427)

* Change auditing docs page for 1.9 release

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Address review comments

Signed-off-by: Mik Vyatskov <vmik@google.com>

* Fix broken link

Signed-off-by: Mik Vyatskov <vmik@google.com>

* short circuit deny docs (#6536)

* line wrap

* short circuit deny

* address comments

* Add kubeadm 1.9 upgrade docs (#6485)

* kubeadm: Improve kubeadm documentation for v1.9 (#6645)

* Update admission control docs for webhooks (re-send #6368) (#6650)

* Update admission control docs for webhooks

* update in response to comments

* Revamp rkt and add CRI-O as alternative runtime (#6371)

Signed-off-by: Lorenzo Fontana <lo@linux.com>

* Documented NLB for Kubernetes 1.9 (#6260)

* Added IPV6 information to setup cluster using kubeadm (#6465)

* Added IPV6 information to setup cluster using kubeadm

* Updated kubeadm.md & create-cluster-kubeadm.md with IPv6 related information

* Added IPv6 options for kubeadm --init  & automated address binding for kube-proxy based on version of IP configured for API server)

* Changes to kubeadm.md as per comments

* Modified kubeadm.md and create-cluster-kubeadm.md

* Implemented changes requested by zacharysarah

* Removed autogenerated kubeadm.md changes

* StatefulSet 1.9 updates. (#6550)

* updates sts concept and tutorials to use 1.9 apps/v1

* Update statefulset.md

* clarify pod name label

* Garbage collection updates for 1.9 (#6555)

* 1.9 gc policy update

* carify deletion

* Couple nits for dnsConfig doc (#6652)

* Add doc for AllowedFlexVolume (#6563)

* Update OpenStack Cloud Provider API support for v1.9 (#6638)

* Flex volume is GA. Remove alpha notation. (#6666)

* Update generated ref docs for Kubernetes and Federation components. (#6658)

* Update generated ref docs for Kubernetes and Federation components.

* Rename kubectl-options to kubectl.

* Add title to kubectl.

* Fix double synopsis.

* Update Federation API ref docs for 1.9. (#6636)

* Update federation API ref docs.

* Move and redirect.

* Move generated Federation docs to the generated directory.

* Fix titles.

* Type

* Fix titles

* Update auto-generated Kubernetes APi ref docs. (#6646)

* Update kubectl commands for 1.9 (#6635)

* add ExtendedResourceToleration admission controller (#6618)

* Update API reference paths for v1.9 (#6681)
This commit is contained in:
Zach Corleissen
2017-12-15 17:36:13 -06:00
committed by GitHub
parent 0e628e7895
commit 08af95d42e
893 changed files with 131178 additions and 105058 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/storage/persistent-volumes.md
+146 -12
View File
@@ -7,18 +7,18 @@ approvers:
title: Persistent Volumes
---
This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
* TOC
{:toc}
## Introduction
Managing storage is a distinct problem from managing compute. The `PersistentVolume` subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this we introduce two new API resources: `PersistentVolume` and `PersistentVolumeClaim`.
Managing storage is a distinct problem from managing compute. The `PersistentVolume` subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this we introduce two new API resources: `PersistentVolume` and `PersistentVolumeClaim`.
A `PersistentVolume` (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A `PersistentVolume` (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
While `PersistentVolumeClaims` allow a user to consume abstract storage
resources, it is common that users need `PersistentVolumes` with varying
@@ -33,14 +33,14 @@ Please see the [detailed walkthrough with working examples](/docs/tasks/configur
## Lifecycle of a volume and claim
PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:
PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:
### Provisioning
There are two ways PVs may be provisioned: statically or dynamically.
#### Static
A cluster administrator creates a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
A cluster administrator creates a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
#### Dynamic
When none of the static PVs the administrator created matches a user's `PersistentVolumeClaim`,
@@ -60,16 +60,39 @@ please check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
### Binding
A user creates, or has already created in the case of dynamic provisioning, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of the mode used to bind them.
A user creates, or has already created in the case of dynamic provisioning, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping.
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
### Using
Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For volumes which support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.
Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For volumes which support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.
Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a persistentVolumeClaim in their Pod's volumes block. [See below for syntax details](#claims-as-volumes).
### Persistent Volume Claim Protection
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
The purpose of the PVC protection is to ensure that PVCs in active use by a pod are not removed from the system as this may result in data loss.
Note: PVC is in active use by a pod when the the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
When the [PVC protection alpha feature](/docs/tasks/administer-cluster/pvc-protection/) is enabled, if a user deletes a PVC in active use by a pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any pods.
You can see that a PVC is protected when the PVC's status is `Terminating` and the `Finalizers` list includes `kubernetes.io/pvc-protection`:
```shell
kubectl described pvc hostpath
Name: hostpath
Namespace: default
StorageClass: example-hostpath
Status: Terminating
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers: [kubernetes.io/pvc-protection]
...
```
### Reclaiming
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.
@@ -118,8 +141,13 @@ For volume plugins that support the Delete reclaim policy, deletion removes both
### Expanding Persistent Volumes Claims
With Kubernetes 1.8, we have added Alpha support for expanding persistent volumes. The current Alpha support was designed to only support volume types
that don't need file system resizing (Currently only glusterfs).
Kubernetes 1.8 added Alpha support for expanding persistent volumes. In v1.9, the following volume types support expanding Persistent volume claims:
* gcePersistentDisk
* awsElasticBlockStore
* Cinder
* glusterfs
* rbd
Administrator can allow expanding persistent volume claims by setting `ExpandPersistentVolumes` feature gate to true. Administrator
should also enable [`PersistentVolumeClaimResize` admission plugin](/docs/admin/admission-controllers/#persistentvolumeclaimresize)
@@ -147,6 +175,16 @@ by simply editing the claim and requesting bigger size. This in turn will trigg
Under no circumstances a new `PersistentVolume` gets created to satisfy the claim. Kubernetes will attempt to resize existing volume to satisfy the claim.
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
resizing to take place. Also, file system resizing is only supported for following file system types:
* XFS
* Ext3, Ext4
**Note:** Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
{: .note}
## Types of Persistent Volumes
@@ -156,7 +194,7 @@ Under no circumstances a new `PersistentVolume` gets created to satisfy the clai
* AWSElasticBlockStore
* AzureFile
* AzureDisk
* FC (Fibre Channel)
* FC (Fibre Channel)**
* FlexVolume
* Flocker
* NFS
@@ -173,6 +211,8 @@ Under no circumstances a new `PersistentVolume` gets created to satisfy the clai
* ScaleIO Volumes
* StorageOS
** Raw Block Support exists for these plugins only.
## Persistent Volumes
Each PV contains a spec and status, which is the specification and status of the volume.
@@ -185,6 +225,7 @@ Each PV contains a spec and status, which is the specification and status of the
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
@@ -203,6 +244,13 @@ Generally, a PV will have a specific storage capacity. This is set using the PV
Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc.
### Volume Mode
Prior to v1.9, the default behavior for all volume plugins was to create a filesystem on the persistent volume. With v1.9, the user can specify a volumeMode which will now support raw block devices in addition to file systems. Valid values for volumeMode are "Filesystem" or "Block". If left unspecified, volumeMode defaults to "Filesystem" internally. This is an optional API parameter.
**Note:** This feature is alpha in v1.9 and may change in the future.
{: .note}
### Access Modes
A `PersistentVolume` can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.
@@ -320,6 +368,7 @@ metadata:
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 8Gi
@@ -335,6 +384,10 @@ spec:
Claims use the same conventions as volumes when requesting storage with specific access modes.
### Volume Modes
Claims use the same convention as volumes to indicates the consumption of the volume as either a filesystem or block device.
### Resources
Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) applies to both volumes and claims.
@@ -417,6 +470,87 @@ spec:
`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
## Raw Block Volume Support
Static provisioning support for Raw Block Volumes is included as an alpha feature for v1.9. With this change are some new API fields that need to be used to facilitate this functionality. Currently, Fibre Channel is the only supported plugin for this feature.
### Persistent Volumes using a Raw Block Volume
```
apiVersion: v1
kind: PersistentVolume
metadata:
name: block-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
volumeMode: Block
persistentVolumeReclaimPolicy: Retain
fc:
targetWWNs: ["50060e801049cfd1"]
lun: 0
readOnly: false
```
### Persistent Volume Claim requesting a Raw Block Volume
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block
resources:
requests:
storage: 10Gi
```
### Pod specification adding Raw Block Device path in container
```
apiVersion: v1
kind: Pod
metadata:
name: pod-with-block-volume
spec:
containers:
- name: fc-container
image: fedora:26
command: ["/bin/sh", "-c"]
args: [ "tail -f /dev/null" ]
volumeDevices:
- name: data
devicePath: /dev/xvda
volumes:
- name: data
persistentVolumeClaim:
claimName: block-pvc
```
**Note:** When adding a raw block device for a Pod, we specify the device path in the container instead of a mount path.
{: .note}
### Binding Block Volumes
If a user requests a raw block volume by indicating this using the volumeMode field in the PersistentVolumeClaim spec, the binding rules differ slighty from previous releases that didn't consider this mode as part of the spec.
Listed is a table of possible combinations the user and admin might specify for requesting a raw block device. The table indicates if the volume will be bound or not given the combinations:
Volume binding matrix for statically provisioned volumes:
| PV volumeMode | PVC volumeMode | Result |
| --------------|:---------------:| ----------------:|
| unspecified | unspecified | BIND |
| unspecified | Block | NO BIND |
| unspecified | Filesystem | BIND |
| Block | unspecified | NO BIND |
| Block | Block | BIND |
| Block | Filesystem | NO BIND |
| Filesystem | Filesystem | BIND |
| Filesystem | Block | NO BIND |
| Filesystem | unspecified | BIND |
**Note:** Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
{: .note}
## Writing Portable Configuration
If you're writing configuration templates or examples that run on a wide range of clusters
docs/concepts/storage/storage-classes.md
+20
View File
@@ -78,6 +78,7 @@ for provisioning PVs. This field must be specified.
| PortworxVolume | &#x2713; | [Portworx Volume](#portworx-volume) |
| ScaleIO | &#x2713; | [ScaleIO](#scaleio) |
| StorageOS | &#x2713; | [StorageOS](#storageos) |
| Local | - | [Local](#local) |
You are not restricted to specifying the "internal" provisioners
listed here (whose names are prefixed with "kubernetes.io" and shipped
@@ -634,3 +635,22 @@ Secrets used for dynamically provisioned volumes may be created in any namespace
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
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
This feature requires the `VolumeScheduling` feature gate to be enabled.
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-fast
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
```
Local volumes do not support dynamic provisioning yet, however a StorageClass
should still be created to delay volume binding until pod scheduling. This is
specified by the `WaitForFirstConsumer` volume binding mode.
docs/concepts/storage/volumes.md
+49 -3
View File
@@ -69,6 +69,7 @@ Kubernetes supports several types of Volumes:
* `azureDisk`
* `azureFile`
* `cephfs`
* `csi`
* `downwardAPI`
* `emptyDir`
* `fc` (fibre channel)
@@ -170,6 +171,38 @@ writers simultaneously.
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/volumes/cephfs/) for more details.
### 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.
### downwardAPI
A `downwardAPI` volume is used to make downward API data available to applications.
@@ -434,7 +467,13 @@ See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{page.githu
### local
This volume type is alpha in 1.7.
{% assign for_k8s_version="v1.7" %}{% include feature-state-alpha.md %}
This alpha feature requires the `PersistentLocalVolumes` feature gate to be
enabled.
**Note:** Starting in 1.9, the `VolumeScheduling` feature gate must also be enabled.
{: .note}
A `local` volume represents a mounted local storage device such as a disk,
partition or directory.
@@ -443,7 +482,7 @@ Local volumes can only be used as a statically created PersistentVolume.
Compared to HostPath volumes, local volumes can be used in a durable manner
without manually scheduling pods to nodes, as the system is aware of the volume's
node constraints.
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.
@@ -481,6 +520,13 @@ spec:
**Note:** The local PersistentVolume cleanup and deletion requires manual intervention without the external provisioner.
{: .note}
Starting in 1.9, local volume binding can be delayed until pod scheduling by
creating a StorageClass with `volumeBindingMode` set to `WaitForFirstConsumer`.
See the [example](storage-classes.md#local). Delaying volume binding ensures
that the volume 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.
For details on the `local` volume type, see the [Local Persistent Storage
user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume).
@@ -893,7 +939,7 @@ achieved by using the `FlexVolume` plugin.
`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. This is an alpha feature and may change in future.
volume plugin path on each node.
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).