Fix links in concepts section
This commit is contained in:
@@ -46,10 +46,9 @@ different purposes:
|
||||
[downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
|
||||
[secret](/docs/concepts/storage/volumes/#secret): inject different
|
||||
kinds of Kubernetes data into a Pod
|
||||
- [CSI ephemeral
|
||||
volumes](docs/concepts/storage/volumes/#csi-ephemeral-volumes):
|
||||
similar to the previous volume kinds, but provided by special [CSI
|
||||
drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
- [CSI ephemeral volumes](#csi-ephemeral-volume):
|
||||
similar to the previous volume kinds, but provided by special
|
||||
[CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
- [generic ephemeral volumes](#generic-ephemeral-volumes), which
|
||||
can be provided by all storage drivers that also support persistent volumes
|
||||
@@ -181,8 +180,8 @@ spec:
|
||||
|
||||
### Lifecycle and PersistentVolumeClaim
|
||||
|
||||
The key design idea is that the [parameters for a
|
||||
volume claim](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)
|
||||
The key design idea is that the
|
||||
[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
|
||||
are allowed inside a volume source of the Pod. Labels, annotations and
|
||||
the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
|
||||
created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
|
||||
|
||||
@@ -183,7 +183,7 @@ By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a bindi
|
||||
If the PersistentVolume exists and has not reserved PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and PersistentVolumeClaim will be bound.
|
||||
|
||||
The binding happens regardless of some volume matching criteria, including node affinity.
|
||||
The control plane still checks that [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
|
||||
The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -18,7 +18,7 @@ Container starts with a clean state. Second, when running Containers together
|
||||
in a `Pod` it is often necessary to share files between those Containers. The
|
||||
Kubernetes `Volume` abstraction solves both of these problems.
|
||||
|
||||
Familiarity with [Pods](/docs/concepts/workloads/pods/pod/) is suggested.
|
||||
Familiarity with [Pods](/docs/concepts/workloads/pods/) is suggested.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -52,8 +52,7 @@ field) and where to mount those into Containers (the
|
||||
field).
|
||||
|
||||
A process in a container sees a filesystem view composed from their Docker
|
||||
image and volumes. The [Docker
|
||||
image](https://docs.docker.com/userguide/dockerimages/) is at the root of the
|
||||
image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/) is at the root of the
|
||||
filesystem hierarchy, and any volumes are mounted at the specified paths within
|
||||
the image. Volumes can not mount onto other volumes or have hard links to
|
||||
other volumes. Each Container in the Pod must independently specify where to
|
||||
|
||||
Reference in New Issue
Block a user