Official 1.17 Release Docs (#18011)
* feat: graduate TaintNodesByCondition to GA (#17073) * Promote StartupProbe to beta (enabled by default). (#17164) * Watch bookmarks to GA (#17026) * feat: graduate ScheduleDaemonSetPods to GA (#17350) * Update Docker installation instructions (#17405) * Use exact version numbers for installing Docker in Ubuntu (#17428) * Move CSIMigration and CSIMigrationGCE to Beta in Kubernetes v1.17 (#17478) * Promote NodeLease feature to GA (#17189) * Update docs for csi topology ga (#17408) * Update RunAsUsername to beta (#17460) * doc:Update RunAsUsername to beta * doc: update samples - kubernetes.io/os is no longer beta * Updating based on review feedback * Promote Node-specific volume limits to GA (#17432) * Promote PodShareProcessNamespace to stable (#17192) * Promote PodShareProcessNamespace to stable * Add for_k8s_version to feature-state label Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Readd version-check to shareProcessNamespace task * Update service load balancer finalizer doc for GA (#17438) * Update Topology Manager docs (#17451) * Added information on how device plugins can take advantage of Topology Manager * Updated the Topology Manager documentation to include additionalinformation and update some out of date sections * Fix broken Topology Manager link (#17746) Part of What's Next Device Plugin section * Update CRD defaulting docs for GA (#17450) * Add documentation for VolumeSnapshot Beta (#17233) * Updating EndpointSlice documentation for beta release in 1.17 (#17411) * (docs/dualstack): v1.17 updates (#17457) * Add placehold doc updates for dualstack in 1.17 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Add Downward API and /etc/hosts Pod IP validation Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * remove addressed known issue via k/k pr 85246 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Remove known issue and add flag as part of k/k 79993 Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * remove follow up placeholders Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update verbiage Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Make IP addressing consistent throughout the task Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update to status.podIPs Signed-off-by: Lachlan Evenson <lachlan.evenson@microsoft.com> * Update content/en/docs/tasks/network/validate-dual-stack.md Use set instead of env Co-Authored-By: Khaled Henidak (Kal) <khnidk@outlook.com> * add topology.kubernetes.io/zone, topology.kubernetes.io/region and node.kubernetes.io/instance-type labels to docs (#17498) Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * Service topology alpha documentation (#17459) * Update list of feature flags for in-tree plugins migrated to CSI (#17533) Signed-off-by: Deep Debroy <ddebroy@docker.com> * Update Node concept for TaintNodesByCondition going GA (#17577) * feat: graduate ResourceQuotaScopeSelectors to GA in 1.17 (#17554) * kubeadm: update the upgrade documentation for 1.17 (#17587) * doc: Simplify Windows deployments with RuntimeClass (#16697) * doc: Simplify Windows deployments with RuntimeClass * Updating on review feedback * doc: Adding windows-build label from enhancement 1301 * update doc for kubelet option --reserved-cpus (#17648) * feat: update TaintNodesByCondition in feature gates table (#17377) * Update docs for v1 resource quota configuration (#17547) * AdmissionConfiguration v1 (#17548) * Update WebhookAdmissionConfiguration examples (#17549) * Update AWS EBS Migration Feature state (#16126) * Add resource version section to api-concepts documentation (#16910) * Add Resource Version semantics section to api concepts * Clarify risks of going back in time, add details about compaction and watch cache sizes * Apply suggestions from liggitt Co-Authored-By: Jordan Liggitt <jordan@liggitt.net> * remove pesudocode, apply feedback * Fix typo * Clarify equality rules * Cleanup kubectl generators docs (#17609) * Write ReplicationController without a space * Drop mentioning unsupported cluster versions * Fix capitalization for “API group” * Tweak wording * Avoid using deprecated generator in example * add Antrea description in dev-1.17 (#17919) * Promote VolumeSubpathEnvExpansion to GA * Reference Documentation for the Kubernetes API for 1.17 (#18019) * Update feature-gates.md (#18033) * Reference Documentation for kubectl Commands for 1.17 (#18017) * Update for v1.17 (#18034) * Update config.toml(release-1.17) for 1.17 (#18031)
This commit is contained in:
Damini Satya
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
cf925bb688
commit
dff2f7b960
@@ -185,10 +185,10 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
|
||||
* All of the above
|
||||
* [Local](#local)
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="1.14" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="1.17" >}}
|
||||
[CSI volumes](/docs/concepts/storage/volumes/#csi) are also supported with dynamic provisioning
|
||||
and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
|
||||
to see its supported topology keys and examples. The `CSINodeInfo` feature gate must be enabled.
|
||||
to see its supported topology keys and examples.
|
||||
|
||||
### Allowed Topologies
|
||||
|
||||
|
||||
@@ -38,6 +38,8 @@ that can be attached to a Node:
|
||||
|
||||
You can change these limits by setting the value of the
|
||||
`KUBE_MAX_PD_VOLS` environment variable, and then starting the scheduler.
|
||||
CSI drivers might have a different procedure, see their documentation
|
||||
on how to customize their limits.
|
||||
|
||||
Use caution if you set a limit that is higher than the default limit. Consult
|
||||
the cloud provider's documentation to make sure that Nodes can actually support
|
||||
@@ -47,10 +49,7 @@ The limit applies to the entire cluster, so it affects all Nodes.
|
||||
|
||||
## Dynamic volume limits
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.12" >}}
|
||||
|
||||
Kubernetes 1.11 introduced support for dynamic volume limits based on Node type as an Alpha feature.
|
||||
In Kubernetes 1.12 this feature is graduating to Beta and will be enabled by default.
|
||||
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
|
||||
|
||||
Dynamic volume limits are supported for following volume types.
|
||||
|
||||
@@ -59,14 +58,12 @@ Dynamic volume limits are supported for following volume types.
|
||||
- Azure Disk
|
||||
- CSI
|
||||
|
||||
|
||||
When the dynamic volume limits feature is enabled, Kubernetes automatically
|
||||
determines the Node type and enforces the appropriate number of attachable
|
||||
volumes for the node. For example:
|
||||
For volumes managed by in-tree volume plugins, Kubernetes automatically determines the Node
|
||||
type and enforces the appropriate maximum number of volumes for the node. For example:
|
||||
|
||||
* On
|
||||
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
|
||||
up to 128 volumes can be attached to a node, [depending on the node
|
||||
up to 127 volumes can be attached to a node, [depending on the node
|
||||
type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
|
||||
|
||||
* For Amazon EBS disks on M5,C5,R5,T3 and Z1D instance types, Kubernetes allows only 25
|
||||
@@ -76,7 +73,9 @@ Kubernetes allows 39 volumes to be attached to a Node.
|
||||
|
||||
* On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
|
||||
|
||||
* For CSI, any driver that advertises volume attach limits via CSI specs will have those limits available as the Node's allocatable property
|
||||
and the Scheduler will not schedule Pods with volumes on any Node that is already at its capacity. Refer to the [CSI specs](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for more details.
|
||||
* If a CSI storage driver advertises a maximum number of volumes for a Node (using `NodeGetInfo`), the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} honors that limit.
|
||||
Refer to the [CSI specifications](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for details.
|
||||
|
||||
* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
- jingxu97
|
||||
- xing-yang
|
||||
- yuxiangqian
|
||||
title: Volume Snapshot Classes
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
@@ -28,7 +30,7 @@ way to describe the "classes" of storage when provisioning a volume snapshot.
|
||||
|
||||
## The VolumeSnapshotClass Resource
|
||||
|
||||
Each `VolumeSnapshotClass` contains the fields `snapshotter` and `parameters`,
|
||||
Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`,
|
||||
which are used when a `VolumeSnapshot` belonging to the class needs to be
|
||||
dynamically provisioned.
|
||||
|
||||
@@ -41,23 +43,30 @@ Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapsh
|
||||
that don't request any particular class to bind to.
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1alpha1
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshotClass
|
||||
metadata:
|
||||
name: csi-hostpath-snapclass
|
||||
snapshotter: csi-hostpath
|
||||
driver: hostpath.csi.k8s.io
|
||||
deletionPolicy: Delete
|
||||
parameters:
|
||||
```
|
||||
|
||||
### Snapshotter
|
||||
### Driver
|
||||
|
||||
Volume snapshot classes have a snapshotter that determines what CSI volume plugin is
|
||||
Volume snapshot classes have a driver that determines what CSI volume plugin is
|
||||
used for provisioning VolumeSnapshots. This field must be specified.
|
||||
|
||||
### DeletionPolicy
|
||||
|
||||
Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
|
||||
|
||||
If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
|
||||
|
||||
## Parameters
|
||||
|
||||
Volume snapshot classes have parameters that describe volume snapshots belonging to
|
||||
the volume snapshot class. Different parameters may be accepted depending on the
|
||||
`snapshotter`.
|
||||
`driver`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
- jingxu97
|
||||
- xing-yang
|
||||
- yuxiangqian
|
||||
title: Volume Snapshots
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
@@ -11,8 +13,8 @@ weight: 20
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
This document describes the current state of `VolumeSnapshots` in Kubernetes. Familiarity with [persistent volumes](/docs/concepts/storage/persistent-volumes/) is suggested.
|
||||
{{< feature-state for_k8s_version="1.17" state="beta" >}}
|
||||
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -27,18 +29,15 @@ A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that
|
||||
|
||||
A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.
|
||||
|
||||
While `VolumeSnapshots` allow a user to consume abstract storage resources, cluster administrators
|
||||
need to be able to offer a variety of `VolumeSnapshotContents` without exposing
|
||||
users to the details of how those volume snapshots should be provisioned. For these needs
|
||||
there is the `VolumeSnapshotClass` resource.
|
||||
`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attibutes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
|
||||
|
||||
Users need to be aware of the following when using this feature:
|
||||
|
||||
* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are CRDs, not part of the core API.
|
||||
* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
|
||||
* `VolumeSnapshot` support is only available for CSI drivers.
|
||||
* As part of the deployment process, the Kubernetes team provides a sidecar helper container for the snapshot controller called `external-snapshotter`. It watches `VolumeSnapshot` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
|
||||
* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use `external-snapshotter`.
|
||||
* The CSI drivers that support volume snapshot will automatically install CRDs defined for the volume snapshots.
|
||||
* As part of the deployment process in the beta version of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver. The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object in dynamic provisioning. The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
|
||||
* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
|
||||
* The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
|
||||
|
||||
## Lifecycle of a volume snapshot and volume snapshot content
|
||||
|
||||
@@ -46,89 +45,104 @@ Users need to be aware of the following when using this feature:
|
||||
|
||||
### Provisioning Volume Snapshot
|
||||
|
||||
There are two ways snapshots may be provisioned: statically or dynamically.
|
||||
There are two ways snapshots may be provisioned: pre-provisioned or dynamically provisioned.
|
||||
|
||||
#### Static
|
||||
A cluster administrator creates a number of `VolumeSnapshotContents`. 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.
|
||||
#### Pre-provisioned {#static}
|
||||
A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real volume snapshot on the storage system 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 `VolumeSnapshotContents` the administrator created matches a user's `VolumeSnapshot`,
|
||||
the cluster may try to dynamically provision a volume snapshot specially for the `VolumeSnapshot` object.
|
||||
This provisioning is based on `VolumeSnapshotClasses`: the `VolumeSnapshot` must request a
|
||||
[volume snapshot class](/docs/concepts/storage/volume-snapshot-classes/) and
|
||||
the administrator must have created and configured that class in order for dynamic
|
||||
provisioning to occur.
|
||||
Instead of using a pre-existing snapshot, you can request that a snapshot to be dynamically taken from a PersistentVolumeClaim. The [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) specifies storage provider-specific parameters to use when taking a snapshot.
|
||||
|
||||
### Binding
|
||||
|
||||
A user creates, or has already created in the case of dynamic provisioning, a `VolumeSnapshot` with a specific amount of storage requested and with certain access modes. A control loop watches for new VolumeSnapshots, finds a matching VolumeSnapshotContent (if possible), and binds them together. If a VolumeSnapshotContent was dynamically provisioned for a new VolumeSnapshot, the loop will always bind that VolumeSnapshotContent to the VolumeSnapshot. Once bound, `VolumeSnapshot` binds are exclusive, regardless of how they were bound. A VolumeSnapshot to VolumeSnapshotContent binding is a one-to-one mapping.
|
||||
The snapshot controller handles the binding of a `VolumeSnapshot` object with an appropriate `VolumeSnapshotContent` object, in both pre-provisioned and dynamically provisioned scenarios. The binding is a one-to-one mapping.
|
||||
|
||||
VolumeSnapshots will remain unbound indefinitely if a matching VolumeSnapshotContent does not exist. VolumeSnapshots will be bound as matching VolumeSnapshotContents become available.
|
||||
In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound until the requested VolumeSnapshotContent object is created.
|
||||
|
||||
### Persistent Volume Claim in Use Protection
|
||||
### Persistent Volume Claim as Snapshot Source Protection
|
||||
|
||||
The purpose of the Persistent Volume Claim Object in Use Protection feature is to ensure that in-use PVC API objects are not removed from the system (as this may result in data loss).
|
||||
The purpose of this protection is to ensure that in-use PersistentVolumeClaim API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
|
||||
|
||||
If a PVC is in active use by a snapshot as a source to create the snapshot, the PVC is in-use. If a user deletes a PVC API object in active use as a snapshot source, the PVC object is not removed immediately. Instead, removal of the PVC object is postponed until the PVC is no longer actively used by any snapshots. A PVC is no longer used as a snapshot source when `ReadyToUse` of the snapshot `Status` becomes `true`.
|
||||
While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
|
||||
|
||||
### Delete
|
||||
|
||||
Deletion removes both the `VolumeSnapshotContent` object from the Kubernetes API, as well as the associated storage asset in the external infrastructure.
|
||||
|
||||
## Volume Snapshot Contents
|
||||
|
||||
Each VolumeSnapshotContent contains a spec, which is the specification of the volume snapshot.
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1alpha1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: new-snapshot-content-test
|
||||
spec:
|
||||
snapshotClassName: csi-hostpath-snapclass
|
||||
source:
|
||||
name: pvc-test
|
||||
kind: PersistentVolumeClaim
|
||||
volumeSnapshotSource:
|
||||
csiVolumeSnapshotSource:
|
||||
creationTime: 1535478900692119403
|
||||
driver: csi-hostpath
|
||||
restoreSize: 10Gi
|
||||
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
|
||||
```
|
||||
|
||||
### Class
|
||||
|
||||
A VolumeSnapshotContent can have a class, which is specified by setting the
|
||||
`snapshotClassName` attribute to the name of a
|
||||
[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
|
||||
A VolumeSnapshotContent of a particular class can only be bound to VolumeSnapshots requesting
|
||||
that class. A VolumeSnapshotContent with no `snapshotClassName` has no class and can only be bound
|
||||
to VolumeSnapshots that request no particular class.
|
||||
Deletion is triggered by deleting the `VolumeSnapshot` object, and the `DeletionPolicy` will be followed. If the `DeletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the `DeletionPolicy` is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
|
||||
|
||||
## VolumeSnapshots
|
||||
|
||||
Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
|
||||
Each VolumeSnapshot contains a spec and a status.
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1alpha1
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: new-snapshot-test
|
||||
spec:
|
||||
snapshotClassName: csi-hostpath-snapclass
|
||||
volumeSnapshotClassName: csi-hostpath-snapclass
|
||||
source:
|
||||
name: pvc-test
|
||||
kind: PersistentVolumeClaim
|
||||
persistentVolumeClaimName: pvc-test
|
||||
```
|
||||
|
||||
### Class
|
||||
`persistentVolumeClaimName` is the name of the PersistentVolumeClaim data source for the snapshot. This field is required for dynamically provisioning a snapshot.
|
||||
|
||||
A volume snapshot can request a particular class by specifying the name of a
|
||||
[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
|
||||
using the attribute `snapshotClassName`.
|
||||
Only VolumeSnapshotContents of the requested class, ones with the same `snapshotClassName`
|
||||
as the VolumeSnapshot, can be bound to the VolumeSnapshot.
|
||||
using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
|
||||
|
||||
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
|
||||
|
||||
```
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: test-snapshot
|
||||
spec:
|
||||
source:
|
||||
volumeSnapshotContentName: test-content
|
||||
```
|
||||
|
||||
## Volume Snapshot Contents
|
||||
|
||||
Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
|
||||
spec:
|
||||
deletionPolicy: Delete
|
||||
driver: hostpath.csi.k8s.io
|
||||
source:
|
||||
volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
|
||||
volumeSnapshotClassName: csi-hostpath-snapclass
|
||||
volumeSnapshotRef:
|
||||
name: new-snapshot-test
|
||||
namespace: default
|
||||
uid: 72d9a349-aacd-42d2-a240-d775650d2455
|
||||
```
|
||||
|
||||
`volumeHandle` is the unique identifier of the volume created on the storage backend and returned by the CSI driver during the volume creation. This field is required for dynamically provisioning a snapshot. It specifies the volume source of the snapshot.
|
||||
|
||||
For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: new-snapshot-content-test
|
||||
spec:
|
||||
deletionPolicy: Delete
|
||||
driver: hostpath.csi.k8s.io
|
||||
source:
|
||||
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
|
||||
volumeSnapshotRef:
|
||||
name: new-snapshot-test
|
||||
namespace: default
|
||||
```
|
||||
|
||||
`snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.
|
||||
|
||||
## Provisioning Volumes from Snapshots
|
||||
|
||||
|
||||
@@ -151,14 +151,19 @@ spec:
|
||||
|
||||
#### CSI Migration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
The CSI Migration feature for awsElasticBlockStore, when enabled, shims all plugin operations
|
||||
from the existing in-tree plugin to the `ebs.csi.aws.com` Container
|
||||
Storage Interface (CSI) Driver. In order to use this feature, the [AWS EBS CSI
|
||||
Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
|
||||
must be installed on the cluster and the `CSIMigration` and `CSIMigrationAWS`
|
||||
Alpha features must be enabled.
|
||||
Beta features must be enabled.
|
||||
|
||||
#### CSI Migration Complete
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
|
||||
To turn off the awsElasticBlockStore storage plugin from being loaded by controller manager and kubelet, you need to set this feature flag to true. This requires `ebs.csi.aws.com` Container Storage Interface (CSI) driver being installed on all worker nodes.
|
||||
|
||||
### azureDisk {#azuredisk}
|
||||
|
||||
@@ -479,14 +484,14 @@ spec:
|
||||
|
||||
#### CSI Migration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
The CSI Migration feature for GCE PD, when enabled, shims all plugin operations
|
||||
from the existing in-tree plugin to the `pd.csi.storage.gke.io` Container
|
||||
Storage Interface (CSI) Driver. In order to use this feature, the [GCE PD CSI
|
||||
Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
|
||||
must be installed on the cluster and the `CSIMigration` and `CSIMigrationGCE`
|
||||
Alpha features must be enabled.
|
||||
Beta features must be enabled.
|
||||
|
||||
### gitRepo (deprecated) {#gitrepo}
|
||||
|
||||
@@ -1154,7 +1159,7 @@ spec:
|
||||
|
||||
### Using subPath with expanded environment variables
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
|
||||
Use the `subPathExpr` field to construct `subPath` directory names from Downward API environment variables.
|
||||
|
||||
Reference in New Issue
Block a user