distribuire lo stack elk in kubernetes con errore VolumeBinding helm
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 pods
comando, 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 slow
e la richiesta di volume persistente claim1
sono i miei esperimenti. kubectl create
Li 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
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"