数字海洋托管的Kubernetes卷处于挂起状态

Question

这并不是特定于DigitalOcean的，确定这是否是预期行为会非常好。

我正在尝试使用来自ElasticSearch itself的helm chart在DO托管的Kubernetes集群上设置ElasticSearch集群。他们说我需要在volumeClaimTemplate中指定storageClassName，以便使用由托管Kubernetes服务提供的卷。对于DO来说，根据他们的docs，应该使用do-block-storages。似乎不需要定义PVC，helm chart应该自己完成。

以下是我正在使用的配置。

# 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

我正在使用 Terraform 设置 Helm chart，但无论你用什么方法都没关系。

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

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

这是我检查 pod 日志时得到的结果：

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

我相当确定问题是卷。这应该由Kubernetes自动提供。描述持久存储如下：

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

我已经谷歌了一切，似乎一切都正确，音量应该在 DO 端内没有问题，但它仍然处于挂起状态。这是预期的行为还是我应该要求 DO 支持检查他们那边发生了什么？

- holms

Answer 1

是的，这是预期的行为。该图表可能与Digital Ocean Kubernetes服务不兼容。

Digital Ocean文档中在已知问题部分提供了以下信息：

• 尚未实现在Kubernetes中调整DigitalOcean块存储卷的支持。

• 在DigitalOcean控制面板中，集群资源（工作节点、负载均衡器和块存储卷）列在Kubernetes页面之外。如果您在控制面板中重命名或以其他方式修改这些资源，则可能使它们对集群无法使用或导致重新协调器提供替换资源。为避免此问题，请仅使用 kubectl 或从控制面板的Kubernetes页面管理您的集群资源。

在charts/stable/elasticsearch中提到了特定的要求：

先决条件详细信息

• Kubernetes 1.10+
• 基础设施上支持PV动态配置

你可以向Digital Ocean支持团队寻求帮助，或尝试在不使用helm chart的情况下部署ElasticSearch。

甚至在github上也提到了：

“目前只针对GKE（Google Kubernetes Engine）运行此图表的自动化测试。”

---

更新：

我的 kubeadm 高可用集群遇到了同样的问题。

不过，我通过手动创建 PersistentVolumes 来为我的 storageclass 实现了工作。

我的 storageclass 定义：storageclass.yaml：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ssd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: pd-ssd

$ kubectl apply -f storageclass.yaml

$ kubectl get sc
NAME   PROVISIONER   AGE
ssd    local         50m

我的持久卷定义：pv.yaml：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: ssd
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - <name of the node>

kubectl apply -f pv.yaml

之后我运行了Helm图表：

helm install stable/elasticsearch --name my-release --set data.persistence.storageClass=ssd,data.storage=30Gi --set data.persistence.storageClass=ssd,master.storage=30Gi

PVC 最终被绑定。

$ kubectl get pvc -A
NAMESPACE   NAME                                     STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
default     data-my-release-elasticsearch-data-0     Bound     task-pv-volume2   30Gi       RWO            ssd            17m
default     data-my-release-elasticsearch-master-0   Pending                                                              17m

请注意，我只手动满足单个PVC，ElasticSearch手动卷配额可能非常低效。

我建议联系DO支持以获取自动化卷配额解决方案。

- Piotr Malec

---

https://www.digitalocean.com/docs/kubernetes/how-to/add-volumes/ 但是好像可以声明PVC吗？我以为Helm Chart也能做同样的事情，不是吗？ - undefined

:D 我刚刚回答了对我有用的内容。正如你所看到的，它应该只是 10G 而不是 10Gi。我不知道为什么这样可以工作，但它可以工作，并且我可以在 DO k8s 中重现此错误。 - undefined

Answer 2

使用do-block-storage-xfs，并记住它的最低内存限制要求为2GB。

- Henadzi Rabkin

Answer 3

什么奇怪的情况，我把10Gi改成10G之后它就开始工作了。也许这与存储类本身有关，但它开始工作了。

- holms