Consul-helm: pod has unbound immediate persistentvolumeclaims
Hi I am trying to run consul on Kubernetes using the repo. I get the error "pod has unbound immediate persistentvolumeclaims ". The server pods don't start up.
Thanks and Regards
Siddharth
siddharthsethi11
All 19 comments
Hey @siddharthsethi11 I started to get this issue as well, are you deploying on a multinode kubernetes environment and which is your cloud provider? If possible you might want to toggle with setting the podAffinity to null.
ALuongIBM
on 26 Sep 2019
@siddharthsethi11 Do your pods show these events?
https://github.com/hashicorp/consul-helm/issues/229
ALuongIBM
on 26 Sep 2019
I would suggest creating PV manually before your deploy the helm chart with the ClaimRef inside , referring to to the PVC created for consul . perhaps it is ugly but I guess that should fix it.
HeshamAboElMagd
on 1 Oct 2019
@HeshamAboElMagd Do you mind elaborating on how to do that?
ALuongIBM
on 1 Oct 2019
create PV like the one below and then when you deploy the chart , it will find the PV to attach(bound) the PVC to , thus you wouldn't get the unbound error
apiVersion: v1
kind: PersistentVolume
metadata:
name: data-consul-pv0
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
claimRef:
namespace: consul
name: data-consul-pvc0
hostPath:
path: "/mnt/data"
Intersting @HeshamAboElMagd, have you played around with volumeBindingMode: WaitForFirstConsumer in the storage class? I found my cloud provider was using Immediate instead of WaitForFirstConsumer.
blhagadorn
on 2 Oct 2019
@siddharthsethi11 what platform are you running Kubernetes on, e.g. EKS, GKE, your own, etc.
Can you run a kubectl get pvc and kubectl get pv and a kubectl describe on the pvcs and pvs?
In the end you're going to need to debug why the PVCs aren't creating volumes.
lkysow
on 9 Oct 2019
I'm going to close this for now since we haven't heard back but feel free to comment and I can reopen.
lkysow
on 28 Oct 2019
I'm running into this as well. I setup a 4 node Kubernetes cluster using Kubespray and I've created 3 PV's (the documentation doesn't mention this as a requirement) like so:
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv0
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
claimRef:
namespace: consul
name: data-consul-pvc0
hostPath:
path: "/mnt/data/pv0"
---
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv1
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
claimRef:
namespace: consul
name: data-consul-pvc1
hostPath:
path: "/mnt/data/pv1"
---
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv2
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
claimRef:
namespace: consul
name: data-consul-pvc2
hostPath:
path: "/mnt/data/pv2"
Shows they are available:
[root@kube02 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
data-consul-pv0 1Gi RWO Recycle Available consul/data-consul-pvc0 manual 5m49s
data-consul-pv1 1Gi RWO Recycle Available consul/data-consul-pvc1 manual 5m49s
data-consul-pv2 1Gi RWO Recycle Available consul/data-consul-pvc2 manual 5m49s
Describe PV:
[root@kube02 ~]# kubectl describe pv
Name: data-consul-pv0
Labels: type=local
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass: manual
Status: Available
Claim: consul/data-consul-pvc0
Reclaim Policy: Recycle
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/data/pv0
HostPathType:
Events: <none>
Name: data-consul-pv1
Labels: type=local
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass: manual
Status: Available
Claim: consul/data-consul-pvc1
Reclaim Policy: Recycle
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/data/pv1
HostPathType:
Events: <none>
Name: data-consul-pv2
Labels: type=local
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass: manual
Status: Available
Claim: consul/data-consul-pvc2
Reclaim Policy: Recycle
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/data/pv2
HostPathType:
Events: <none>
Create Consul cluster:
helm install --name hashicorp ./consul-helm
Get pods:
[root@kube02 ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hashicorp-consul-2hlvr 0/1 Running 0 3m33s 10.233.100.8 kube03 <none> <none>
hashicorp-consul-8m55s 0/1 Running 0 3m33s 10.233.98.6 kube01 <none> <none>
hashicorp-consul-f8t5g 0/1 Running 0 3m33s 10.233.87.6 kube02 <none> <none>
hashicorp-consul-lhlvp 0/1 Running 0 3m33s 10.233.89.9 kube04 <none> <none>
hashicorp-consul-server-0 0/1 Pending 0 3m33s <none> <none> <none> <none>
hashicorp-consul-server-1 0/1 Pending 0 3m32s <none> <none> <none> <none>
hashicorp-consul-server-2 0/1 Pending 0 3m32s <none> <none> <none> <none>
View the PVC's:
[root@kube02 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-hashicorp-consul-server-0 Pending 3m54s
data-default-hashicorp-consul-server-1 Pending 3m54s
data-default-hashicorp-consul-server-2 Pending 3m53s
Describe PVC's:
[root@kube02 ~]# kubectl describe pvc
Name: data-default-hashicorp-consul-server-0
Namespace: default
StorageClass:
Status: Pending
Volume:
Labels: app=consul
chart=consul-helm
component=server
hasDNS=true
release=hashicorp
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: hashicorp-consul-server-0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal FailedBinding 2m10s (x26 over 8m11s) persistentvolume-controller no persistent volumes available for this claim and no storage class is set
Name: data-default-hashicorp-consul-server-1
Namespace: default
StorageClass:
Status: Pending
Volume:
Labels: app=consul
chart=consul-helm
component=server
hasDNS=true
release=hashicorp
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: hashicorp-consul-server-1
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal FailedBinding 2m11s (x26 over 8m11s) persistentvolume-controller no persistent volumes available for this claim and no storage class is set
Name: data-default-hashicorp-consul-server-2
Namespace: default
StorageClass:
Status: Pending
Volume:
Labels: app=consul
chart=consul-helm
component=server
hasDNS=true
release=hashicorp
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: hashicorp-consul-server-2
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal FailedBinding 2m11s (x26 over 8m11s) persistentvolume-controller no persistent volumes available for this claim and no storage class is set
All three servers are failing with pod has unbound immediate PersistentVolumeClaims (repeated 4 times). Not sure what I'm missing here but I have tried editing the provided values.yml to storage: 1Gi so it would match my PV's which didn't seem to help.
francis826
on 12 Jan 2020
@francis826 This seems to be an issue that comes up a lot as a generic error message ( the pod has unbound immediate PersistentVolumeClaims part, that is).
Would you mind getting the YAML of your default storage class (or the one you are specifying in your Helm chart). I was on IBM Cloud, but adding a custom storage class fixed this error for me. Particularly, I changed the volumeBindingMode. kubectl get storageclasses and then the default one, could you kubectl get storageclass NAMEOFSTORAGECLASS -o yaml?
blhagadorn
on 12 Jan 2020
Or try, kubectl get storageclass default -o yaml
blhagadorn
on 12 Jan 2020
@blhagadorn to be completely honest, I never created a default storage class. I went ahead and created one, but it still isn't working:
Storage Class:
[root@kube02 ~]# cat storageclass.yml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: default
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
Kubectl get storageclass:
[root@kube02 ~]# kubectl get storageclass default -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
creationTimestamp: "2020-01-13T01:57:07Z"
name: default
resourceVersion: "138776"
selfLink: /apis/storage.k8s.io/v1/storageclasses/default
uid: 8f5eba8f-f079-4576-8011-b1692d69d2fc
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
New PV Created:
{
"kind": "PersistentVolume",
"apiVersion": "v1",
"metadata": {
"name": "data-consul-pv0",
"selfLink": "/api/v1/persistentvolumes/data-consul-pv0",
"uid": "ff690d57-b92a-4cda-b464-2b9e5475b0d6",
"resourceVersion": "138808",
"creationTimestamp": "2020-01-13T01:57:22Z",
"labels": {
"type": "local"
},
"finalizers": [
"kubernetes.io/pv-protection"
]
},
"spec": {
"capacity": {
"storage": "1Gi"
},
"hostPath": {
"path": "/mnt/data",
"type": ""
},
"accessModes": [
"ReadWriteOnce"
],
"claimRef": {
"namespace": "consul",
"name": "data-consul-pvc0"
},
"persistentVolumeReclaimPolicy": "Recycle",
"storageClassName": "default",
"volumeMode": "Filesystem"
},
"status": {
"phase": "Available"
}
}
PVC:
{
"kind": "PersistentVolumeClaim",
"apiVersion": "v1",
"metadata": {
"name": "data-default-hashicorp-consul-server-0",
"namespace": "default",
"selfLink": "/api/v1/namespaces/default/persistentvolumeclaims/data-default-hashicorp-consul-server-0",
"uid": "9dcbb1ab-dc89-4246-9237-0caee5e5679f",
"resourceVersion": "139002",
"creationTimestamp": "2020-01-13T01:58:44Z",
"labels": {
"app": "consul",
"chart": "consul-helm",
"component": "server",
"hasDNS": "true",
"release": "hashicorp"
},
"finalizers": [
"kubernetes.io/pvc-protection"
]
},
"spec": {
"accessModes": [
"ReadWriteOnce"
],
"resources": {
"requests": {
"storage": "1Gi"
}
},
"storageClassName": "default",
"volumeMode": "Filesystem"
},
"status": {
"phase": "Pending"
}
}
Servers are still pending with the same error:
[root@kube02 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
hashicorp-consul-9rrxr 0/1 Running 0 6m6s
hashicorp-consul-b75ss 0/1 Running 0 6m6s
hashicorp-consul-np9fd 0/1 Running 0 6m6s
hashicorp-consul-server-0 0/1 Pending 0 6m6s
hashicorp-consul-server-1 0/1 Pending 0 6m6s
hashicorp-consul-server-2 0/1 Pending 0 6m6s
hashicorp-consul-td65m 0/1 Running 0 6m6s
I also updated the values.yml to match:
storage: 1Gi
storageClass: default
@francis826 if you're doing everything manually you need to start with creating the PVCs and then creating the PVs that satisfy the PVCs. From your first post, it looks like you only created the PVs.
The PVCs need to follow a specific naming convention:
https://www.consul.io/docs/platform/k8s/run.html#using-existing-persistent-volume-claims-pvcs-
Here's what my PVCs and PVs look like on GKE for namespace jan7 and release name consul:
k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-jan7-consul-server-0 Bound pvc-65873f38-33cd-11ea-b849-42010a800054 10Gi RWO standard 2d23h
data-jan7-consul-server-1 Bound pvc-66232135-33cd-11ea-b849-42010a800054 10Gi RWO standard 2d23h
data-jan7-consul-server-2 Bound pvc-664e15c9-33cd-11ea-b849-42010a800054 10Gi RWO standard
k get pvc data-jan7-consul-server-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd
creationTimestamp: "2020-01-10T17:19:45Z"
finalizers:
- kubernetes.io/pvc-protection
labels:
app: consul
chart: consul-helm
component: server
hasDNS: "true"
release: consul
name: data-jan7-consul-server-0
namespace: jan7
resourceVersion: "61266054"
selfLink: /api/v1/namespaces/jan7/persistentvolumeclaims/data-jan7-consul-server-0
uid: 65873f38-33cd-11ea-b849-42010a800054
spec:
accessModes:
- ReadWriteOnce
dataSource: null
resources:
requests:
storage: 10Gi
storageClassName: standard
volumeMode: Filesystem
volumeName: pvc-65873f38-33cd-11ea-b849-42010a800054
status:
accessModes:
- ReadWriteOnce
capacity:
storage: 10Gi
phase: Bound
k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-65873f38-33cd-11ea-b849-42010a800054 10Gi RWO Delete Bound jan7/data-jan7-consul-server-0 standard 2d23h
pvc-66232135-33cd-11ea-b849-42010a800054 10Gi RWO Delete Bound jan7/data-jan7-consul-server-1 standard 2d23h
pvc-664e15c9-33cd-11ea-b849-42010a800054 10Gi RWO Delete Bound jan7/data-jan7-consul-server-2 standard 2d23h
You can see that the PVC references the PV via volumeName: pvc-65873f38-33cd-11ea-b849-42010a800054.
lkysow
on 13 Jan 2020
@lkysow Thank you for your response, I'm new to Kubernetes and appreciate your time! I'm even more confused now as I'm just trying follow the simple guide found on https://www.consul.io/docs/platform/k8s/run.html to tinker with Consul. My confusion comes from the helm install command creating PVC's for me which is why I originally only created the PV's, but you're telling me I need to create them beforehand?
[root@kube02 ~]# k get pv
No resources found.
[root@kube02 ~]# k get pvc
No resources found.
[root@kube02 ~]# k get pods
No resources found.
[root@kube02 ~]# helm install --name consul ./consul-helm
NAME: consul
LAST DEPLOYED: Mon Jan 13 21:11:10 2020
NAMESPACE: default
STATUS: DEPLOYED
...
[root@kube02 ~]# k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-consul-consul-server-0 Pending default 4s
data-default-consul-consul-server-1 Pending default 4s
data-default-consul-consul-server-2 Pending default 4s
[root@kube02 ~]# k get pods
NAME READY STATUS RESTARTS AGE
consul-consul-69v6m 0/1 Running 0 3m46s
consul-consul-8qjzv 0/1 Running 0 3m46s
consul-consul-fnvhh 0/1 Running 0 3m46s
consul-consul-g5nvm 0/1 Running 0 3m46s
consul-consul-server-0 0/1 Pending 0 3m46s
consul-consul-server-1 0/1 Pending 0 3m46s
consul-consul-server-2 0/1 Pending 0 3m46s
[root@kube02 ~]# k get pvc data-default-consul-consul-server-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: "2020-01-14T05:11:11Z"
finalizers:
- kubernetes.io/pvc-protection
labels:
app: consul
chart: consul-helm
component: server
hasDNS: "true"
release: consul
name: data-default-consul-consul-server-0
namespace: default
resourceVersion: "339029"
selfLink: /api/v1/namespaces/default/persistentvolumeclaims/data-default-consul-consul-server-0
uid: fe9f7d12-fde4-44b8-915f-19fe83a8e876
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: default
volumeMode: Filesystem
status:
phase: Pending
Up to this point, everything was automated from the helm install, but still failing. I tried creating the PV's manually after (and before hand in a separate attempt) with no luck
[root@kube02 ~]# k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
data-default-consul-consul-server-0 1Gi RWO Recycle Available consul/data-default-consul-consul-server-0 default 34s
data-default-consul-consul-server-1 1Gi RWO Recycle Available consul/data-default-consul-consul-server-1 default 34s
data-default-consul-consul-server-2 1Gi RWO Recycle Available consul/data-default-consul-consul-server-2 default 33s
[root@kube02 ~]# k get pv data-default-consul-consul-server-0 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"data-default-consul-consul-server-0"},"spec":{"accessModes":["ReadWriteOnce"],"capacity":{"storage":"1Gi"},"claimRef":{"name":"data-default-consul-consul-server-0","namespace":"consul"},"hostPath":{"path":"/mnt/data/pv0"},"persistentVolumeReclaimPolicy":"Recycle","storageClassName":"default"}}
creationTimestamp: "2020-01-14T05:20:05Z"
finalizers:
- kubernetes.io/pv-protection
labels:
type: local
name: data-default-consul-consul-server-0
resourceVersion: "340351"
selfLink: /api/v1/persistentvolumes/data-default-consul-consul-server-0
uid: 3425ee77-2a4c-4564-b5dd-b520bbf42c21
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
claimRef:
name: data-default-consul-consul-server-0
namespace: consul
hostPath:
path: /mnt/data/pv0
type: ""
persistentVolumeReclaimPolicy: Recycle
storageClassName: default
volumeMode: Filesystem
status:
phase: Available
Here are some describes for the first servers pod, pvc, and pv:
[root@kube02 ~]# k describe pv data-default-consul-consul-server-0 | grep -E '(Name|Claim)'
Name: data-default-consul-consul-server-0
Claim: consul/data-default-consul-consul-server-0
[root@kube02 ~]# k describe pod consul-consul-server-0 | grep -A4 "Volumes"
Volumes:
data-default:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: data-default-consul-consul-server-0
ReadOnly: false
[root@kube02 ~]# k describe pvc data-default-consul-consul-server-0 | grep -m 1 "Name"
Name: data-default-consul-consul-server-0
i had similar issues - same errors on aws eks. I deleted helm install and the default pvcs created by the helm install and finally edited the values.yaml - that got it working. The default values.yaml creating pvc without a storage class seems to break it.
$ helm delete --purge consul -or whatever you named it
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-consul-consul-server-0 Pending 4h17m
data-default-consul-consul-server-1 Pending 4h17m
data-default-consul-consul-server-2 Pending 4h17m
$ kubectl delete pvc data-default-consul-consul-server-0 data-default-consul-consul-server-1 data-default-consul-consul-server-2
then edit values.yaml server.storageClass with a storage class type - in my case encrypted-gp2
server:
enabled: "-"
image: null
replicas: 3
bootstrapExpect: 3 # Should <= replicas count
# enterpriseLicense refers to a Kubernetes secret that you have created that
# contains your enterprise license. It is required if you are using an
# enterprise binary. Defining it here applies it to your cluster once a leader
# has been elected. If you are not using an enterprise image
# or if you plan to introduce the license key via another route, then set
# these fields to null.
enterpriseLicense:
secretName: null
secretKey: null
# storage and storageClass are the settings for configuring stateful
# storage for the server pods. storage should be set to the disk size of
# the attached volume. storageClass is the class of storage which defaults
# to null (the Kube cluster will pick the default).
storage: 10Gi
storageClass: encrypted-gp2
redeploy helm with values.yaml -
it will now have - mine came up then
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-consul-consul-server-0 Bound pvc-9d556fc3-38d4-11ea-b7bf-021af0f6bf3e 10Gi RWO encrypted-gp2 36s
data-default-consul-consul-server-1 Bound pvc-9d57eddb-38d4-11ea-b7bf-021af0f6bf3e 10Gi RWO encrypted-gp2 36s
data-default-consul-consul-server-2 Bound pvc-9d5a63dd-38d4-11ea-b7bf-021af0f6bf3e 10Gi RWO encrypted-gp2 36s
pkelleratwork
on 17 Jan 2020
@pkelleratwork @francis826 Are you both using GKE? My experience was for IBM Cloud
blhagadorn
on 17 Jan 2020
@blhagadorn - sorry, no, i was on aws eks. thanks for pointing that out - i edited my comment above with that info.
pkelleratwork
on 17 Jan 2020
I'm running bare metal and figured out my issue with the help from everyone here.
root@kube01:~# k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-consul-consul-server-0 Pending fast-disks 3m22s
data-default-consul-consul-server-1 Pending fast-disks 3m22s
data-default-consul-consul-server-2 Pending fast-disks 3m22s
I needed to create 3 volumes for these claims as @lkysow mentioned above:
apiVersion: v1
kind: PersistentVolume
metadata:
name: data-default-consul-consul-server-0
labels:
type: local
spec:
storageClassName: fast-disks
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
apiVersion: v1
kind: PersistentVolume
metadata:
name: data-default-consul-consul-server-1
labels:
type: local
spec:
storageClassName: fast-disks
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
apiVersion: v1
kind: PersistentVolume
metadata:
name: data-default-consul-consul-server-2
labels:
type: local
spec:
storageClassName: fast-disks
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
After applying those, the servers came up and the claims were successful:
root@kube01:~# k get pods
NAME READY STATUS RESTARTS AGE
consul-consul-57r4w 1/1 Running 0 12m
consul-consul-j9sxb 1/1 Running 0 12m
consul-consul-mrk7l 1/1 Running 0 12m
consul-consul-rxqfz 1/1 Running 0 12m
consul-consul-server-0 1/1 Running 0 12m
consul-consul-server-1 1/1 Running 0 12m
consul-consul-server-2 1/1 Running 0 12m
root@kube01:~# k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-default-consul-consul-server-0 Bound data-default-consul-consul-server-0 2Gi RWO fast-disks 16m
data-default-consul-consul-server-1 Bound data-default-consul-consul-server-1 2Gi RWO fast-disks 16m
data-default-consul-consul-server-2 Bound data-default-consul-consul-server-2 2Gi RWO fast-disks 16m
in my case consul is running in personal cluster on IBM Cloud, it was failed binding the pv as no default storageClass in my cluster.
I created 3 volumes for these claims as @lkysow mentioned above with empty storageClass.
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv0
labels:
type: local
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
hostPath:
path: "/mnt/data/pv0"
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv1
labels:
type: local
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
hostPath:
path: "/mnt/data/pv1"
kind: PersistentVolume
apiVersion: v1
metadata:
name: data-consul-pv2
labels:
type: local
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
hostPath:
path: "/mnt/data/pv2"
I changed the values.yaml with empty on storageClass as below:
storage: 10Gi
storageClass:
Then run helm : helm install consul -f values.yaml hashicorp/consul --set global.name=consul
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-consul-consul-server-0 Bound data-consul-pv1 10Gi RWO 2m45s
data-consul-consul-server-1 Bound data-consul-pv0 10Gi RWO 2m45s
data-consul-consul-server-2 Bound data-consul-pv2 10Gi RWO 2m45s
wengzy
on 9 Sep 2020
Related issues
soonoo
路
5Comments
csayler
路
6Comments
iamaverrick
路
5Comments
karras
路
6Comments
Shige99011
路
7Comments
Most helpful comment
I'm running bare metal and figured out my issue with the help from everyone here.
I needed to create 3 volumes for these claims as @lkysow mentioned above:
After applying those, the servers came up and the claims were successful: