參考文獻(xiàn)：https://blog.csdn.net/networken/article/details/86697018
本篇文章絕大部分（幾乎完全）復(fù)制粘貼，他的文章給了我很大幫助，現(xiàn)在在這里寫這篇文章，一是為了記錄，CSDN有時(shí)候文章會損壞或者服務(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共享存儲有兩種方式：
1.手動方式靜態(tài)創(chuàng)建所需要的PV和PVC。
2.通過創(chuàng)建PVC動態(tài)地創(chuàng)建對應(yīng)PV，無需手動創(chuàng)建PV。
下面對這兩種方式進(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
#啟動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ī)啟動
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)申請PV卷
添加pv卷對應(yīng)目錄,這里創(chuàng)建2個(gè)pv卷，則添加2個(gè)pv卷的目錄作為掛載點(diǎn)。
#創(chuàng)建pv卷對應(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 上的對應(yīng)存儲資源，例如 AWS EBS、GCE PD、Azure
Disk、OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 為 nfs。相當(dāng)于為 PV 設(shè)置了一個(gè)分類，PVC 可以指定 class 申請相應(yīng) class 的 PV。
⑤ 指定 PV 在 NFS 服務(wù)器上對應(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 申請。
創(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，申請成功。注意pvc綁定到對應(yīng)pv通過labels標(biāo)簽方式實(shí)現(xiàn)，也可以不指定，將隨機(jī)綁定到pv。
接下來就可以在 Pod 中使用存儲了，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申請的 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不會被刪除，nfs存儲的數(shù)據(jù)不會被刪除。
[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存儲中的數(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
動態(tài)申請PV卷
External NFS驅(qū)動的工作原理
K8S的外部NFS驅(qū)動，可以按照其工作方式（是作為NFS server還是NFS client）分為兩類：
1.nfs-client:
也就是我們接下來演示的這一類，它通過K8S的內(nèi)置的NFS驅(qū)動掛載遠(yuǎn)端的NFS服務(wù)器到本地目錄；然后將自身作為storage provider，關(guān)聯(lián)storage class。當(dāng)用戶創(chuàng)建對應(yīng)的PVC來申請PV時(shí)，該provider就將PVC的要求與自身的屬性比較，一旦滿足就在本地掛載好的NFS目錄中創(chuàng)建PV所屬的子目錄，為Pod提供動態(tài)的存儲服務(wù)。
2.nfs:
與nfs-client不同，該驅(qū)動并不使用k8s的NFS驅(qū)動來掛載遠(yuǎn)端的NFS到本地再分配，而是直接將本地文件映射到容器內(nèi)部，然后在容器內(nèi)使用ganesha.nfsd來對外提供NFS服務(wù)；在每次創(chuàng)建PV的時(shí)候，直接在本地的NFS根目錄中創(chuàng)建對應(yīng)文件夾，并export出該子目錄。
利用NFS動態(tài)提供Kubernetes后端存儲卷
本文將介紹使用nfs-client-provisioner這個(gè)應(yīng)用，利用NFS Server給Kubernetes作為持久存儲的后端，并且動態(tài)提供PV。前提條件是有已經(jīng)安裝好的NFS服務(wù)器，并且NFS服務(wù)器與Kubernetes的Slave節(jié)點(diǎn)都能網(wǎng)絡(luò)連通。將nfs-client驅(qū)動做一個(gè)deployment部署到K8S集群中，然后對外提供存儲服務(wù)。
nfs-client-provisioner 是一個(gè)Kubernetes的簡易NFS的外部provisioner，本身不提供NFS，需要現(xiàn)有的NFS服務(wù)器提供存儲
部署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動態(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ū)動所傳入的環(huán)境變量PROVISIONER_NAME的值。否則，驅(qū)動不知道知道如何綁定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
這里指定了其對應(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
查看自動創(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目錄，可以看到對應(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的存儲服務(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)管理員手動創(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會出現(xiàn)running后，過一陣子后出現(xiàn)CrashLoopBackOff ，即說明容器曾經(jī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動態(tài)存儲也成功了。我想了一下，可能是再創(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)管理員手動創(chuàng)建卷，pod無法作為provisioner來創(chuàng)建pvc，所以pvc一直pending。
1.所以deployment就只需要創(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會noready，出現(xiàn)了很多次，需要重啟node，錯(cuò)誤過程中（這幾個(gè)小時(shí)里）也出現(xiàn)了，我不知道是不是一直NotReady。所以可能是因?yàn)閚ode NotReady，所以pod才會重啟為CrashLoopBackOff,所以日志會顯示nfs-client-provisioner: dial tcp 192.168.88.114:10250: connect: connection refused，無法作為provisioner來動態(tài)創(chuàng)建pv，這也是一種可能
5.虛擬機(jī)掛起，關(guān)機(jī)后啟動出現(xiàn)某種緩存類似的問題，
也可能是都不對，哈哈，只是舉了我的幾個(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來提供。一會時(shí)間。但是之前那個(gè)是一直創(chuàng)建不了，一直pending，那就是External provisioner的pod(deployment)有問題。這只是補(bǔ)充情況
虛擬機(jī)掛起后啟動（從掛起到啟動）出現(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ī)一直開著，那么不會出現(xiàn)這種情況，應(yīng)該是虛擬機(jī)掛起到啟動，k8s的某種緩存或者其他原因?qū)е聲霈F(xiàn)這種情況。如果你裝nfs-provisioner，出現(xiàn)這種情況，那么就重啟虛擬機(jī)，不行就重啟電腦，再重新部署deployment（可能也不需要吧，就刪除pod）
OK，感覺已經(jīng)解決了
在我掛起(可能關(guān)機(jī))虛擬機(jī)后，啟動（從掛起到啟動）虛擬機(jī)后，k8s的provisioner的pod就出現(xiàn)了上面的情況，即使重新部署deployment，也不行。我重啟k8s(master和node)，好像也不行。我后面重啟電腦后，打開虛擬機(jī)后，再次部署provisioner的deployment，就OK了。說明這是偶然的，重啟虛擬機(jī)的k8s就可能解決，起因可能是虛擬機(jī)掛起后重新啟動，k8s就出現(xiàn)某種問題，解決方案 重啟虛擬機(jī)或者直接重啟電腦。說明應(yīng)該是原因5。
