持续集成环境搭建(二):kubernetes Dynamic p
的目标是完全自动化存储资源的生命周期管理，让用户无需过多的关注存储的管理，可以按需求自动动态创建和调整存储资源。在Kubernetes 1.6正式版中，动态配置被提升至稳定版。
image.png
是实现动态配置的关键，它本质上是底层存储介质的抽象：不同的存储介质拥有统一的表示和行为。StorageClass使用特定存储平台或者云提供商为Kubernetes提供的物理介质，动态生成PV。所以使用时必须通过指定的
Internal Provisioner或者external provisioners来指定生成PV依赖的物理介质。目前K8S所支持的Internal Provisioner:
| Volume Plugin | Internal Provisioner | Config Example |
|---|---|---|
| AWSElasticBlockStore | ✓ | AWS EBS |
| AzureFile | ✓ | Azure File |
| AzureDisk | ✓ | Azure Disk |
| CephFS | - | - |
| Cinder | ✓ | OpenStack Cinder |
| FC | - | - |
| Flexvolume | - | - |
| Flocker | ✓ | - |
| GCEPersistentDisk | ✓ | GCE PD |
| Glusterfs | ✓ | Glusterfs |
| iSCSI | - | - |
| Quobyte | ✓ | Quobyte |
| NFS | - | - |
| RBD | ✓ | Ceph RBD |
| VsphereVolume | ✓ | vSphere |
| PortworxVolume | ✓ | Portworx Volume |
| ScaleIO | ✓ | ScaleIO |
| StorageOS | ✓ | StorageOS |
| Local | - | Local |
因为是在本地搭建，所以这里我采用了NFS SERVER作为StorageClass的物理介质，NFS并没有K8S支持的Internal Provisioner，我们就需要借助于Kubernetes NFS-Client Provisioner。
在持续集成环境搭建(一):kubernetes安装,已经搭建好了K8S集群，还需要搭建NFS服务器，可参考Linux下NFS服务器的搭建与配置,并保证Node节点可以与NFS服务器都能网络连同。
NFS-Client Provisioner
一、node节点安装nfs客户端
~]# yum -y install nfs-utils
~]# systemctl start nfs-utils
~]# systemctl enable nfs-utils
二、master安装所需服务
- 创建ServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
2.ServiceAccount赋权:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
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"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
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
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: leader-locking-nfs-client-provisioner
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: leader-locking-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
3.创建StorageClass:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: fuseim.pri/ifs
parameters:
archiveOnDelete: "false"
4.创建Deployment
apiVersion: extensions/v1beta1
kind: Deployment
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 # 需要与StorageClass中provisioner属性保持一致
- name: NFS_SERVER
value: 192.168.120.169
- name: NFS_PATH
value: /data/localk8s/
volumes:
- name: nfs-client-root
nfs:
server: 192.168.120.169
path: /data/localk8s/
在 NFS-Client Provisioner中，动态创建的PV是通过容器内部的GO代码实现的。从上面的yaml文件中可以看到，在StorageClass与Deployment之间仅仅是在容器的环境变量中有关联，那么问题来了：
StorageClass 是怎么通过provisioner与NFS-Client Provisioner中的Pod产生联系的？
