K8S部署有状态服务

这里的话就不直接使用kubectl来创建应用了，使用可视化的kubesphere来操作k8s集群！
kubesphere的整合之前文章中有写过K8S安装Kubesphere

k8s部署有状态服务的话就是参照上面的图。

• 有状态服务抽取配置为ConfigMap
  在之前我们使用Docker部署MySQL的时候也会将conf、logs、data等数据挂载到宿主机上，那么在k8s里面的话专门有一个空间是管理配置文件的也就是上面提到的ConfigMap，可以将一些常用的配置抽离出来做成ConfigMap配置，后来不管是MySQL挂了重启还是创建新的MySQL都可已使用同一个ConfigMap中的配置，这也就是第一点将有状态服的配置抽离到ConfigMap中来，这样后期修改配置就只需要更改ConfigMap就行了
• 有状态服务必须使用PVC持久化数据
  每个MySQL都会用自己的数据存储，那么在k8s中存在一个专门存储数据的空间，也就是上面提到的PVC， 每一个MySQL都会分配一个PVC数据存储空间，或者共享一个PVC空间，也就是想Docker挂载出来的data目录一样，在Docker中的MySQL容器重启后MySQL中的数据还存在，那么k8s中的MySQL挂掉后重启后也会在PVC中找持久化的数据，那么这样就不会存在在其他节点拉起MySQL存在数据丢失的问题了
• 服务集群内访问使用DNS提供稳定的域名
  在上面图中存在一个主节点MySQL和两个从节点MySQL，在这个MySQL集群中个节点间是要相互通信访问的，这里实现各节点间通信访问的话就需要使用Headless Service服务，这个服务就是集群中间相互访问的，在k8s中最小的部署单元是pod，如MySQL0就是一个pod，那么我们将这个pod包装成一个Service，同时让k8s为这个Service生成一个域名，DNS为这个服务提供一个稳定域名，如图上为MySQL0这个服务提供了mysql-0.test域名，其他的pod对外暴露服务后也会提供相应的域名，那么各节点通信就可以使用域名访问，这里提供域名的好处就是防止某台对外暴露的服务突然挂掉了，在别的机器上拉起，那么这时的ip就会发生改变，那么集群内的所有应用，包括服务自己都可以使用域名来访问

k8s部署有状态服务都可以遵循图上的操作逻辑

ConfigMap

那么在yaml文件中呈现的配置就是这样的

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: mabangbang
  labels:
    app: test
  name: test
  annotations:
    kubesphere.io/alias-name: ConfigMap测试
spec:
  template:
    metadata:
      labels:
        app: test

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: mabangbang
  name: pvc
  labels:
    app: pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  template:
    metadata:
      labels:
        app: pvc