<p>I follow <a href="https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/master/deploy/single/all-in-one-postgres.yaml" rel="nofollow noreferrer">this</a> to install kong-ingress-controller in my master node. But when I deploy postgres-0 it created volume which is pending. I using my own cloud. Here is my yaml to create persistanvolume: </p>

<pre><code>apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgre-pv-volume
  namespace : kong
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/var/lib/postgresql/data"
</code></pre>

<p>When I run <code>kubectl describe pod postgres-0 -n kong</code>   </p>

<p>Result:</p>

<pre><code>Name:           postgres-0
Namespace:      kong
Priority:       0
Node:           &lt;none&gt;
Labels:         app=postgres
                controller-revision-hash=postgres-59ccf8fcf7
                statefulset.kubernetes.io/pod-name=postgres-0
Annotations:    &lt;none&gt;
Status:         Pending
IP:             
IPs:            &lt;none&gt;
Controlled By:  StatefulSet/postgres
Containers:
  postgres:
    Image:      postgres:9.5
    Port:       5432/TCP
    Host Port:  0/TCP
    Environment:
      POSTGRES_USER:      kong
      POSTGRES_PASSWORD:  kong
      POSTGRES_DB:        kong
      PGDATA:             /var/lib/postgresql/data/pgdata
    Mounts:
      /var/lib/postgresql/data from datadir (rw,path="pgdata")
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-g7828 (ro)
Conditions:
  Type           Status
  PodScheduled   False 
Volumes:
  datadir:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  datadir-postgres-0
    ReadOnly:   false
  default-token-g7828:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-g7828
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  &lt;none&gt;
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  &lt;unknown&gt;  default-scheduler  pod has unbound immediate PersistentVolumeClaims
  Warning  FailedScheduling  &lt;unknown&gt;  default-scheduler  pod has unbound immediate PersistentVolumeClaims
</code></pre>

<p>Please help me. Thanks</p>

Akashii
<p>Problem may lay in bad or none configuration of <a href="https://kubernetes.io/docs/concepts/storage/storage-classes/" rel="nofollow noreferrer">StorageClass</a>. </p>

<p><strong>1.</strong> Firstly you have to ensure that you have storageclass called manual.</p>

<pre><code>$ kubectl get storageclass
</code></pre>

<p>The name of a StorageClass object is significant, and is how users can request a particular class. </p>

<p><strong>2.</strong> To create StorageClass you have to define configuration file, here is example:</p>

<pre><code>apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: manual
provisioner: xxx
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate
</code></pre>

<p>Storage classes have a <a href="https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner" rel="nofollow noreferrer">provisioner</a> that determines what volume plugin is used for provisioning PVs. This field must be specified (xxx).</p>

<p>Take note on such definition:</p>

<pre><code>apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
</code></pre>

<p><a href="https://kubernetes.io/docs/concepts/storage/storage-classes/#local" rel="nofollow noreferrer">Local volumes</a>  do not currently support dynamic provisioning, however a StorageClass should still be created to delay volume binding until pod scheduling. This is specified by the WaitForFirstConsumer volume binding mode.</p>

<p>Delaying volume binding allows the scheduler to consider all of a pod’s scheduling constraints when choosing an appropriate PersistentVolume for a PersistentVolumeClaim.</p>

<p>Let me know if it helps.</p>
