k8s学习之路 | k8s 工作负载 StatefulSet

1. StatefulSet 基础

1.1 什么是 sts

StatefulSet 是用来管理有状态应用的工作负载 API 对象，也是一种工作负载资源

有状态和无状态

无状态应用：当前应用不会记录状态（网络可能会变、挂载的东西可能会变、顺序可能会变）

有状态应用：需要记录当前状态（网络不变、存储不变、顺序不变）

sts

• 管理某一类 Pod 集合的部署喝扩缩
• 给这一类 Pod 提供持久存储和持久标识符

对比 deploy

• 都是管理着有相同容器规约的一组 Pod

• sts 给这些 Pod 维护了一个有粘性的 ID，虽然这些 Pod 都是基于相同的规约来创建的，但是不能相互替换，不管怎么调度，每个 Pod 都有一个永久不变的 ID

• 虽然单个 Pod 会有故障的风险，但是持久的 Pod 标识符使得新旧 Pod 相匹配更加容器

一个来自官方的示例

###改了一下
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默认值是 1
  minReadySeconds: 10 # 默认值是 0
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx:1.23

运行一下

[root@k8s-01 k8s-yaml]# kubectl apply -f sts.yaml
service/nginx created		
statefulset.apps/web created
[root@k8s-01 k8s-yaml]#

1.2 sts 使用场景

StatefulSet 对于需要满足以下一个或多个需求的应用程序很有价值：

• 稳定的、唯一的网络标识符
• 稳定的、持久的存储
• 有序的、优雅的部署和扩缩
• 有序的、自动的滚动更新

1.3 sts 资源的编写

参考官方定义：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/

还是老规矩吧，通过官网加kubectl explain sts配合着来

• apiVersion: apps/v1
• kind: StatefulSet
• metadata：标准的对象元数据
• spec：Pod 模板

spec

[root@k8s-01 k8s-yaml]# kubectl explain sts.spec
KIND:     StatefulSet
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired identities of pods in this set.

     A StatefulSetSpec is the specification of a StatefulSet.

FIELDS:
## podManagementPolicy 控制在初始规模扩展期间、替换节点上的 Pod 或缩减集合规模时如何创建 Pod。 默认策略是 “OrderedReady”，各个 Pod 按升序创建的（pod-0，然后是pod-1 等）， 控制器将等到每个 Pod 都准备就绪后再继续。缩小集合规模时，Pod 会以相反的顺序移除。 另一种策略是 “Parallel”，意味着并行创建 Pod 以达到预期的规模而无需等待，并且在缩小规模时将立即删除所有 Pod
   podManagementPolicy  <string>
     podManagementPolicy controls how pods are created during initial scale up,
     when replacing pods on nodes, or when scaling down. The default policy is
     `OrderedReady`, where pods are created in increasing order (pod-0, then
     pod-1, etc) and the controller will wait until each pod is ready before
     continuing. When scaling down, the pods are removed in the opposite order.
     The alternative policy is `Parallel` which will create pods in parallel to
     match the desired scale without waiting, and on scale down will delete all
     pods at once.
## replicas 是给定模板的所需的副本数。之所以称作副本，是因为它们是相同模板的实例，不过各个副本也具有一致的身份。如果未指定，则默认为 1。
   replicas     <integer>
     replicas is the desired number of replicas of the given Template. These are
     replicas in the sense that they are instantiations of the same Template,
     but individual replicas also have a consistent identity. If unspecified,
     defaults to 1.
## revisionHistoryLimit 是在 StatefulSet 的修订历史中维护的修订个数上限。 修订历史中包含并非由当前所应用的 StatefulSetSpec 版本未表示的所有修订版本。默认值为 10。
   revisionHistoryLimit <integer>
     revisionHistoryLimit is the maximum number of revisions that will be
     maintained in the StatefulSet's revision history. The revision history
     consists of all revisions not represented by a currently applied
     StatefulSetSpec version. The default value is 10.
## selector 是对 Pod 的标签查询，查询结果应该匹配副本个数。 此选择算符必须与 Pod 模板中的 label 匹配
   selector