K8S 实战篇 - Mysql部署

在k8s 实战篇 - mysql部署 - 2和k8s 实战篇 - mysql部署 - 1中有讲过如何在pod上部署mysql，其中1主要是描述如何部署，2主要描述部署之后数据如何持久化。在本章中会讲通过K8S的PV和PVC部署mysql，来进行数据的持久化。那什么是PV及PVC呢？

1、何为PV&PVC？

• PV 是指 Persistent Volume，是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
• PVC 是指 Persistent Volume Claim，表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。
  以上摘自kubernetes官网的PV和PVC的定义。

1.1、PV存储映射介质

PV 是物理存储与k8s存储的一种映射关系。物理存储介质包括：

• cephfs - CephFS volume
• csi - 容器存储接口 (CSI)
• fc - Fibre Channel (FC) 存储
• hostPath - HostPath 卷 （仅供单节点测试使用；不适用于多节点集群；请尝试使用 local 卷作为替代）
• iscsi - iSCSI (SCSI over IP) 存储
• local - 节点上挂载的本地存储设备
• nfs - 网络文件系统 (NFS) 存储
• rbd - Rados 块设备 (RBD) 卷

以下的持久卷已被弃用。这意味着当前仍是支持的，但是 Kubernetes 将来的发行版会将其移除。

• awsElasticBlockStore - AWS 弹性块存储（EBS） （于 v1.17 弃用）
• azureDisk - Azure Disk （于 v1.19 弃用）
• azureFile - Azure File （于 v1.21 弃用）
• cinder - Cinder（OpenStack 块存储）（于 v1.18 弃用）
• flexVolume - FlexVolume （于 v1.23 弃用）
• gcePersistentDisk - GCE Persistent Disk （于 v1.17 弃用）
• glusterfs - Glusterfs 卷 （于 v1.25 弃用）
• portworxVolume - Portworx 卷 （于 v1.25 弃用）
• vsphereVolume - vSphere VMDK 卷 （于 v1.19 弃用）

旧版本的 Kubernetes 仍支持这些“树内（In-Tree）”持久卷类型：

• photonPersistentDisk - Photon 控制器持久化盘。（从 v1.15 版本开始将不可用）
• scaleIO - ScaleIO 卷（v1.21 之后不可用）
• flocker - Flocker 存储 （v1.25 之后不可用）
• quobyte - Quobyte 卷 （v1.25 之后不可用）
• storageos - StorageOS 卷 （v1.25 之后不可用）

这次主要使用hostpath进行存储，在之前的部署中都是通过直接pod，直接关联hostpath，这次主要使用PV和PVC进行关联。

1.2、PV的访问方式

对PV的数据进行请求权限设置，类似于linux的chmod进行授权，通过“accessModes”字段进行设置。授予用户对存储资源的访问权限：

• ​​ReadWriteOnce​​（RWO）：读写权限，并且只能被单个Node挂载。
• ReadOnlyMany​​（ROX）：只读权限，允许被多个Node挂载
• ReadWriteMany​​（RWX）：读写权限，允许被多个Node挂载。

并不是所有的存储介质都拥有三种访问方式的，可以通过官方网站进行查询，hostpath只支持单节点的读写操作。

1.3、PV回收策略

对PV存储块中的数据处理操作，通过“persistentVolumeReclaimPolicy”字段进行设置。

• Retain：回收策略 Retain 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象被删除时，PersistentVolume 卷仍然存在，对应的数据卷被视为"已释放（released）"。 由于卷上仍然存在这前一申领人的数据，该卷还不能用于其他申领。
• Delete：对于支持 Delete 回收策略的卷插件，删除动作会将 PersistentVolume 对象从 Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中移除所关联的存储资产。 动态制备的卷会继承其 StorageClass 中设置的回收策略， 该策略默认为 Delete。管理员需要根据用户的期望来配置 StorageClass； 否则 PV 卷被创建之后必须要被编辑或者修补。
• Recycle：如果下层的卷插件支持，回收策略 Recycle 会在卷上执行一些基本的擦除 （rm -rf /thevolume/*）操作，之后允许该卷用于新的 PVC 申领。

2、mysql的PV&PVC存储

以上介绍了何为PV&PVC。需要注意的概念存储介质、访问方式、回收策略。本章主要是使用PV映射hostpath，进行对mysql数据的存储。下面编写一下kubectl的yaml文件，定义文件名为kubectl apply -f mysql-k8s-pv-pvc.yaml，如下：

## 定义PV
apiVersion: v1
kind: PersistentVolume
metadata: # PV建立不要加名称空间，因为PV属于集群级别的
  name: mysql-pv # PV名称
spec: # 这里的spec和volumes里面的一样
  storageClassName: manual # 类的名称
  accessModes: # 用于定义资源的访问方式
    - ReadWriteOnce # 可读可写
  capacity: # 设置存储空间大小
    storage: 1Gi
  persistentVolumeReclaimPolicy: Recycle # 回收策略
  hostPath:
    ## 绑定在node上的位置
    path: /data/mysql-data
---
## 定义mysql的pvc，同时申领资源
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv   
  namespace: default
spec:
  storageClassName: manual
  accessModes: # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
    - ReadWriteOnce
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 1Gi # 定义要求有多大空间
---
## 定义创建mysql并部署
apiVersion: apps/v1
kind: Deployment # 副本控制器RC
metadata:
  name: mysql-pvc #RC 的名称，全局唯一
  namespace: default # 默认空间
spec:
  replicas: 1 #Pod 副本的期待数量
  selector:
    matchLabels:
      app: mysql-pvc # 符合目标的Pod拥有此标签
  template: # 根据此模版创建Pod的副本
    metadata:
      labels:
        app: mysql-pvc # Pod副本拥有的标签，对应RC的Selector
    spec:
      containers: # Pod的内容的定义部分
        - name: mysql-pvc # 容器的名称
          image: mysql # 容器对应的Docker Image
          ports:
            - containerPort: 3306 # 容器应用监听的端口号
          env:
            - name: MYSQL_ROOT_PASSWORD # 设置mysql的初始化密码
              value: "123456" # 设置mysql的初始化密码
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
      volumes:
        - name: mysql-data
          persistentVolumeClaim: #引用的模式
            claimName: mysql-pv #引用到的pvc动态创建的名字
---
apiVersion: v1
kind: Service # 表明是Kubernetes Service
metadata:
  name: mysql-pvc # Service 的全局唯一名称
spec:
  type: NodePort
  selector:
    app: mysql-pvc
  ports: # Service 提供服务的端口
    - port: 3306 # Service 对应的Pod拥有这里定义的标签

以上是根据mysql部署1-2的配置文件进行的改造，加入pv及pvc的配置，pv里面定义了host的路径、存储空间大小，访问方式、回收策略等。pvc中主要定义需要关联那个pv里面，然后申请使用空间及访问方式。然后在mysql-k8s-pv-pvc.yaml里面卷配置的地方关联pvc：

volumes:
    - name: mysql-data
      persistentVolumeClaim: #引用的模式
        claimName: mysql-pv #引用到的pvc动态创建的名字

整个配置已经准备好了，现在需要验证执行文件的有效性了。

3、在K8S上部署运行mysql

执行部署命令kubectl apply -f mysql-k8s-pv-pvc.yaml

smy1102@LAPTOP-7HC3FEQ9 D:\minikube\source_data>kubectl apply -f mysql-k8s-pv-pvc.yaml
persistentvolume/mysql-pv created
persistentvolumeclaim/mysql-pv created
deployment.apps/mysql-pvc created
service/mysql-pvc created

等待一会查看mysql是否安装成功，执行如下：

smy1102@LAPTOP-7HC3FEQ9 D:\minikube\source_data>kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
docker-demo-k8s-54db7b687d-sqqk9   1/1     Running   5          5d22h
mysql-647d7dc46f-2dnkz             1/1     Running   0          45d
mysql-pvc-ddd7d8b4d-j5wk4          1/1     Running   0          2m21s

smy1102@LAPTOP-7HC3FEQ9 D:\minikube\source_data>kubectl get svc
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
docker-demo-k8s   NodePort    10.110.13.185    <none>        8080:31883/TCP   5d22h
kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP          59d
mysql             NodePort    10.104.191.103   <none>        3306:31767/TCP   45d
mysql-pvc         NodePort    10.98.231.25     <none>        3306:31989/TCP   2m33s

里面可以看到有好几个pod，刚才执行配置的时候定义的pod名为mysql-pvc ，通过定位mysql-pvc ，可以查看pod的状态是running，说明是正常运行。然后通过nodePort 31989，进行访问如下：
配置mysql访问配置，主机，端口，用户名等信息

点击链接测试

请求成功。