參考文獻(xiàn)：https://blog.csdn.net/networken/article/details/86697018
本篇文章絕大部分（幾乎完全）復(fù)制粘貼，他的文章給了我很大幫助，現(xiàn)在在這里寫這篇文章，一是為了記錄，CSDN有時(shí)候文章會(huì)損壞或者服務(wù)器正在維修，二是我覺得這是一個(gè)很好的文章，自己收藏；三是自己遇到了問題，記錄一下

NFS簡介
NFS是網(wǎng)絡(luò)文件系統(tǒng)Network File System的縮寫，NFS服務(wù)器可以讓PC將網(wǎng)絡(luò)中的NFS服務(wù)器共享的目錄掛載到本地的文件系統(tǒng)中，而在本地的系統(tǒng)中來看，那個(gè)遠(yuǎn)程主機(jī)的目錄就好像是自己的一個(gè)磁盤分區(qū)一樣。

kubernetes使用NFS共享存儲(chǔ)有兩種方式：

1.手動(dòng)方式靜態(tài)創(chuàng)建所需要的PV和PVC。
2.通過創(chuàng)建PVC動(dòng)態(tài)地創(chuàng)建對(duì)應(yīng)PV，無需手動(dòng)創(chuàng)建PV。
下面對(duì)這兩種方式進(jìn)行配置并進(jìn)行演示。

搭建NFS服務(wù)器
k8s集群準(zhǔn)備，以這篇文章為例：https://blog.csdn.net/networken/article/details/84991940

我的集群是一主一從，master的IP是192.168.88.111,node1的IP是192.168.88.114

這里作為測試，臨時(shí)在master節(jié)點(diǎn)上部署NFS服務(wù)器。

#master節(jié)點(diǎn)安裝nfs
yum -y install nfs-utils

#創(chuàng)建nfs目錄
mkdir -p /nfs/data/

#修改權(quán)限
chmod -R 777 /nfs/data

#編輯export文件,這個(gè)文件就是nfs默認(rèn)的配置文件
vim /etc/exports
/nfs/data *(rw,no_root_squash,sync)

#配置生效
exportfs -r
#查看生效
exportfs

#啟動(dòng)rpcbind、nfs服務(wù)
systemctl restart rpcbind && systemctl enable rpcbind
systemctl restart nfs && systemctl enable nfs

#查看 RPC 服務(wù)的注冊狀況
rpcinfo -p localhost

#showmount測試
showmount -e 192.168.88.111

所有node節(jié)點(diǎn)安裝客戶端，開機(jī)啟動(dòng)

yum -y install nfs-utils
systemctl start nfs && systemctl enable nfs

作為準(zhǔn)備工作，我們已經(jīng)在 k8s-master(192.168.88.111) 節(jié)點(diǎn)上搭建了一個(gè) NFS 服務(wù)器，目錄為 /nfs/data

靜態(tài)申請(qǐng)PV卷
添加pv卷對(duì)應(yīng)目錄,這里創(chuàng)建2個(gè)pv卷，則添加2個(gè)pv卷的目錄作為掛載點(diǎn)。

#創(chuàng)建pv卷對(duì)應(yīng)的目錄
mkdir -p /nfs/data/pv001

#配置exportrs(我覺得可以不用這步，因?yàn)楦改夸?nfs/data，已經(jīng)設(shè)為共享文件夾)
vim /etc/exports
/nfs/data *(rw,no_root_squash,sync)
/nfs/data/pv001 *(rw,no_root_squash,sync)

#配置生效
exportfs -r
#重啟rpcbind、nfs服務(wù)
systemctl restart rpcbind && systemctl restart nfs

創(chuàng)建PV
下面創(chuàng)建名為pv001的PV卷，配置文件 nfs-pv001.yaml 如下：

[centos@k8s-master ~]$ vim nfs-pv001.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv001
labels:
  pv: nfs-pv001
spec:
capacity:
  storage: 1Gi
accessModes:
  - ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
  path: /nfs/data/pv001
  server: 192.168.88.111

配置說明：
① capacity 指定 PV 的容量為 1G。
② accessModes 指定訪問模式為 ReadWriteOnce，支持的訪問模式有：

2.1ReadWriteOnce – PV 能以 read-write 模式 mount 到單個(gè)節(jié)點(diǎn)。
2.2ReadOnlyMany – PV 能以 read-only 模式 mount 到多個(gè)節(jié)點(diǎn)。
2.3ReadWriteMany – PV 能以 read-write 模式 mount 到多個(gè)節(jié)點(diǎn)。
③ persistentVolumeReclaimPolicy 指定當(dāng) PV 的回收策略為 Recycle，支持的策略有：

3.1Retain – 需要管理員手工回收。
3.2Recycle – 清除 PV 中的數(shù)據(jù)，效果相當(dāng)于執(zhí)行 rm -rf /thevolume/*。
3.3Delete – 刪除 Storage Provider 上的對(duì)應(yīng)存儲(chǔ)資源，例如 AWS EBS、GCE PD、Azure
Disk、OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 為 nfs。相當(dāng)于為 PV 設(shè)置了一個(gè)分類，PVC 可以指定 class 申請(qǐng)相應(yīng) class 的 PV。
⑤ 指定 PV 在 NFS 服務(wù)器上對(duì)應(yīng)的目錄。

創(chuàng)建 pv：

[centos@k8s-master ~]$ kubectl apply -f nfs-pv001.yaml 
persistentvolume/nfs-pv001 created

[centos@k8s-master ~]$ kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv001   1Gi        RWO            Recycle          Available           nfs                     4s

STATUS 為 Available，表示 pv就緒，可以被 PVC 申請(qǐng)。
創(chuàng)建PVC
接下來創(chuàng)建一個(gè)名為pvc001的PVC，配置文件 nfs-pvc001.yaml 如下：

[centos@k8s-master ~]$ vim nfs-pvc001.yaml               
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc001
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs
  selector:
    matchLabels:
      pv: nfs-pv001

執(zhí)行yaml文件創(chuàng)建 pvc：

[centos@k8s-master ~]$ kubectl apply -f nfs-pvc001.yaml 
persistentvolumeclaim/nfs-pvc001 created

[centos@k8s-master ~]$ kubectl get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc001   Bound    pv001    1Gi        RWO            nfs            6s

[centos@k8s-master ~]$ kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
nfs-pv001   1Gi        RWO            Recycle          Bound    default/pvc001   nfs                     9m12s

從 kubectl get pvc 和 kubectl get pv 的輸出可以看到 pvc001綁定到pv001，申請(qǐng)成功。注意pvc綁定到對(duì)應(yīng)pv通過labels標(biāo)簽方式實(shí)現(xiàn)，也可以不指定，將隨機(jī)綁定到pv。
接下來就可以在 Pod 中使用存儲(chǔ)了，Pod 配置文件 nfs-pod001.yaml 如下：

[centos@k8s-master ~]$ vim nfs-pod001.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: nfs-pod001
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: nfs-pv001
  volumes:
    - name: nfs-pv001
      persistentVolumeClaim:
        claimName: nfs-pvc001

與使用普通 Volume 的格式類似，在 volumes 中通過 persistentVolumeClaim 指定使用nfs-pvc001申請(qǐng)的 Volume。
執(zhí)行yaml文件創(chuàng)建nfs-pdo001：

[centos@k8s-master ~]$ kubectl apply -f nfs-pod001.yaml 
pod/nfs-pod001 created

[centos@k8s-master ~]$ kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-75bf876d88-sqqpv   1/1     Running   0          25m
nfs-pod001                                1/1     Running   0          12s

驗(yàn)證 PV 是否可用：

[centos@k8s-master ~]$ kubectl exec nfs-pod001 touch /var/www/html/index001.html                  

[centos@k8s-master ~]$ ls /nfs/data/pv001/
index001.html

進(jìn)入pod查看掛載情況

[centos@k8s-master ~]$ kubectl exec -it nfs-pod001 /bin/bash
root@nfs-pod001:/# df -h
......
192.168.92.56:/nfs/data/pv001   47G  5.2G   42G  11% /var/www/html
......
root@nfs-pod001:/# 

刪除pv
刪除pod，pv和pvc不會(huì)被刪除，nfs存儲(chǔ)的數(shù)據(jù)不會(huì)被刪除。

[centos@k8s-master ~]$ kubectl delete -f nfs-pod001.yaml 
pod "nfs-pod001" deleted

[centos@k8s-master ~]$ kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
nfs-pv001   1Gi        RWO            Recycle          Bound    default/pvc001   nfs                     34m

[centos@k8s-master ~]$ kubectl get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc001   Bound    pv001    1Gi        RWO            nfs            25m

[centos@k8s-master ~]$ ls /nfs/data/pv001/
index001.html

繼續(xù)刪除pvc，pv將被釋放，處于 Available 可用狀態(tài)，并且nfs存儲(chǔ)中的數(shù)據(jù)被刪除。

[centos@k8s-master ~]$ kubectl delete -f nfs-pvc001.yaml 
persistentvolumeclaim "nfs-pvc001" deleted

[centos@k8s-master ~]$ kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM            STORAGECLASS   REASON   AGE
nfs-pv001   1Gi        RWO            Recycle          Available                    nfs                     35m

[centos@k8s-master ~]$ ls /nfs/data/pv001/
[centos@k8s-master ~]$ 

繼續(xù)刪除pv

[centos@k8s-master ~]$ kubectl delete -f nfs-pv001.yaml 
persistentvolume "pv001" deleted

動(dòng)態(tài)申請(qǐng)PV卷
External NFS驅(qū)動(dòng)的工作原理
K8S的外部NFS驅(qū)動(dòng)，可以按照其工作方式（是作為NFS server還是NFS client）分為兩類：
1.nfs-client:
也就是我們接下來演示的這一類，它通過K8S的內(nèi)置的NFS驅(qū)動(dòng)掛載遠(yuǎn)端的NFS服務(wù)器到本地目錄；然后將自身作為storage provider，關(guān)聯(lián)storage class。當(dāng)用戶創(chuàng)建對(duì)應(yīng)的PVC來申請(qǐng)PV時(shí)，該provider就將PVC的要求與自身的屬性比較，一旦滿足就在本地掛載好的NFS目錄中創(chuàng)建PV所屬的子目錄，為Pod提供動(dòng)態(tài)的存儲(chǔ)服務(wù)。
2.nfs:
與nfs-client不同，該驅(qū)動(dòng)并不使用k8s的NFS驅(qū)動(dòng)來掛載遠(yuǎn)端的NFS到本地再分配，而是直接將本地文件映射到容器內(nèi)部，然后在容器內(nèi)使用ganesha.nfsd來對(duì)外提供NFS服務(wù)；在每次創(chuàng)建PV的時(shí)候，直接在本地的NFS根目錄中創(chuàng)建對(duì)應(yīng)文件夾，并export出該子目錄。
利用NFS動(dòng)態(tài)提供Kubernetes后端存儲(chǔ)卷
本文將介紹使用nfs-client-provisioner這個(gè)應(yīng)用，利用NFS Server給Kubernetes作為持久存儲(chǔ)的后端，并且動(dòng)態(tài)提供PV。前提條件是有已經(jīng)安裝好的NFS服務(wù)器，并且NFS服務(wù)器與Kubernetes的Slave節(jié)點(diǎn)都能網(wǎng)絡(luò)連通。將nfs-client驅(qū)動(dòng)做一個(gè)deployment部署到K8S集群中，然后對(duì)外提供存儲(chǔ)服務(wù)。
nfs-client-provisioner 是一個(gè)Kubernetes的簡易NFS的外部provisioner，本身不提供NFS，需要現(xiàn)有的NFS服務(wù)器提供存儲(chǔ)

部署nfs-client-provisioner
(在master上操作，即192.168.88.111)
首先克隆倉庫獲取yaml文件

git clone https://github.com/kubernetes-incubator/external-storage.git
cp -R external-storage/nfs-client/deploy/ $HOME
cd deploy

修改deployment.yaml文件
這里修改的參數(shù)包括NFS服務(wù)器所在的IP地址（192.168.88.111），以及NFS服務(wù)器共享的路徑（/nfs/data），兩處都需要修改為你實(shí)際的NFS服務(wù)器和共享目錄。

[root@K8S-M1 deploy]# cat deployment.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.88.111
            - name: NFS_PATH
              value: /nfs/data
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.88.111
            path: /nfs/data

這里我就有點(diǎn)疑惑了，這里既部署了deployment，也部署了ServiceAccount，在后面的rbac.yaml里也有同樣的，所以我認(rèn)為是應(yīng)該是現(xiàn)在不需要這個(gè)ServiceAccount的創(chuàng)建?？赡芫褪且?yàn)檫@個(gè)，所以我的pvc動(dòng)態(tài)創(chuàng)建就出現(xiàn)了問題

部署deployment.yaml
（修改部分信息，參考上面）

kubectl apply -f deployment.yaml

查看創(chuàng)建的POD

[centos@k8s-master deploy]$ kubectl get pod -o wide
NAME                                      READY   STATUS             RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
nfs-client-provisioner-75bf876d88-578lg   1/1     Running            0          51m   10.244.2.131   k8s-node2   <none>           <none>

創(chuàng)建StorageClass
storage class的定義，需要注意的是：provisioner屬性要等于驅(qū)動(dòng)所傳入的環(huán)境變量PROVISIONER_NAME的值。否則，驅(qū)動(dòng)不知道知道如何綁定storage class。
此處可以不修改，或者修改provisioner的名字，需要與上面的deployment的PROVISIONER_NAME名字一致。
（此yaml無需修改）

[centos@k8s-master deploy]$ cat class.yaml 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

部署yaml文件

kubectl apply -f class.yaml

查看創(chuàng)建的storageclass

[centos@k8s-master deploy]$ kubectl get sc
NAME                  PROVISIONER      AGE
managed-nfs-storage   fuseim.pri/ifs   95m
[centos@k8s-master deploy]$ 

配置授權(quán)
如果集群啟用了RBAC，則必須執(zhí)行如下命令授權(quán)provisioner。(k8s1.6+默認(rèn)開啟)
此yaml無需修改

[centos@k8s-master deploy]$ cat rbac.yaml 
kind: ServiceAccount
apiVersion: v1
metadata:
  name: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

部署yaml文件

kubectl create -f rbac.yaml

測試

創(chuàng)建測試PVC

kubectl create -f test-claim.yaml

這里指定了其對(duì)應(yīng)的storage-class的名字為managed-nfs-storage，如下：

[centos@k8s-master deploy]$ cat test-claim.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

查看創(chuàng)建的PVC
可以看到PVC狀態(tài)為Bound，綁定的volume為pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3。

[centos@k8s-master deploy]$ kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
test-claim   Bound    pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3   1Mi        RWX            managed-nfs-storage   34m

查看自動(dòng)創(chuàng)建的PV

[centos@k8s-master deploy]$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS          REASON   AGE
pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3   1Mi        RWX            Delete           Bound    default/test-claim   managed-nfs-storage            34m
[centos@k8s-master deploy]$ 

然后，我們進(jìn)入到NFS的export目錄，可以看到對(duì)應(yīng)該volume name的目錄已經(jīng)創(chuàng)建出來了。
其中volume的名字是namespace，PVC name以及uuid的組合：

[root@k8s-master ~]# cd /nfs/data/
[root@k8s-master data]# ll
total 0
drwxrwxrwx 2 root root 21 Jan 29 12:03 default-test-claim-pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3

創(chuàng)建測試Pod
指定該pod使用我們剛剛創(chuàng)建的PVC：test-claim，另外注意這里將鏡像改為dockerhub鏡像。
完成之后，如果attach到pod中執(zhí)行一些文件的讀寫操作，就可以確定pod的/mnt已經(jīng)使用了NFS的存儲(chǔ)服務(wù)了。

[centos@k8s-master deploy]$ vim test-pod.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: willdockerhub/busybox:1.24
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim

執(zhí)行yaml文件

kubectl create -f test-pod.yaml

查看創(chuàng)建的測試POD

[centos@k8s-master ~]$ kubectl get pod -o wide
NAME                                      READY   STATUS             RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
nfs-client-provisioner-75bf876d88-578lg   1/1     Running            0          51m   10.244.2.131   k8s-node2   <none>           <none>
test-pod                                  0/1     Completed          0          41m   10.244.1.

在NFS服務(wù)器上的共享目錄下的卷子目錄中檢查創(chuàng)建的NFS PV卷下是否有"SUCCESS" 文件。

[root@k8s-master ~]# cd /nfs/data/
[root@k8s-master data]# ll
total 0
drwxrwxrwx 2 root root 21 Jan 29 12:03 default-test-claim-pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3
[root@k8s-master data]# 

[root@k8s-master data]# cd default-test-claim-pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3/
[root@k8s-master default-test-claim-pvc-a17d9fd5-237a-11e9-a2b5-000c291c25f3]# ll
total 0
-rw-r--r-- 1 root root 0 Jan 29 12:03 SUCCESS

清理測試環(huán)境
刪除測試POD

kubectl delete -f test-pod.yaml

刪除測試PVC

kubectl delete -f test-claim.yaml

在NFS服務(wù)器上的共享目錄下查看NFS的PV卷已經(jīng)被刪除。

ok,成功了

說一下我當(dāng)時(shí)遇到的問題，當(dāng)時(shí)創(chuàng)建pv后，pv顯示pending

[root@K8S-M1 deploy]# kubectl describe pvc test-claim
Name:          test-claim
Namespace:     default
StorageClass:  managed-nfs-storage
Status:        Bound
Volume:        pvc-962a06fa-67db-11e9-963d-000c29619b15
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-class: managed-nfs-storage
               volume.beta.kubernetes.io/storage-provisioner: fuseim.pri/ifs
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Mi
Events:
  Type    Reason                Age   From                         Message
  ----    ------                ----  ----                         -------
  Normal  ExternalProvisioning  10s   persistentvolume-controller  waiting for a volume to be created, either by external provisioner "fuseim.pri/ifs" or manually created by system administrator

即正在等待外部設(shè)置程序“fuseim.pri/ifs”或系統(tǒng)管理員手動(dòng)創(chuàng)建卷
我參考了這個(gè)文章
https://github.com/kubernetes-incubator/external-storage/issues/754
試著執(zhí)行此yaml

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: default-admin-rbac (or whatever)
subjects:
  - kind: ServiceAccount
    name: default
    namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

試過，依舊不可以
我發(fā)現(xiàn)我的nfs-client-provisioner-xxx的pod會(huì)出現(xiàn)running后，過一陣子后出現(xiàn)CrashLoopBackOff ，即說明容器曾經(jīng)啟動(dòng)了，但又異常退出了。
通過kubectl logs -f 命令查看，發(fā)現(xiàn)

nfs-client-provisioner: dial tcp 192.168.88.114:10250: connect: connection refused

或者(我不記得是哪個(gè)了)

[root@K8S-M1 deploy]# kubectl get pod
NAME                                      READY   STATUS             RESTARTS   AGE
nfs-client-provisioner-648f9b65c6-snsc6   0/1     CrashLoopBackOff   6          14m
[root@K8S-M1 deploy]# kubectl logs -f nfs-client-provisioner-648f9b65c6-snsc6
F0427 02:58:21.988130       1 provisioner.go:180] Error getting server version: Get https://10.10.10.1:443/version?timeout=32s: dial tcp 10.10.10.1:443: i/o timeout

192.168.88.114是我的node，也是此pod所在的node。 所以我覺得是我的provisioner的原因，但是你刪除pod，還是不可以，pod的狀態(tài)和pvc的狀態(tài)依舊。
或者第二種情況，不過這種我也找不出原因

當(dāng)我把provisioner的deployment刪除后，(我不記得是否重啟了虛擬機(jī))，重新 kubectl create -f ,創(chuàng)建deployment和pod，這次觀察pod ，一直running，查看日志

[root@K8S-M1 deploy]# kubectl logs -f nfs-client-provisioner-c85fbcc5d-mtgb8
I0426 05:03:50.995699       1 leaderelection.go:185] attempting to acquire leader lease  default/fuseim.pri-ifs...
I0426 05:03:51.083275       1 leaderelection.go:194] successfully acquired lease default/fuseim.pri-ifs
I0426 05:03:51.084006       1 controller.go:631] Starting provisioner controller fuseim.pri/ifs_nfs-client-provisioner-c85fbcc5d-mtgb8_ae87400d-67e0-11e9-84ac-0242ac110304!
I0426 05:03:51.084350       1 event.go:221] Event(v1.ObjectReference{Kind:"Endpoints", Namespace:"default", Name:"fuseim.pri-ifs", UID:"ae9593ed-67e0-11e9-963d-000c29619b15", APIVersion:"v1", ResourceVersion:"246640", FieldPath:""}): type: 'Normal' reason: 'LeaderElection' nfs-client-provisioner-c85fbcc5d-mtgb8_ae87400d-67e0-11e9-84ac-0242ac110304 became leader
I0426 05:03:51.205879       1 controller.go:680] Started provisioner controller fuseim.pri/ifs_nfs-client-provisioner-c85fbcc5d-mtgb8_ae87400d-67e0-11e9-84ac-0242ac110304!
I0426 05:03:51.206648       1 controller.go:987] provision "default/test-claim" class "managed-nfs-storage": started

這時(shí)再查看pvc，發(fā)現(xiàn)成功（或者你重新創(chuàng)建pvc）

[root@K8S-M1 deploy]# kubectl get pvc
NAME                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
test-claim               Bound    pvc-962a06fa-67db-11e9-963d-000c29619b15   1Mi        RWX            managed-nfs-storage   40m

[root@K8S-M1 deploy]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                            STORAGECLASS          REASON   AGE
pvc-962a06fa-67db-11e9-963d-000c29619b15   1Mi        RWX            Delete           Bound       default/test-claim               managed-nfs-storage            3m59s

發(fā)現(xiàn)成功創(chuàng)建了pv,并且綁定
再次查看provisioner的pod的日志，發(fā)現(xiàn)在上次的記錄之外，多了下面的記錄

I0426 05:03:51.213869       1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"test-claim", UID:"962a06fa-67db-11e9-963d-000c29619b15", APIVersion:"v1", ResourceVersion:"244152", FieldPath:""}): type: 'Normal' reason: 'Provisioning' External provisioner is provisioning volume for claim "default/test-claim"
I0426 05:03:51.224187       1 controller.go:1087] provision "default/test-claim" class "managed-nfs-storage": volume "pvc-962a06fa-67db-11e9-963d-000c29619b15" provisioned
I0426 05:03:51.224252       1 controller.go:1101] provision "default/test-claim" class "managed-nfs-storage": trying to save persistentvvolume "pvc-962a06fa-67db-11e9-963d-000c29619b15"
I0426 05:03:51.299834       1 controller.go:1108] provision "default/test-claim" class "managed-nfs-storage": persistentvolume "pvc-962a06fa-67db-11e9-963d-000c29619b15" saved
I0426 05:03:51.299895       1 controller.go:1149] provision "default/test-claim" class "managed-nfs-storage": succeeded
I0426 05:03:51.300609       1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"test-claim", UID:"962a06fa-67db-11e9-963d-000c29619b15", APIVersion:"v1", ResourceVersion:"244152", FieldPath:""}): type: 'Normal' reason: 'ProvisioningSucceeded' Successfully provisioned volume pvc-962a06fa-67db-11e9-963d-000c29619b15

說明provisioner成功工作，nfs動(dòng)態(tài)存儲(chǔ)也成功了。我想了一下，可能是再創(chuàng)建provisioner的deployment時(shí)，也創(chuàng)建了ServiceAccount，但是這個(gè)ServiceAccount還沒有綁定具有權(quán)限的ClusterRole,雖然后面的rbac.yaml里寫入了，但是deployment已經(jīng)把沒有綁定權(quán)限的ClusterRole的ServiceAccount寫入到環(huán)境里，它已經(jīng)不受后面操作的影響了，所以pvc才說正在等待外部設(shè)置程序“fuseim.pri/ifs”或系統(tǒng)管理員手動(dòng)創(chuàng)建卷，pod無法作為provisioner來創(chuàng)建pvc，所以pvc一直pending。

1.所以deployment就只需要?jiǎng)?chuàng)建provisioner的deployment，可以把創(chuàng)建ServiceAccount的代碼刪除，由rbac.yaml去統(tǒng)一創(chuàng)建綁定。
2.也可能需要需要先創(chuàng)建rbac.yaml,再創(chuàng)建deployment和storageClass。
3.也可能就是偶然，出現(xiàn)這種情況就刪除deployment，重新創(chuàng)建
4.因?yàn)槲沂窃诠P記本上用虛擬機(jī)創(chuàng)建k8s集群，所以有時(shí)候node會(huì)noready，出現(xiàn)了很多次，需要重啟node，錯(cuò)誤過程中（這幾個(gè)小時(shí)里）也出現(xiàn)了，我不知道是不是一直NotReady。所以可能是因?yàn)閚ode NotReady，所以pod才會(huì)重啟為CrashLoopBackOff,所以日志會(huì)顯示nfs-client-provisioner: dial tcp 192.168.88.114:10250: connect: connection refused，無法作為provisioner來動(dòng)態(tài)創(chuàng)建pv，這也是一種可能
5.虛擬機(jī)掛起，關(guān)機(jī)后啟動(dòng)出現(xiàn)某種緩存類似的問題，
也可能是都不對(duì)，哈哈，只是舉了我的幾個(gè)想法，不完全。

我剛剛又重新創(chuàng)建pvc，發(fā)現(xiàn)

[root@K8S-M1 deploy]# kubectl describe pvc test-claim
Name:          test-claim
Namespace:     default
StorageClass:  managed-nfs-storage
Status:        Bound
Volume:        pvc-0d94a6a4-6800-11e9-963d-000c29619b15
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-class: managed-nfs-storage
               volume.beta.kubernetes.io/storage-provisioner: fuseim.pri/ifs
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Mi
Access Modes:  RWX
Events:
  Type       Reason                 Age                From                                                                                        Message
  ----       ------                 ----               ----                                                                                        -------
  Normal     ExternalProvisioning   76s (x2 over 76s)  persistentvolume-controller                                                                 waiting for a volume to be created, either by external provisioner "fuseim.pri/ifs" or manually created by system administrator
  Normal     Provisioning           76s                fuseim.pri/ifs_nfs-client-provisioner-c85fbcc5d-mtgb8_ae87400d-67e0-11e9-84ac-0242ac110304  External provisioner is provisioning volume for claim "default/test-claim"
  Normal     ProvisioningSucceeded  76s                fuseim.pri/ifs_nfs-client-provisioner-c85fbcc5d-mtgb8_ae87400d-67e0-11e9-84ac-0242ac110304  Successfully provisioned volume pvc-0d94a6a4-6800-11e9-963d-000c29619b15
Mounted By:  <none>

也是出現(xiàn)了waiting for a volume to be created, either by external provisioner "fuseim.pri/ifs" or manually created by system administrator，后面External provisioner給他創(chuàng)建pv來提供。一會(huì)時(shí)間。但是之前那個(gè)是一直創(chuàng)建不了，一直pending，那就是External provisioner的pod(deployment)有問題。這只是補(bǔ)充情況

虛擬機(jī)掛起后啟動(dòng)（從掛起到啟動(dòng)）出現(xiàn)了下面的情況，pod重新創(chuàng)建了

[root@K8S-M1 deploy]# kubectl get pod
NAME                                      READY   STATUS             RESTARTS   AGE
nfs-client-provisioner-648f9b65c6-snsc6   0/1     CrashLoopBackOff   6          14m
[root@K8S-M1 deploy]# kubectl logs -f nfs-client-provisioner-648f9b65c6-snsc6
F0427 02:58:21.988130       1 provisioner.go:180] Error getting server version: Get https://10.10.10.1:443/version?timeout=32s: dial tcp 10.10.10.1:443: i/o timeout

不過如果虛擬機(jī)一直開著，那么不會(huì)出現(xiàn)這種情況，應(yīng)該是虛擬機(jī)掛起到啟動(dòng)，k8s的某種緩存或者其他原因?qū)е聲?huì)出現(xiàn)這種情況。如果你裝nfs-provisioner，出現(xiàn)這種情況，那么就重啟虛擬機(jī)，不行就重啟電腦，再重新部署deployment（可能也不需要吧，就刪除pod）

OK，感覺已經(jīng)解決了
在我掛起(可能關(guān)機(jī))虛擬機(jī)后，啟動(dòng)（從掛起到啟動(dòng)）虛擬機(jī)后，k8s的provisioner的pod就出現(xiàn)了上面的情況，即使重新部署deployment，也不行。我重啟k8s(master和node)，好像也不行。我后面重啟電腦后，打開虛擬機(jī)后，再次部署provisioner的deployment，就OK了。說明這是偶然的，重啟虛擬機(jī)的k8s就可能解決，起因可能是虛擬機(jī)掛起后重新啟動(dòng)，k8s就出現(xiàn)某種問題，解決方案 重啟虛擬機(jī)或者直接重啟電腦。說明應(yīng)該是原因5。