Digital Ocean管理的Kubernetes数量处于待定状态 先决条件详细信息

不是特定于数字海洋的,非常好的去验证这是否是预期的行为。

我正在尝试使用来自ElasticSearch itself的掌舵图在DO管理的Kubernetes集群上设置ElasticSearch集群

他们说我需要在storageclassname中指定一个volumeclaimTemplate才能使用托管kubernetes服务提供的卷。对于DO,根据其docsdo-block-storages。似乎也不必定义PVC,掌舵图应自行完成。

我正在使用的配置

# 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

我已经在Google上搜索了所有内容,似乎一切都正确,并且DO端的音量应该没有问题,但是它挂起了挂起状态。这是预期的行为吗?还是我应该请DO支持人员检查他们的情况?

pipi0462 回答:Digital Ocean管理的Kubernetes数量处于待定状态 先决条件详细信息

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

Digital Ocean文档在“已知问题”部分中包含以下信息:

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

  •   
  • 在DigitalOcean控制面板中,群集资源(工作节点,负载平衡器和块存储卷)列在Kubernetes页面的外部。如果您在控制面板中重命名或以其他方式修改这些资源,则可能使它们对群集不可用,或导致协调程序调配替换资源。为避免这种情况,请仅使用kubectl或从控制面板的Kubernetes页面管理群集资源。

  •   

charts/stable/elasticsearch中提到了一些具体要求:

  

先决条件详细信息

     
      
  • Kubernetes 1.10 +
  •   
  • 基础架构上的PV动态预配置支持
  •   

您可以向Digital Ocean支持寻求帮助,或者尝试在没有头盔图的情况下部署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 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支持人员联系以获取自动卷配置解决方案。

,

在将10Gi更改为10G之后,它开始起作用了,这真是一个奇怪的情况。也许它必须对自己的存储类做些事情,但是它开始起作用。

本文链接:https://www.f2er.com/3159368.html

大家都在问