带你玩转kubernetes-k8s（第27篇：k8s-深入掌握Pod-使用StatefulSet 搭建MongoDB已经GlusterFS+Heketi的部署-2）

定义StorageClass

     准备工作已经就绪，集群群里元现在可以在k8s集群中定义一个StorageClass了。

   storageclass-gluster-hekeit.yaml 配置文件的内容如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-test
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://20.0.40.53:8080"     #填写宿主机ip，不要填写clusterip
  restauthenabled: "false"

  

     Provisioner参数必须被设置为“kubernetes.io/glusterfs”。

     resturl的地址需要被设置为API Server所在主机可以访问到Heketi服务的某个地址，可以使用服务ClusterIP+端口号、容器IP地址+端口号，或将服务映射到物理机，使用物理机IP+NodePort。

     创建这个StorageClass资源对象：

定义PVC

现在，用户可以申请一个PVC了。例如，一个用户申请一个1GIB空间的共享存储资源，StorageClass使用gluster-heketi，没有定义任何Selector，说明使用动态资源供应模式：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-gluster-test
spec:
  storageClassName: gluster-test
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

pvc的定义一旦生成，系统便将触发Heketi进行相应操作，主要为在GlusterFS集群上创建Brick，再创建并启动一个Volume。整个过程可以在Heketi的日志中查到。

查看PVC的状态，可见其已经为Bound（已绑定）

查看PV，可见系统自动创建的PV:

   查看该PV的详细信息，可以看到其容量、引用的StorageClass等信息都已正确设置，状态也为Bound，回收策略则为默认的Delete。同时Gluster的Endpoint和Paht也→Heketi自动完成了设置：

至此，一个可供Pod使用的PVC就创建成功了。接下来Pod就能通过Volume的设置将这个PVC挂载到容器内部进行使用了。

Pod使用PVC的存储资源

    在Pod中使用PVC定义的存储资源非常容易，只需设置一个Volume，其类型为persistentVolumeClaim，既可轻松引用一个PVC。注意Pod需要与PVC属于同一个Namespace：

apiVersion: v1
kind: Pod
metadata:
  name: pod-use-pvc
spec:
  containers:
  - name: pod-use-pvc
    image: busybox
    command:
    - sleep
    - "3600"
    volumeMounts:
    - name: gluster-volume
      mountPath: "/pv-data"
      readOnly: false
  volumes:
  - name: gluster-volume
    persistentVolumeClaim:
      claimName: pvc-gluster-test

进入容器，在/pv-data  下创建文件

可以验证文件a在GlusterFS集群中是否正确生成。

到这里，使用kubernetes最新的动态存储供应模式，配合StorageClass和Heketi共同搭建基于GlusterFS的共享存储就完成了。

在使用动态存储供应模式的情况下，相对于静态模式的优势至少包含如下两点。

（1） 管理员无须预先创建大量的PV作为存储资源。

（2）用户在申请PVC时无法保证容器与预置PV的容量完全匹配。从kubernetes1.6开始，建议用户优先考虑使用StorageClass的动态存储供应模式进行存储管理。

GlusterFS的共享存储创建完之后，现在继续来完成MongoDB集群的搭建。

创建StatefulSet

为了完成MongoDB集群的搭建，需要创建如下三个资源对象。
◎　一个StorageClass，用于StatefulSet自动为各个应用Pod申请PVC。
◎　一个Headless Service，用于维护MongoDB集群的状态。
◎　一个StatefulSet。

首先，创建一个SotrateClass对象

storageclass-fast.yaml文件内容如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://20.0.40.53:8080"

resturl为heketi  pod的IP加上9090端口

执行kubectl create 命令创建该StorageClass：

接下来，创建对应的HeadLessService。

   mongo-sidecar作为MongoDB集群的管理者，将使用此Headless Service来维护各个MongoDB实例之间的集群关系，以及集群规模变化时的自动更新。

    mongo-headeless-service.yaml文件的内容如下：

apiVersion: v1
kind: Service
metadata:
  name: mongo
  labels:
    name: mongo
spec:
  selector:
    role: mongo
  ports:
  - port: 27017
    targetPort: 27017
  clusterIP: None

最后，创建MongoDB StatefulSet。

statefulset-mongo.yam文件的内容如下：

apiVersion: apps/v1beta1
kind: StatefulSet
metadata: 
  name: mongo
spec: 
  serviceName: "mongo"
  replicas: 3
  template: 
    metadata: 
      labels: 
        role: mongo
        environment: test
    spec: 
      terminationGracePeriodSeconds: 10
      containers: 
      - name: mongo
        image: 135.10.145.25:5000/gzpaas/mongo:3.4.4
        command:
        - mongod
        - "--replSet"
        - rs0
        - "--smallfiles"
        - "--noprelloc"      
        resources:
          limits: 
            cpu: "0.2"
            memory: 100Mi
          requests:
            cpu: "0.2"
            memory: 100Mi
        ports: 
        - containerPort: 27017
        volumeMounts: 
        - name: mongo-persistent-storage
          mountPath: /data/db
      - name: mongo-sidecar
        image: 135.10.145.25:5000/gzpaas/mongo-k8s-sidecar:latest
        resources:
          limits:
            cpu: "0.2"
            memory: 100Mi
          requests:
            cpu: "0.2"
            memory: 100Mi
        env: 
        - name: MONGO_SIDECAR_POD_LABELS
          value: "role=mongo,environment=test"
        - name: KUBERNETES_MONGO_SERVICE_NAME
          value: "mongo"
  volumeClaimTemplates:
  - metadata:
      name: mongo-persistent-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: "fast"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

其中的主要配置说明如下。
（1）在该StatefulSet的定义中包括两个容器：mongo和mongo-sidecar。mongo是主服务程序，mongo-sidecar是将多个mongo实例进行集群设置的工具。mongo-sidecar中的环境变量如下。
◎　MONGO_SIDECAR_POD_LABELS：设置为mongo容器的标签，用于sidecar查询它所要管理的MongoDB集群实例。
◎　KUBERNETES_MONGO_SERVICE_NAME：它的值为mongo，表示sidecar将使用mongo这个服务名来完成MongoDB集群的设置。
（2）replicas=3表示这个MongoDB集群由3个mongo实例组成。
（3）volumeClaimTemplates是StatefulSet最重要的存储设置。在annotations段设置volume.beta.kubernetes.io/storage-class="fast"表示使用名为fast的StorageClass自动为每个mongo Pod实例分配后端存储。resources.requests.storage=10Gi表示为每个mongo实例都分配10GiB的磁盘空间。

查看是否创建成功：

   最终可以看到StatefulSet依次创建并启动了3个mongo Pod实例，它们的名字依次为mongo-0、mongo-1、mongo-2

进入mongo-0 Pod 中的 mongo容器

      StatefulSet会用volumeClaimTemplates中的定义为每个Pod副本都创建一个PVC实例，每个PVC的名称由StatefulSet定义中volumeClaimTemplates的名称和Pod副本的名称组合而成。

 

使用kubectl get pod xxx -o yaml查看是否挂载pvc

kubectl get pod mongo-0 -o yaml

 

    至此，一个由3个实例组成的MongoDB集群就创建完成了，其中每个实例都拥有稳定的名称和独立的存储空间。

小结：

         今天的内容就到这里了，明天继续讲解。

          谢谢大家的关注，与支持