思考题，我的理解：
因为当一个pvc创建之后，kubernetes因为dynamic provisioning机制会调用pvc指定的storageclass里的provisioner自动使用local disk的信息去创建pv。而且pv一旦创建，nodeaffinity参数就指定了固定的node。而此时，provisioner并没有pod调度的相关信息。
延迟绑定发生的时机是pod已经进入调度器。此时对应的pv已经创建，绑定了node。并可能与pod的调度信息发生冲突。
如果dynamic provisioning机制能够推迟到pod 调度的阶段，同时考虑pod调度条件和node硬件信息，这样才能实现dynamic provisioning。实现上可以参考延迟绑定，来一个延迟 provision。另外实现一个controller在pod调度阶段创建pv。

liuchjlu
请教一个问题，当使用Local Persistent Volume的时候，pv中声明的local path如果所在节点没有这个目录会不会自动创建？


我的理解是：pv无论是使用NAS或者其他的存储，还是local persistent volume，都是infra的童鞋帮忙先规划好的存储区域。那么你在写这个pv的时候，要确保这块存储可用，比如目录存在。

按照文章测试了下，指定了单个节点，报如下错误什么原因呢？
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      #nodeSelector:
       #zone: node-1
      nodeName: kubernetes-node-1 #指定调度节点为 kubernetes-node-1
      containers:
      - name: nginx-pv-container
        image: nginx:1.10.3
        imagePullPolicy: IfNotPresent
        ports:
         - containerPort: 80
        volumeMounts:
            - name: example-pv-storage
              mountPath: "/usr/share/nginx/html"
      volumes:
      - name: example-pv-storage
        persistentVolumeClaim:
          claimName: example-local-claim

Unable to mount volumes for pod "nginx-deployment-77489d8d4c-4bl22_default(5c22d166-e440-11e8-90ea-0050569f4a19)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-deployment-77489d8d4c-4bl22". list of unmounted volumes=[example-pv-storage]. list of unattached volumes=[example-pv-storage default-token-7c4cf]