Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)'

[garysu]

The PVC claim just sits in a pending state and at API doesn't come up successfully, the Web UI just sits there "Loading".

kubectl version shows:
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

[nmnellis]

Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard
Example of mine

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
parameters:
  type: gp2
provisioner: kubernetes.io/aws-ebs

[garysu]

In AWS, we will eventually move to EKS, but the current cluster was spun up using kops.

…

________________________________ From: Nick <notifications@github.com> Sent: Monday, July 16, 2018 5:53 PM To: nmnellis/vistio Cc: Gary Sumner; Author Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8) Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard Example of mine apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: standard parameters: type: gp2 provisioner: kubernetes.io/aws-ebs — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd>.

[garysu]

Looks like that might be the issue…here is what my storage classes look like: [cid:image001.png@01D41D97.FD1AB480] From: Nick <notifications@github.com> Sent: Monday, July 16, 2018 5:53 PM To: nmnellis/vistio <vistio@noreply.github.com> Cc: Gary Sumner <garysu@seventh-symbol.net>; Author <author@noreply.github.com> Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8) Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard Example of mine apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: standard parameters: type: gp2 provisioner: kubernetes.io/aws-ebs — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd>.

[redstyr]

Same error here. K8s deployed with kubeadm.

  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  17s (x3 over 33s)  default-scheduler  pod has unbound PersistentVolumeClaims

kubectl get storageclass -n istio-system local-storage -oyaml          ⎈ isobox:tethering
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: 2018-07-03T15:48:22Z
  name: local-storage
  resourceVersion: "601"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/local-storage
  uid: 841bab8a-7ed8-11e8-ac4d-005056950510
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

[nmnellis]

this is more of an issue with statefulsets and pvcs than with vistio. Upgrading your kubernetes version to >=1.9 might help fix this issue

[redstyr]

My kube version is v1.10.2

[garysu]

Mine was 1.10.5...I didn’t get to the bottom of the issue as I needed to move on to other work.

…

________________________________ From: Anurag <notifications@github.com> Sent: Thursday, August 9, 2018 2:06 PM To: nmnellis/vistio Cc: Gary Sumner; Author Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8) My kube version is v1.10.2 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ1spiOf-RHTJqJSGiFmafEyxZT0cks5uPKRUgaJpZM4VGfQd>.

[nmnellis]

maybe follow this? helm/charts#5188 (comment)

[SS-TT]

Same issue for me, but I'm using NFS so I don't have any StorageClass.

[donbowman]

AKS also does not have 'standard', it has 'default'.

$ kubectl get sc
NAME                PROVISIONER                AGE
default (default)   kubernetes.io/azure-disk   5d
managed-premium     kubernetes.io/azure-disk   38d

[fjudith]

Works well with rook.

helm install helm/vistio -f helm/vistio/values-with-ingress.yaml --set api.storage.class=rook-ceph-block --name vistio --namespace default

kubectl -n default get pods,svc,pvc -l app=vistio-api,app=vistio-api -o wide

NAME               READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE
pod/vistio-api-0   3/3     Running   0          18m   10.2.240.6   node03   <none>

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
service/vistio-api   ClusterIP   10.3.0.23    <none>        9091/TCP   18m   app=vistio-api,release=vistio

NAME                                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
persistentvolumeclaim/vistio-db-vistio-api-0   Bound    pvc-b220c7ea-f3ff-11e8-9102-960000143fe3   5Gi        RWO            rook-ceph-block   4h59m

[fjudith]

I suggest to not enforce the name of the storageclass.
If left empty ("") PVC will automatically select the (default) storage class.