mirrors/prometheus-operator
mirrors/prometheus-operator
1
0
Fork 0
mirror of https://github.com/prometheus-operator/prometheus-operator.git synced 2025-04-20 19:29:10 +00:00
Code Activity

docs: editorial pass on storage.md

Browse source
This commit is contained in:
Beth Wright 2017-12-07 13:57:38 -08:00
parent a111fb359b
commit d9aebfd39a
1 changed files with 19 additions and 15 deletions

34
Documentation/user-guides/storage.md
View file

@ -5,16 +5,15 @@
# Storage
To keep data cross deployments and version upgrades the data must be persisted to some volume other than `emptyDir`, to be able to reuse it by `Pod`s after an upgrade.
To maintain data across deployments and version upgrades, the data must be persisted to some volume other than `emptyDir`, allowing it to be reused by Pods after an upgrade.
There are various kinds of volumes supported by Kubernetes. The Prometheus Operator works with `PersistentVolumeClaim`s. `PersistentVolumeClaims` are especially useful, because they support the underlying `PersistentVolume` to be provisioned when requested.
This document assumes you have a basic understanding of `PersisentVolume`s, `PersisentVolumeClaim`s, and their [provisioning](https://kubernetes.io/docs/user-guide/persistent-volumes/#provisioning).
Kubernetes supports several kinds of storage volumes. The Prometheus Operator works with PersistentVolumeClaims, which support the underlying PersistentVolume to be provisioned when requested.
This document assumes a basic understanding of PersisentVolumes, PersisentVolumeClaims, and their [provisioning][pv-provisioning].
## Storage Provisioning on AWS
For automatic provisioning of storage a `StorageClass` is required.
Automatic provisioning of storage requires a `StorageClass`.
```yaml
apiVersion: storage.k8s.io/v1beta1
@ -26,9 +25,9 @@ parameters:
type: gp2
```
> Make sure that AWS as a cloud provider is properly configured with your cluster, as otherwise storage provisioning will not work.
> Make sure that AWS as a cloud provider is properly configured with your cluster, or storage provisioning will not work.
It is recommended to use volumes that have high I/O throughput therefore we're using SSD EBS volumes here. Make sure to read the [documentation](https://kubernetes.io/docs/user-guide/persistent-volumes/#aws) to adapt this `StorageClass` to your needs.
For best results, use volumes that have high I/O throughput. These examples use SSD EBS volumes. Read the Kubernetes [Persistent Volumes][persistent-volumes] documentation to adapt this `StorageClass` to your needs.
The `StorageClass` that was created can be specified in the `storage` section in the `Prometheus` resource.
@ -51,14 +50,13 @@ spec:
storage: 1Gi
```
> The full documentation of the `storage` field can be found in the [spec documentation](../api.md#storagespec).
When now creating the `Prometheus` object a `PersistentVolumeClaim` is used for each `Pod` in the `StatefulSet` and the storage should automatically be provisioned, mounted and used.
> The full documentation of the `storage` field can be found in the [API documentation][api-doc].
When creating the Prometheus object, a PersistentVolumeClaim is used for each Pod in the StatefulSet, and the storage should automatically be provisioned, mounted and used.
## Manual storage provisioning
The Prometheus CRD specification allows you to support arbitrary storage, via a PersistentVolumeClaim.
The Prometheus CRD specification allows you to support arbitrary storage through a PersistentVolumeClaim.
The easiest way to use a volume that cannot be automatically provisioned (for whatever reason) is to use a label selector alongside a manually created PersistentVolume.
@ -103,13 +101,13 @@ spec:
### Disabling Default StorageClasses
In order to manually provoision volumes, as of Kubernetes 1.6.0, you may need to disable the default `StorageClass` that is automatically created for certain Cloud Providers. Default StorageClasses are pre-installed on Azure, AWS, GCE, OpenStack, and vSphere.
To manually provision volumes (as of Kubernetes 1.6.0), you may need to disable the default StorageClass that is automatically created for certain Cloud Providers. Default StorageClasses are pre-installed on Azure, AWS, GCE, OpenStack, and vSphere.
The default `StorageClass`s behavior will override manual storage provisioning, causing `PerisistentVolumeClaim`s not to bind manually created `PersistentVolume`s automatically.
The default StorageClass behavior will override manual storage provisioning, preventing PerisistentVolumeClaims from automatically binding to manually created PersistentVolumes.
To override this behavior, you must explicitely create the same resource, but set it to *not* be default ([see changelog for details](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#volumes)).
To override this behavior, you must explicitly create the same resource, but set it to *not* be default. (See the [changelog][volumes-changelog] for more information.)
To accomplish this on a Google Container Engine cluster, create the following `StorageClass`:
For example, to disable default StorageClasses on a Google Container Engine cluster, create the following StorageClass:
```yaml
kind: StorageClass
@ -124,3 +122,9 @@ parameters:
type: pd-ssd
zone: us-east1-d
```
[volumes-changelog]: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#volumes
[api-doc]: ../api.md#storagespec
[pv-provisioning]: https://kubernetes.io/docs/user-guide/persistent-volumes/#provisioning
[persistent-volumes]: https://kubernetes.io/docs/user-guide/persistent-volumes/#aws