Digital Ocean управляет томом Kubernetes в состоянии ожидания

Это не настолько специфично для цифрового океана, было бы действительно неплохо проверить, является ли это ожидаемым поведением или нет.

Я пытаюсь настроить кластер ElasticSearch на управляемом DO кластере Kubernetes с помощью Helm-диаграммы из ElasticSearch сам

И они говорят, что мне нужно указать storageClassName в volumeClaimTemplate, чтобы использовать том, который предоставляется управляемой службой Kubernetes. Для DO это do-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")
  ]
}

Вот что я получил при проверке журналов модуля:

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

Я почти уверен, что проблема в томе. он должен был быть предоставлен кубернетами автоматически. Описание постоянного хранилища дает следующее:

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 без проблем, но зависает в состоянии ожидания. Это ожидаемое поведение или мне следует обратиться в службу поддержки, чтобы узнать, что происходит на их стороне?


kubernetes digital-ocean volumes
person holms    schedule 05.11.2019    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Да, это ожидаемое поведение. Эта диаграмма может быть несовместима с сервисом Digital Ocean Kubernetes.

Документация Digital Ocean содержит следующую информацию в разделе "Известные проблемы":

  • Поддержка изменения размеров блочного хранилища DigitalOcean в Kubernetes еще не реализована.

  • В панели управления DigitalOcean ресурсы кластера (рабочие узлы, балансировщики нагрузки и тома блочного хранилища) перечислены за пределами страницы Kubernetes. Если вы переименуете или иным образом измените эти ресурсы на панели управления, вы можете сделать их непригодными для использования в кластере или заставить согласователь выделить ресурсы для замены. Чтобы этого избежать, управляйте ресурсами кластера исключительно с помощью kubectl или со страницы панели управления Kubernetes.

В диаграммах / stable / elasticsearch есть определенные упомянутые требования:

Предварительные условия Подробности

  • Kubernetes 1.10+
  • Поддержка динамического выделения ресурсов PV в базовой инфраструктуре

Вы можете обратиться за помощью в службу поддержки Digital Ocean или попробовать развернуть ElasticSearch без Helm Chart.

Это даже упоминается на 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

ПВХ, наконец, был связан.

$ 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 по поводу решения для автоматического выделения томов.

person Piotr Malec    schedule 05.11.2019
comment
digitalocean.com/docs/kubernetes/how-to/add-volumes а вроде можно ли требовать ПВХ ..? Я хоть штурвал-то же нет? - person holms; 06.11.2019
comment
: D Я только что ответил, что у меня сработало. Как видите, это должно было быть 10G вместо 10Gi. IDK, почему это работает, но работает, и я могу воспроизвести эту ошибку в DO k8s - person holms; 12.11.2019

arrow_upward
-1
arrow_downward

Какая странная ситуация, после того, как я изменил 10Gi на 10G, она начала работать. Возможно, он должен что-то делать с классом хранения, но он начал работать.

person holms    schedule 11.11.2019