bureaucraten, interfacemoderatoren, Beheerders (Semantic MediaWiki), Curatoren (Semantic MediaWiki), Redacteuren (Semantic MediaWiki), toezichthouders, beheerders
205
bewerkingen
→Make a PersistentVolume with a claim
| Regel 338: | Regel 338: | ||
To more accurately implement this use-case, Kubernetes has two object types called [https://kubernetes.io/docs/concepts/storage/persistent-volumes/ PersistentVolume and PersistentVolumeClaim]. The idea is that a cluster administrator creates PersistentVolumes (abbreviated <code>pv</code>) that know what kind of storage they represent and where to find it; then, users create PersistentVolumeClaim (abbreviated <code>pvc</code>) asking for storage with constraints like "at least 10 GB". When a PVC is created, it is matched to its closest PV and a link is created. If no PV is available to fulfill a PVC, the PVC stays in "Pending" state. In a way, PersistentVolumes are like Nodes in the sense that they provide capacity, and PersistentVolumeClaims are like Pods in the sense that they use that capacity if it is available anywhere in the cluster. | To more accurately implement this use-case, Kubernetes has two object types called [https://kubernetes.io/docs/concepts/storage/persistent-volumes/ PersistentVolume and PersistentVolumeClaim]. The idea is that a cluster administrator creates PersistentVolumes (abbreviated <code>pv</code>) that know what kind of storage they represent and where to find it; then, users create PersistentVolumeClaim (abbreviated <code>pvc</code>) asking for storage with constraints like "at least 10 GB". When a PVC is created, it is matched to its closest PV and a link is created. If no PV is available to fulfill a PVC, the PVC stays in "Pending" state. In a way, PersistentVolumes are like Nodes in the sense that they provide capacity, and PersistentVolumeClaims are like Pods in the sense that they use that capacity if it is available anywhere in the cluster. | ||
In this section, we'll rewrite our Pod from before to use a PersistentVolumeClaim with its constraints, and then have that PersistentVolumeClaim automatically matched to a PersistentVolume that provides the same NFS share. | In this section, we'll rewrite our Pod from before to use a PersistentVolumeClaim with its constraints, and then have that PersistentVolumeClaim automatically matched to a PersistentVolume that provides the same NFS share. The first thing we'll do is create the PersistentVolumeClaim: | ||
<pre> | |||
$ cat nginx-storage.yaml | |||
apiVersion: v1 | |||
kind: PersistentVolumeClaim | |||
metadata: | |||
name: nginx-webfiles | |||
spec: | |||
accessModes: | |||
- ReadWriteOnce | |||
resources: | |||
requests: | |||
storage: 2Gi | |||
$ kubectl apply -f nginx-storage.yaml | |||
persistentvolumeclaim/nginx-webfiles created | |||
$ kubectl get pvc | |||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE | |||
nginx-webfiles Pending 6s | |||
</pre> | |||
As you see, the <code>nginx-webfiles</code> PVC is created, but is Pending, because haven't supplied any PersistentVolumes to the cluster yet that can fulfill it. | |||
== Running a Deployment using this volume == | == Running a Deployment using this volume == | ||