Why these two storage configuration are different?

Users Dgraph
, ,
1

i got this config（https://github.com/dgraph-io/dgraph/blob/master/contrib/config/kubernetes/dgraph-ha/dgraph-ha.yaml）
i want to know is this config local storage?

image
image1362×552 77.2 KB

why is it different with the follow configuration（https://dgraph.io/docs/deploy/kubernetes/）?

image
image1712×594 85.1 KB

3

@cangchen8180 Hi,

I will answer the questions under topic headings.

storageClassName vs. storage-class annotation

TL;DR Summary: The annotation (e.g. volume.alpha.kubernetes.io/storage-class and also volume.beta.kubernetes.io/storage-class) is an early implementation and will be deprecated, while the StorageClassName is the current method.

From the Kubernetes Docs:

A PV can have a class, which is specified by setting the storageClassName attribute to the name of a StorageClass. A PV of a particular class can only be bound to PVCs requesting that class. A PV with no storageClassName has no class and can only be bound to PVCs that request no particular class.

In the past, the annotation volume.beta.kubernetes.io/storage-class was used instead of the storageClassName attribute. This annotation is still working; however, it will become fully deprecated in a future Kubernetes release.
– source: Persistent Volumes | Kubernetes

Default Storage Class vs. Specific Storage Class

TL;DR Summary: You can see the default storage class with the following command: kubectl get storageclass.

One of these will be marked at default, but the provider (AKS, EKS, GKE, or another) may have other storage classes to choose from, or you may have installed others. Some examples of provider options:

  • In AKS for example has alternatives for SSD
  • In GKE there is a feature to enable a more robust gce storage driver. With this you can create storage classes that support features like SSD or encryption for external storage. The default is standard.
    NAME                 PROVISIONER            AGE
standard (default)   kubernetes.io/gce-pd   19d
  • In EKS, there’s an open source driver that can use the new gp3 with higher IOPS or other disk options. As an example, here’s one I created called gp3 and the default that comes with EKS:
    NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  152d
gp3             ebs.csi.aws.com         Delete          WaitForFirstConsumer   false                  15d
  • For all of these above and other K8S, there variety of drivers you can use for remote or local storage: Drivers - Kubernetes CSI Developer Documentation

Before, with the earlier K8S versions, you can set annotation to anything†, which will mean that you will use the default storage class for the K8S cluster. This is no longer needed, as the new method is to simply not include the storageClassName key.

† Annotation: volume.beta.kubernetes.io/storage-class: anything

If you want an alternative storage class, you can specify this explicitly with the storageClassName key.

Documentation + Examples

The documentation and example looks like it is in need of being updated. I will look into that. So I hope this explanation is useful in navigating with Kubernetes + Dgraph.

If you have a chance, you might be interested in the helm chart for Dgraph, which has many features that can be toggled, unlike the more static Kubernetes manifest. The github repository has some examples for helm chart values as well as helmfile examples to orchestrate one or more helm chart(s) with shared values.

1 Like
4

thanks， i am gonna try it.