distribuire lo stack elk in kubernetes con errore VolumeBinding helm

Aug 24 2020

Sto cercando di distribuire lo stack di alci nel cluster Kubernetes con helm, utilizzando questo grafico. Quando lancio

helm install elk-stack stable/elastic-stack

Ricevo il seguente messaggio:

NOME: elk-stack
ULTIMO DISTRIBUZIONE: lunedì 24 agosto 07:30:31 2020
NAMESPACE: predefinito
STATO: schierato
REVISIONE: 1
APPUNTI:
Il cluster elasticsearch e gli extra associati sono stati installati.
Si può accedere a Kibana:

  * All'interno del tuo cluster, al seguente nome DNS sulla porta 9200:

    elk-stack-elastic-stack.default.svc.cluster.local

  * Dall'esterno del cluster, esegui questi comandi nella stessa shell:

    esporta POD_NAME =$(kubectl get pods --namespace default -l "app=elastic-stack,release=elk-stack" -o jsonpath="{.items[0].metadata.name}")
    echo "Visit http://127.0.0.1:5601 to use Kibana"
    kubectl port-forward --namespace default $POD_NAME 5601: 5601

Ma quando corro

kubectl ottieni pod

il risultato è:

NOME READY STATUS RIAVVIA L'ETÀ
elk-stack-elasticsearch-client-7fcfc7b858-5f7fw 0/1 In esecuzione 0 12 m
elk-stack-elasticsearch-client-7fcfc7b858-zdkwd 0/1 In esecuzione 1 12 m
elk-stack-elasticsearch-data-0 0/1 In attesa 0 12m
elk-stack-elasticsearch-master-0 0/1 In attesa di 0 12m
elk-stack-kibana-cb7d9ccbf-msw95 1/1 In esecuzione 0 12m
elk-stack-logstash-0 0/1 In attesa 0 12m

Usando il kubectl describe podscomando, vedo che per i pod elasticsearch il problema è:

 Avviso FailedScheduling 6m29s default-scheduler che esegue il plug-in di filtro "VolumeBinding" per il pod "elk-stack-elasticsearch-data-0": il pod ha un binding PersistentVolumeClaims immediato

e per i pod logstash:

Avviso FailedScheduling 7m53s default-scheduler che esegue il plug-in di filtro "VolumeBinding" per il pod "elk-stack-logstash-0": il pod ha un binding PersistentVolumeClaims immediato

Uscita di kubectl get pv,pvc,sc -A:

NOME CAPACITÀ MODALITÀ DI ACCESSO POLITICA DI RECLAMO STATO RECLAMO ARCHIVIAZIONE CLASSE MOTIVO ETÀ
persistentvolume / elasticsearch-data 10Gi RWO Retain Bound default / elasticsearch-data manual 16d

NOME SPAZIO NOME STATO VOLUME CAPACITÀ MODALITÀ DI ACCESSO STORAGECLASS AGE
default persistentvolumeclaim / claim1 In attesa lento 64m
default persistentvolumeclaim / data-elk-stack-elasticsearch-data-0 In attesa di 120m
default persistentvolumeclaim / data-elk-stack-elasticsearch-master-0 In attesa di 120m
default persistentvolumeclaim / data-elk-stack-logstash-0 In attesa di 120m
default persistentvolumeclaim / elasticsearch-data Bound elasticsearch-data 10Gi RWO manual 16d
default persistentvolumeclaim / elasticsearch-data-elasticsearch-data-0 In attesa 17d
default persistentvolumeclaim / elasticsearch-data-elasticsearch-data-1 In attesa 17d
default persistentvolumeclaim / elasticsearch-data-quickstart-es-default-0 In attesa 16g
default persistentvolumeclaim / elasticsearch-master-elasticsearch-master-0 In attesa 17d
default persistentvolumeclaim / elasticsearch-master-elasticsearch-master-1 In attesa 17d
default persistentvolumeclaim / elasticsearch-master-elasticsearch-master-2 In attesa 16d

NOME SPAZIO NOME FORNITORE RECLAMO VOLUME VINCOLANTE MODO CONSENTITO VOLUME ESPANSIONE ETÀ
            storageclass.storage.k8s.io/slow (predefinito) kubernetes.io/gce-pd Elimina Immediato false 66m

La classe di archiviazione slowe la richiesta di volume persistente claim1sono i miei esperimenti. kubectl createLi creo usando e un file yaml, gli altri vengono creati automaticamente da helm (credo).

Uscita di kubectl get pvc data-elk-stack-elasticsearch-master-0 -o yaml:

apiVersion: v1
tipo: PersistentVolumeClaim
metadati:
  creationTimestamp: "2020-08-24T07: 30: 38Z"
  finalizzatori:
  - kubernetes.io/pvc-protection
  etichette:
    app: elasticsearch
    rilascio: elk-stack
  managedFields:
  - apiVersion: v1
    fieldType: FieldsV1
    fieldsV1:
      f: metadata:
        f: etichette:
          .: {}
          f: app: {}
          f: release: {}
      f: spec:
        f: accessModes: {}
        f: risorse:
          f: richieste:
            .: {}
            f: archiviazione: {}
        f: volumeMode: {}
      f: stato:
        f: fase: {}
    manager: kube-controller-manager
    operazione: aggiornamento
    ora: "2020-08-24T07: 30: 38Z"
  nome: data-elk-stack-elasticsearch-master-0
  spazio dei nomi: predefinito
  resourceVersion: "201123"
  selfLink: / api / v1 / namespaces / default / persistentvolumeclaims / data-elk-stack-elasticsearch-master-0
  uid: de58f769-f9a7-41ad-a449-ef16d4b72bc6
spec:
  accessModes:
  - ReadWriteOnce
  risorse:
    richieste:
      archiviazione: 4Gi
  volumeMode: filesystem
stato:
  fase: in sospeso

Qualcuno può aiutarmi a risolvere questo problema? Grazie in anticipo.

Risposte

2 ArghyaSadhu Aug 24 2020 at 20:35

Il motivo per cui il pod è in sospeso è inferiore ai PVC, poiché i PV corrispondenti non vengono creati.

data-elk-stack-elasticsearch-master-0
data-elk-stack-logstash-0
data-elk-stack-elasticsearch-data-0

Dato che hai detto che questo è per lo sviluppo locale, puoi usare il volume hostPath per il PV. Quindi crea PV per ciascuno dei PVC in sospeso utilizzando il PV di esempio di seguito. Quindi creerai 3 PV in totale.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: elk-master
  labels:
    type: local
spec:
  capacity:
    storage: 4Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: elk-logstash
  labels:
    type: local
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: elk-data
  labels:
    type: local
spec:
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"