K8s StatefulSet 的高级扩缩容与滚动更新策略：零停机操作

各位观众老爷，大家好！我是你们的老朋友——码农张三！今天咱们不聊996的血泪史，也不谈秃头少女的悲惨遭遇，咱们来聊聊Kubernetes界里的“贵族”——StatefulSet，以及如何让这位“贵族”在扩容和更新时，依然保持优雅，做到真正的“零停机”！

想象一下，你运营着一个电商平台，背后撑起整个平台的是一个庞大的数据库集群，用的就是StatefulSet。如果某天，流量突然暴增，你急需扩容数据库，但又不能让数据库停下来，否则用户下单就成了“薛定谔的猫”，下单了也不知道有没有成功。或者，你发现数据库有个严重的Bug，需要紧急更新，但又不想让用户体验受到影响，毕竟谁也不想付款的时候看到一个“页面走丢了”的提示吧？

所以，今天我们就来解剖一下，如何利用StatefulSet的高级特性，让你的服务在扩容和更新的时候，像一只优雅的芭蕾舞者，旋转跳跃，我闭着眼（用户毫无感知）！

一、StatefulSet：自带光环的“贵族”

首先，我们来简单回顾一下StatefulSet。简单来说，它就是Kubernetes里专门用来管理有状态应用的控制器。啥叫有状态应用呢？就是那些需要持久化存储、需要稳定网络标识、需要按照特定顺序启动的应用，比如数据库、消息队列、缓存等等。

与Deployment相比，StatefulSet最大的特点就是它的Pod是有“身份”的。每个Pod都有一个唯一的、稳定的hostname和存储卷。这就保证了即使Pod被重新调度，它的数据和身份依然保持不变。这就像是古代的皇子，每个人都有自己的封号和领地，即使被贬谪，身份也不会改变。

StatefulSet的优势，总结起来有以下几点：

稳定的网络标识符 (Stable Network Identifiers): 每个Pod都有一个固定的hostname，格式为<statefulset-name>-<ordinal>，比如 my-app-0, my-app-1。
稳定的持久化存储 (Stable, Persistent Storage): 每个Pod都可以绑定一个PersistentVolumeClaim（PVC），保证数据的持久化存储，即使Pod被删除或重新调度，数据依然存在。
有序的部署和扩缩容 (Ordered Deployment and Scaling): Pod的创建和删除都是按照顺序进行的，从0开始，依次递增。这保证了依赖关系的正确性，比如主从数据库的启动顺序。
有序的滚动更新 (Ordered Rolling Updates): 更新也是按照顺序进行的，从最大的序号开始，依次递减。

二、扩容：让服务像吹气球一样膨胀！🎈

扩容，简单来说就是增加Pod的数量，以应对日益增长的流量。对于StatefulSet来说，扩容的过程是相对简单的，只需要修改replicas的值即可。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-app
spec:
  replicas: 3  # 初始副本数为3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        ports:
        - containerPort: 8080

假设我们需要将副本数增加到5，只需要将replicas的值修改为5，然后执行 kubectl apply -f your-statefulset.yaml 即可。

但是，问题来了！直接修改replicas的值，Kubernetes会按照顺序创建新的Pod，但是这些新的Pod如何加入到现有集群中呢？这就要依赖于应用程序自身的逻辑了。

这里提供几种常用的方法：

使用Service Discovery: 应用程序可以通过Service Discovery机制来发现新的Pod。比如，可以使用Kubernetes自带的DNS服务，或者使用Consul、etcd等服务发现工具。新Pod启动后，会自动注册到Service Discovery系统中，其他Pod就可以发现它并与之建立连接。这就像是新来的员工主动向大家介绍自己，然后加入到团队中。
使用Leader Election: 如果应用程序需要选举一个Leader，可以使用Leader Election机制。新的Pod启动后，会参与到Leader的选举中。如果它被选为Leader，就会接管一部分流量，从而分担现有Leader的压力。这就像是选班长一样，选出一位有能力的新班长，来分担老班长的任务。
使用Configuration Management: 可以使用Configuration Management工具（如Ansible、Chef、Puppet）来配置新的Pod。新Pod启动后，会自动从Configuration Management服务器拉取配置，并加入到现有集群中。这就像是新员工入职后，HR会给他一份详细的入职指南，告诉他该如何操作。

表格：StatefulSet扩容策略对比

策略	优点	缺点	适用场景
Service Discovery	自动化程度高，无需手动配置	需要应用程序支持Service Discovery	分布式系统，需要自动发现和注册服务
Leader Election	可以保证集群的可用性，避免单点故障	需要应用程序支持Leader Election	需要选举Leader的场景，如数据库主从切换
Configuration Management	灵活性高，可以自定义配置	需要手动配置，维护成本较高	需要精细化配置的场景，如数据库参数调优

三、滚动更新：像换轮胎一样平稳！🚗

滚动更新，就是在不停止服务的情况下，逐步更新Pod的镜像版本。对于StatefulSet来说，Kubernetes提供了多种滚动更新策略。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-app
spec:
  updateStrategy:
    type: RollingUpdate  # 使用滚动更新策略
    rollingUpdate:
      partition: 2     # 设置partition
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:v2  # 新的镜像版本
        ports:
        - containerPort: 8080

常用的滚动更新策略有以下几种：

RollingUpdate: 这是StatefulSet默认的更新策略。它会按照顺序，从序号最大的Pod开始，依次更新到序号最小的Pod。在更新过程中，Kubernetes会先创建一个新的Pod，然后再删除旧的Pod。这保证了在任何时候，集群中都有可用的Pod。
OnDelete: 这种策略比较简单粗暴。它不会自动更新Pod，而是需要手动删除Pod，然后Kubernetes会自动创建新的Pod。这种策略适用于对可用性要求不高的场景。
Partitioned RollingUpdate: 这是RollingUpdate的一个变种，它允许你指定一个partition值。Kubernetes只会更新序号大于等于partition的Pod。这可以让你逐步更新Pod，先更新一部分Pod进行测试，然后再更新剩余的Pod。这就像是灰度发布，先让一部分用户体验新版本，然后再推广到所有用户。

这里重点讲一下Partitioned RollingUpdate，它在零停机更新中扮演着重要的角色。

假设我们有一个包含5个Pod的StatefulSet，partition设置为2。那么，Kubernetes只会更新my-app-2、my-app-3、my-app-4这三个Pod。my-app-0和my-app-1会保持原来的版本。

如何实现零停机更新呢？

预热： 在更新之前，先创建一个新的StatefulSet，使用新的镜像版本，但是replicas设置为0。然后，逐渐增加replicas的值，让新的Pod启动并预热。这就像是热身运动，先让身体活动起来，然后再进行剧烈运动。
流量切换： 使用Service的selector，将一部分流量切换到新的StatefulSet。这可以通过修改Service的selector来实现，也可以使用Ingress Controller来实现。这就像是分流，先让一部分用户体验新版本，看看有没有问题。
Partitioned RollingUpdate： 使用Partitioned RollingUpdate，逐步更新旧的StatefulSet。每次更新一部分Pod，然后观察一段时间，确保没有问题后再继续更新。这就像是逐步蚕食，一点一点地替换旧版本。
回滚： 如果在更新过程中发现问题，可以立即将partition的值设置为0，停止更新，并将流量切换回旧的StatefulSet。这就像是紧急刹车，一旦发现问题，立即停止并返回到安全状态。

表格：滚动更新策略对比

策略	优点	缺点	适用场景
RollingUpdate	自动化程度高，保证可用性	更新时间较长，可能会影响性能	大多数场景，对可用性要求较高的场景
OnDelete	简单粗暴，更新速度快	需要手动干预，可能会导致服务中断	对可用性要求不高的场景，或者需要手动控制更新过程的场景
Partitioned RollingUpdate	可以逐步更新，方便灰度发布，易于回滚	需要手动配置，维护成本较高	需要灰度发布的场景，或者需要逐步更新的场景，如数据库升级

四、实战演练：以数据库为例

我们以一个简单的MySQL数据库集群为例，来演示如何使用StatefulSet进行零停机扩容和滚动更新。

1. 定义StatefulSet：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "your_password"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

2. 定义Service：

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector:
    app: mysql
  ports:
  - port: 3306
    targetPort: 3306

3. 扩容：

将replicas的值修改为5，然后执行 kubectl apply -f your-statefulset.yaml。新的MySQL实例会自动加入到集群中，并可以通过Service进行访问。

4. 滚动更新：

假设我们需要将MySQL版本升级到8.0，可以按照以下步骤进行：

修改镜像版本： 将image的值修改为 mysql:8.0。
设置partition： 将updateStrategy.rollingUpdate.partition的值设置为2。
执行更新： 执行 kubectl apply -f your-statefulset.yaml。
观察： 观察mysql-2、mysql-3、mysql-4这三个Pod的更新状态。
逐步更新： 如果一切正常，将partition的值设置为1，然后再次执行 kubectl apply -f your-statefulset.yaml。
完成更新： 最后，将partition的值设置为0，完成所有Pod的更新。

五、总结：优雅的谢幕！ 👏

今天我们一起探讨了StatefulSet的高级扩缩容与滚动更新策略，并以MySQL数据库为例进行了实战演练。希望通过这篇文章，能够帮助大家更好地理解和使用StatefulSet，让你的服务在扩容和更新的时候，像一只优雅的芭蕾舞者一样，旋转跳跃，我闭着眼（用户毫无感知）！

记住，零停机操作的关键在于：预热、分流、逐步更新、及时回滚。掌握了这些技巧，你就能轻松应对各种复杂的场景，成为Kubernetes界的“弄潮儿”！

最后，感谢大家的观看！下次再见！ 👋

发表回复 取消回复

发表回复取消回复