【转】kubernetes 磁盘、PV、PVC以及MySQL部署

作者: 吕信 | 来源:发表于2020-02-12 17:09 被阅读0次

6.1.介绍卷

6.1.1.卷的类型

emptyDir-用于存储临时数据的简单空目录

hostPath-用于将目录从工作节点的文件系统挂载到pod

nfs-挂载到pod中的NFS共享卷。

还有其他的如gitRepo、gcepersistenDisk

6.2.通过卷在容器间共享数据

6.2.1.使用emptyDir卷

卷的生命周期与pod的生命周期项关联，所以当删除pod时，卷的内容就会丢失。

使用empty示例代码如下：

apiVersion: v1

kind: Pod

metadata:

name: fortune

spec:

containers:

- image: luksa/fortune

name: html-gener

volumeMounts:

- name: html

mountPath: /usr/share/nginx

readOnly: true

- image: nginx/aplin

name: web-service

volumeMounts:

- name: html

mountPath: /usr/share

readOnly: true

volumes:

- name: html                        //一个名为html的单独emptyDir卷，挂载在上面的两个容器中

emptyDir: {}

6.3.访问工作节点文件系统上的文件

6.3.1.hostPath卷

hostPath是持久性存储，emptyDir卷的内容随着pod的删除而删除。

使用hostPath会发现当删除一个pod，并且下一个pod使用了指向主机上相同路径的hostPath卷，则新pod将会发现上一个pod留下的数据，但前提是必须将其调度到与第一个pod相同的节点上。

所以当你使用hostPath时请务必考虑清楚，当重新起一个pod时候，必须要保证pod的节点与之前相同。

apiVersion: v1

kind: Pod

metadata:

name: test-pd

spec:

containers:

- image: k8s.gcr.io/test-webserver

name: test-container

volumeMounts:

- mountPath: /test-pd

name: test-volume

volumes:

- name: test-volume

hostPath:

# directory location on host

path: /data

# this field is optional

type: Directory

6.4.使用持久化存储

怎样保证pod重新启动后调度到任意一个节点都有相同的数据可用，这就需要做到持久化存储。

因此必须要将数据存储在某种类型的网络存储（NAS）中。

各种支持的方式不尽相同，例如 GlusterFS 需要创建 Endpoint，Ceph/NFS 之流就没这么麻烦了。

6.4.1.使用NFS存储

以NFS为例，yml代码如下：

image

6.4.2.configmap和secert

secret和configmap可以理解为特殊的存储卷，但是它们不是给Pod提供存储功能的，而是提供了从集群外部向集群内部的应用注入配置信息的功能。ConfigMap扮演了K8S集群中配置中心的角色。ConfigMap定义了Pod的配置信息，可以以存储卷的形式挂载至Pod中的应用程序配置文件目录，从configmap中读取配置信息；也可以基于环境变量的形式，从ConfigMap中获取变量注入到Pod容器中使用。但是ConfigMap是明文保存的，如果用来保存数据库账号密码这样敏感信息，就非常不安全。一般这样的敏感信息配置是通过secret来保存。secret的功能和ConfigMap一样，不过secret是通过Base64的编码机制保存配置信息。

从ConfigMap中获取配置信息的方法有两种：

一种是利用环境变量将配置信息注入Pod容器中的方式，这种方式只在Pod创建的时候生效，这就意味着在ConfigMap中的修改配置信息后，更新的配置不能被已经创建Pod容器所应用。
另一种是将ConfigMap做为存储卷挂载至Pod容器内，这样在修改ConfigMap配置信息后，Pod容器中的配置也会随之更新，不过这个过程会有稍微的延迟。

ConfigMap当作存储卷挂载至Pod中的用法：

apiVersion: v1

kind: Pod

metadata:

name: pod-configmap-vol-2

labels:

name: pod-configmap-vol-2

spec:

containers:

- name: myapp

image: ikubernetes/myapp:v1

volumeMounts:

- name: my-cm-www

mountPath: /etc/nginx/conf.d/ # 将名为my-www的configmap挂载至Pod容器的这个目录下。

volumes:

- name: my-cm-www

configMap: # 存储卷类型选configMap

secert的方法类似，只是secert对数据进行了加密

6.5.从底层存储技术解耦pod

6.5.1.介绍持久卷和持久卷声明

当集群用户需要在其pod中使用持久化存储时，他们首先创建持久化声明（PVC）清单，指定所需要的最低容量要求，和访问模式，然后用户将持久卷声明清单提交给kubernetes API服务器，kubernetes将找到可以匹配的持久卷并将其绑定到持久卷声明。

持久卷声明可以当做pod中的一个卷来使用，其他用户不能使用相同的持久卷，除非先通过删除持久卷声明绑定来释放。

6.5.2.创建持久卷

下面创建一个 PV mypv1，配置文件pv1.yml 如下：

apiVersion: v1

kind: PersistentVolume

metadata:

name: yh_pv1

spec:

capacity:

storage: 1Gi ``//capacity 指定 PV 的容量为 1G

accessModes： ``//accessModes 指定访问模式为 ReadWriteOnce

- ReadWriteOnce

persistentVolumeReclaimpolicy: Recycle ``//persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle

storageClassName: nfs ``//storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。

nfs:

path: /nfs/data ``//指定 PV 在 NFS 服务器上对应的目录

server: 10.10.0.11

1.accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：

ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
　　ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
　　ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

2.persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
　　Retain – 需要管理员手工回收。
　　Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
　　Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

创建 pv：

# kubectl apply -f pv1.yml

persistentvolume/yh-pv1 created

查看pv：

# kubectl get pv

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

yh-pv1 1Gi RWO Recycle Available nfs 17m

STATUS 为 Available，表示 yh-pv1就绪，可以被 PVC 申请。

6.5.3.通过持久卷声明来获取持久卷

接下来创建 PVC mypvc1，配置文件 pvc1.yml 如下：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: yh-pvc

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 1Gi

storageClassName: nfs

PVC 就很简单了，只需要指定 PV 的容量，访问模式和 class。

执行命令创建 mypvc1：

# kubectl apply -f pvc1.yml

persistentvolumeclaim/yh-pvc created

查看pvc

# kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

yh-pvc Bound yh-pv1 1Gi RWO nfs 64s

从 kubectl get pvc 和 kubectl get pv 的输出可以看到 yh-pvc1 已经 Bound 到yh- pv1，申请成功。

# kubectl get pv

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

yh-pv1 1Gi RWO Recycle Bound ``default``/yh-pvc nfs 47m

6.5.4.在pod中使用持久卷声明

上面已经创建好了pv和pvc，pod中直接使用这个pvc即可

image

与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc1 申请的 Volume。

通过命令创建mypod1：

image

可见，在 Pod 中创建的文件 /mydata/hello 确实已经保存到了 NFS 服务器目录 /nfsdata中。

如果不再需要使用 PV，可用删除 PVC 回收 PV。

6.5.5.回收持久卷

当 PV 不再需要时，可通过删除 PVC 回收。

image

未删除pvc之前 pv的状态是Bound

image

image

删除pvc之后pv的状态变为Available，，此时解除绑定后则可以被新的 PVC 申请。

/nfsdata文件中的文件被删除了

image

因为 PV 的回收策略设置为 Recycle，所以数据会被清除，但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain。

image

通过 kubectl apply 更新 PV：

image

回收策略已经变为 Retain，通过下面步骤验证其效果：

image

① 重新创建 mypvc1。

② 在 mypv1 中创建文件 hello。

③ mypv1 状态变为 Released。

④ PV 中的数据被完整保留。

虽然 mypv1 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv1。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。

image

新建的 mypv1 状态为 Available，已经可以被 PVC 申请。

PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

回到顶部