elasticsearch Digital Ocean管理的Kubernetes卷处于挂起状态

pqwbnv8z  于 6个月前  发布在  ElasticSearch
关注(0)|答案(3)|浏览(67)

这不是数字海洋的具体情况,如果能验证这是否是预期的行为,那就太好了。
我正在尝试使用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设置舵手图,但无论如何,这并不重要,你会这样做:

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支持,以检查他们那边发生了什么?

llycmphe

llycmphe1#

是的,这是预期行为。此图表可能与Digital Ocean Kubernetes服务不兼容。
Digital Ocean文档中的“已知问题”部分包含以下信息:

  • 尚未在Kubernetes中实现对DigitalOcean Block Storage的支持。
  • 在DigitalOcean控制面板中,群集资源(工作节点、负载均衡器和块存储卷)列在Kubernetes页面之外。如果您在控制面板中重命名或以其他方式修改这些资源,可能会使它们无法用于集群或导致协调器调配替换资源。为避免这种情况,使用kubectl或从控制面板的Kubernetes页面专门管理集群资源。

在charts/stable/elasticsearch中提到了具体的要求:

预约详情

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

您可以向Digital Ocean支持部门寻求帮助,或者尝试部署没有Helm Chart的ElasticSearch。
在github上也提到:
此图表的自动测试目前仅针对GKE(Google Kubernetes Engine)运行。

更新:

同样的问题也出现在我的kubeadm ha集群上。
然而,我设法让它工作,手动创建PersistentVolumes的为我的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

我的PersistentVolume定义: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 Chart:

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支持自动卷配置解决方案。

oipij1gg

oipij1gg2#

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

x6h2sr28

x6h2sr283#

这是一个多么奇怪的情况,在我把10Gi改为10G之后,它开始工作了。也许它必须做一些与它自己的存储类有关的事情,但它开始工作了。

相关问题