Fix links in concepts section

This commit is contained in:
Qiming Teng
2020-10-22 14:24:56 +08:00
parent 1996d94faa
commit 070023b24a
17 changed files with 27 additions and 28 deletions
@@ -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
+2 -3
View File
@@ -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