这里将介绍Kubernetes工作负载资源中的StatefulSet

创建StatefulSet

不同于RC、RS、Deployment可以用于部署无状态的应用。而对于有状态的应用而言，其要求Pod需要具有稳定的、唯一的网标识符，稳定的、持久的存储。这对于RS、Deployment而言是无法满足的。为此K8s中提供了一种专用于有状态应用的StatefulSet，其可以保证当一个有状态的Pod被删除后(比如人工手动删除)，K8s则会创建一个与之完全一致的Pod出来，包括Pod名称、网络主机名、存储等

对于StatefulSet的Pod而言，即使其被重新调度到别的节点，其也必须挂载旧Pod此前所使用的存储。为此Pod所使用的必须是PV持久卷，且需要与Pod解耦。故需要将每个Pod绑定各自的PVC持久卷声明。为此在StatefulSet的定义中，我们需设置PVC模板即可。以便StatefulSet能够按照PVC模板创建出与Pod数量相同的PVC。而PV持久卷则既可以是管理员提前创建的，也可以是动态制备的

这里我们先手动创建两个PV

# 创建持久卷PV

apiVersion: v1
kind: PersistentVolume
metadata:
  # PV卷名称
  name: pv-a
spec:
  # 容量
  capacity: 
    # 存储大小: 30MB
    storage: 30Mi
  # 该卷支持的访问模式
  accessModes:
    - ReadWriteOnce # RWO, 该卷可以被一个节点以读写方式挂载
    - ReadOnlyMany  # ROX, 该卷可以被多个节点以只读方式挂载
  # 回收策略: 保留
  persistentVolumeReclaimPolicy: Retain
  # 该持久卷的实际存储类型: 此处使用HostPath类型卷
  hostPath:
    path: /tmp/PvA

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-b
spec:
  capacity: 
    storage: 30Mi
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /tmp/PvB

---

效果如下所示

对于StatefulSet而言，其还需要提前创建一个Headless Service

# 创建 Headless Service

apiVersion: v1
kind: Service
metadata:
  name: my-kubia-headless-service
spec:
  type: ClusterIP
  # 对于ClusterIP类型服务而言, 当clusterIP为None时表示这是一个Headless Service
  clusterIP: None
  selector:
    app: my-kubia
  ports:
  - port: 12121 # 服务监听端口
    targetPort: 8080 # 服务将请求转发到Pod的目标端口

现在我们开始创建StatefulSet，配置文件如下所示

# 创建 StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset-kubia
spec:
  # 标签选择器
  selector:
    matchLabels:
      app: my-kubia
  # 设定Headless Service的服务名称
  serviceName: my-kubia-headless-service
  # Pod的副本数
  replicas: 2
  # Pod模板
  template:
    metadata:
      labels:
        # 标签信息
        app: my-kubia
    spec:
      containers:
      - name: my-app-kubia
        image: luksa/kubia-pet
        # 仅用于展示容器所使用的端口
        ports:
          - containerPort: 8080
            protocol: TCP
        volumeMounts:
        # 将名为my-volume-data的卷挂载到容器指定路径/var/data上
        - name: my-volume-data
          mountPath: /var/data
  # PVC模板
  volumeClaimTemplates:
  - metadata:
      # 卷的名称
      name: my-volume-data
    spec:
      # 禁止使用动态制备的卷, 即使用静态制备
      storageClassName: ""
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Mi

效果如下所示，两个Pod分别绑定各自的PVC。而这两个PVC进一步地分别使用了我们之前创建的两个PV。与此同时，对于StatefulSet创建的Pod而言，其名称命名规则是StatefulSet名称加索引编号

测试

该应用支持通过POST请求将数据存储到容器内的/var/data路径下，通过GET请求获取容器内的/var/data路径下的数据内容。这里我们先启动一个代理，然后利用API服务器访问指定的Pod。效果如下所示，符合预期

对于包含N个Pod副本的StatefulSet而言，其会按照索引顺序依次创建N个Pod。即先创建索引为0的Pod，再创建索引为1的Pod，再创建索引为2的Pod，以此类推。而当我们进行缩容的时候，则它们是按照索引逆序的顺序依次终止Pod的，即顺序为N-1、N-2、N-3、...、2、1、0。现在我们将该StatefulSet的Pod副本数缩容为1

# 将StatefulSet的Pod副本数调整为指定数量
kubectl scale statefulset  my-statefulset-kubia --replicas=1

# 将指定名称的StatefulSet的Pod副本数调整为指定数量
kubectl scale statefulset <StatefulSet的名称> --replicas=<Pod的副本数>

效果如下所示。而且即使缩容了，索引1的Pod所使用的PVC、PV也依然会被保留。这样当你再次扩容时，其依然会创建一个索引为1的Pod，且依然会绑定此前索引为1的Pod所使用的PVC。无论这个新Pod会被调度哪个集群节点当中

现在我们重新将该StatefulSet扩容到2。可以看到索引为1的Pod再次使用了之前的PVC。且访问该Pod可以查询到此前的数据，进一步验证了这个结果

查询SRV记录

现在我们创建一个Pod演示如何用于获取该StatefulSet中全部Pod的网络信息

# 创建一个包含dig、ping命令的Pod

apiVersion: v1
kind: Pod
metadata:
  # Pod 名称
  name: my-dnsutils
spec:
  # 容器信息
  containers:  
  - name: my-dnsutils
    # 镜像信息
    image: tutum/dnsutils
    # 设置容器启动时执行的命令、参数
    command:  # 该命令可以保持容器一直运行, 而不会结束退出
      - sleep
      - infinity

在创建StatefulSet时我们指定了一个Headless Service。其目的在于该Headless Service会创建出相应的SRV记录。通过SRV记录我们就可以知道来该服务对应Pod的域名、IP、端口等信息了。其中该StatefulSet的域名规则一般如下所示

# StatefulSet的域名规则
<Headless Service的服务名称>.<命名空间的名称>.svc.cluster.local 

# 通过dig srv命令查询SRV记录
dig srv my-kubia-headless-service.default.svc.cluster.local

效果如下所示。这样我们就可以实现获取StatefulSet中全部Pod的网络地址了

参考文献

1. Kubernetes in Action中文版 Marko Luksa著
2. 深入剖析Kubernetes 张磊著