resolving conflicts
This commit is contained in:
Savitha Raghunathan
@@ -5,11 +5,11 @@ reviewers:
|
||||
- thockin
|
||||
- msau42
|
||||
title: Dynamic Volume Provisioning
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dynamic volume provisioning allows storage volumes to be created on-demand.
|
||||
Without dynamic provisioning, cluster administrators have to manually make
|
||||
@@ -19,10 +19,10 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates
|
||||
the need for cluster administrators to pre-provision storage. Instead, it
|
||||
automatically provisions storage when it is requested by users.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Background
|
||||
|
||||
@@ -133,4 +133,4 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
|
||||
Pods are scheduled. This can be accomplished by setting the [Volume Binding
|
||||
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -11,18 +11,18 @@ feature:
|
||||
description: >
|
||||
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -746,8 +746,9 @@ and need persistent storage, it is recommended that you use the following patter
|
||||
dynamic storage support (in which case the user should create a matching PV)
|
||||
or the cluster has no storage system (in which case the user cannot deploy
|
||||
config requiring PVCs).
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
|
||||
* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
|
||||
@@ -759,4 +760,3 @@ and need persistent storage, it is recommended that you use the following patter
|
||||
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
|
||||
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
|
||||
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
|
||||
{{% /capture %}}
|
||||
@@ -5,19 +5,19 @@ reviewers:
|
||||
- thockin
|
||||
- msau42
|
||||
title: Storage Classes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the concept of a StorageClass in Kubernetes. Familiarity
|
||||
with [volumes](/docs/concepts/storage/volumes/) and
|
||||
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -821,4 +821,4 @@ Delaying volume binding allows the scheduler to consider all of a Pod's
|
||||
scheduling constraints when choosing an appropriate PersistentVolume for a
|
||||
PersistentVolumeClaim.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -5,10 +5,10 @@ reviewers:
|
||||
- thockin
|
||||
- msau42
|
||||
title: Node-specific Volume Limits
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page describes the maximum number of volumes that can be attached
|
||||
to a Node for various cloud providers.
|
||||
@@ -18,9 +18,9 @@ how many volumes can be attached to a Node. It is important for Kubernetes to
|
||||
respect those limits. Otherwise, Pods scheduled on a Node could get stuck
|
||||
waiting for volumes to attach.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Kubernetes default limits
|
||||
|
||||
@@ -78,4 +78,4 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface
|
||||
|
||||
* 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 %}}
|
||||
|
||||
|
||||
@@ -5,18 +5,18 @@ reviewers:
|
||||
- thockin
|
||||
- msau42
|
||||
title: CSI Volume Cloning
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -70,4 +70,4 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
|
||||
|
||||
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -7,20 +7,20 @@ reviewers:
|
||||
- xing-yang
|
||||
- yuxiangqian
|
||||
title: Volume Snapshot Classes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
|
||||
with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
|
||||
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -69,4 +69,4 @@ Volume snapshot classes have parameters that describe volume snapshots belonging
|
||||
the volume snapshot class. Different parameters may be accepted depending on the
|
||||
`driver`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -7,19 +7,19 @@ reviewers:
|
||||
- xing-yang
|
||||
- yuxiangqian
|
||||
title: Volume Snapshots
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.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 %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -154,4 +154,4 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
|
||||
For more details, see
|
||||
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ reviewers:
|
||||
- thockin
|
||||
- msau42
|
||||
title: Volumes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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
|
||||
@@ -20,15 +20,15 @@ Kubernetes `Volume` abstraction solves both of these problems.
|
||||
|
||||
Familiarity with [Pods](/docs/user-guide/pods) is suggested.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Background
|
||||
|
||||
Docker also has a concept of
|
||||
[volumes](https://docs.docker.com/engine/admin/volumes/), though it is
|
||||
[volumes](https://docs.docker.com/storage/), 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
|
||||
recently there were only local-disk-backed volumes. Docker now provides volume
|
||||
@@ -1480,6 +1480,7 @@ sudo systemctl restart docker
|
||||
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user