elasticsearchkubernetesdigital-oceanvolumes

Digital Ocean managed Kubernetes volume in pending state


It's not so digital ocean specific, would be really nice to verify if this is an expected behavior or not.

I'm trying to setup ElasticSearch cluster on DO managed Kubernetes cluster with helm chart from ElasticSearch itself

And they say that I need to specify a storageClassName in a volumeClaimTemplate in order to use volume which is provided by managed kubernetes service. For DO it's do-block-storages according to their docs. Also seems to be it's not necessary to define PVC, helm chart should do it itself.

Here's config I'm using

# Specify node pool
nodeSelector:
    doks.digitalocean.com/node-pool: elasticsearch

# Shrink default JVM heap.
esJavaOpts: "-Xmx128m -Xms128m"

# Allocate smaller chunks of memory per pod.
resources:
  requests:
    cpu: "100m"
    memory: "512M"
  limits:
    cpu: "1000m"
    memory: "512M"

# Specify Digital Ocean storage
# Request smaller persistent volumes.
volumeClaimTemplate:
  accessModes: [ "ReadWriteOnce" ]
  storageClassName: do-block-storage
  resources:
    requests:
      storage: 10Gi
extraInitContainers: |
  - name: create
    image: busybox:1.28
    command: ['mkdir', '/usr/share/elasticsearch/data/nodes/']
    volumeMounts:
    - mountPath: /usr/share/elasticsearch/data
      name: elasticsearch-master
  - name: file-permissions
    image: busybox:1.28
    command: ['chown', '-R', '1000:1000', '/usr/share/elasticsearch/']
    volumeMounts:
    - mountPath: /usr/share/elasticsearch/data
      name: elasticsearch-master

Helm chart i'm setting with terraform, but it doesn't matter anyway, which way you'll do it:

resource "helm_release" "elasticsearch" {
  name      = "elasticsearch"
  chart     = "elastic/elasticsearch"
  namespace = "elasticsearch"

  values = [
    file("charts/elasticsearch.yaml")
  ]
}

Here's what I've got when checking pod logs:

51s         Normal    Provisioning           persistentvolumeclaim/elasticsearch-master-elasticsearch-master-2   External provisioner is provisioning volume for claim "elasticsearch/elasticsearch-master-elasticsearch-master-2"
2m28s       Normal    ExternalProvisioning   persistentvolumeclaim/elasticsearch-master-elasticsearch-master-2   waiting for a volume to be created, either by external provisioner "dobs.csi.digitalocean.com" or manually created by system administrator

I'm pretty sure the problem is a volume. it should've been automagically provided by kubernetes. Describing persistent storage gives this:

holms@debian ~/D/c/s/b/t/s/post-infra> kubectl describe pvc elasticsearch-master-elasticsearch-master-0 --namespace elasticsearch
Name:          elasticsearch-master-elasticsearch-master-0
Namespace:     elasticsearch
StorageClass:  do-block-storage
Status:        Pending
Volume:        
Labels:        app=elasticsearch-master
Annotations:   volume.beta.kubernetes.io/storage-provisioner: dobs.csi.digitalocean.com
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Mounted By:    elasticsearch-master-0
Events:
  Type    Reason                Age                    From                                                                              Message
  ----    ------                ----                   ----                                                                              -------
  Normal  Provisioning          4m57s (x176 over 14h)  dobs.csi.digitalocean.com_master-setupad-eu_04e43747-fafb-11e9-b7dd-e6fd8fbff586  External provisioner is provisioning volume for claim "elasticsearch/elasticsearch-master-elasticsearch-master-0"
  Normal  ExternalProvisioning  93s (x441 over 111m)   persistentvolume-controller                                                       waiting for a volume to be created, either by external provisioner "dobs.csi.digitalocean.com" or manually created by system administrator

I've google everything already, it seems to be everything is correct, and volume should be up withing DO side with no problems, but it hangs in pending state. Is this expected behavior or should I ask DO support to check what's going on their side?


Solution

  • What a strange situation, after I've changed 10Gi to 10G it started to work. Maybe it has to do something with a storage class it's self, but it started to work.