Kubernetes调度基础——Deployment 无状态应用

本博客用于Deployment 无状态的学习

在 Kubernetes 中，Deployment 是最常用的 Pod 控制器，一般用于部署企业内部的无状态服务(微服务居多)，可利用 Deployment 的高级功能做到无缝迁移、自动扩缩容、自动容灾、一键回滚等功能。

知识点：

1. 在k8s中，有状态应用和无状态应用的区别？创建有状态和无状态应用分别使用哪种资源对象类型？

   • 区别：

     • 有状态应用：需要持久化存储，保持唯一标识和稳定网络标识（如数据库）

     • 无状态应用：不需要持久化存储，各实例可互换（如web前端）

   • 资源对象类型：

     • 有状态：StatefulSet

     • 无状态：Deployment

无状态和有状态应用特性

1. 无状态应用：

不将数据或应用状态存储到集群或永久性存储空间的应用。

常见的无状态应用包括 Web 服务器、负载均衡器、静态文件服务器等。

以 web 服务器为例：客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份，服务端不 会保存任何客户端请求者信息。

无状态应用特点：

易于扩展：由于无状态应用不保存请求状态，因此可以轻松地将它们部署在多个服务器上，从而实 现水平扩展。

高可用性：由于无状态应用的每个请求都是独立的，因此即使某个请求失败，也不会影响其他请求 的处理。这有助于提高应用的可用性。

安全性：无状态应用通常不保存敏感数据，因此不太可能泄露敏感信息。

可替代性：由于无状态应用不保存请求状态，因此不同的服务器可以处理相同的请求，这意味着任 何一个服务器都可以替代其他服务器来处理请求。

2. 有状态应用：

应用程序的处理需要依赖特定的状态或数据存储。

“有状态应用”的例子有很多，比如 Redis、MySQL 这样的数据库，它们的“状态”就是在内存或者磁盘上 产生的数据，是应用的核心价值所在，如果不能够把这些数据及时保存再恢复，那绝对会是灾难性的后 果。

有状态应用特点：

依赖状态：应用程序的处理依赖于特定的状态信息。

数据持久化：有状态应用通常需要将状态数据持久化存储，以便后续请求可以访问和使用。

有序性：由于有状态应用处理请求时依赖先前的状态，因此请求之间的顺序可能很重要。

1.创建 Deployment

kubectl create deploy nginx --image=nginx:1.24.0 --replicas=4 -o yaml --dry-run=client > nginx-dp.yaml

2. 修改生成的 Deploy 文件，修改yaml如下：

vim nginx-dp.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.24.0
        name: nginx
        ports:
        - containerPort: 80

kubectl create -f nginx-dp.yaml
kubectl get deployments.apps #查看默认命名空间下deployment所有资源
#名称  准备状态  期望副本数   可使用副本数  运行时间
kubectl get pod # 查看默认命名空间下的所有pods
kubectl rollout status deployment nginx #查看整个deployment创建状态
kubectl get rs -l app=nginx #查看deployment对应的RS，-l指定标签

3.测试副本数量控制机制

查看pods，删除一个 deployment 的 pod

kubectl get pod kubectl delete po nginx-595dff4799-59xwx

再查看 pod 资源列表

kubectl get po

为保持之前定义的数量4，所以deployment会再次新建一个pod

4.更新 Deployment

更新当前 Deployment 的 Nginx Pod 的底层镜像模板，并使用 --record 记录当前更改的参数，方便后 期回滚更新。

也可使用 “kubectl edit deployments.apps nginx”命令对 deployment 资源编辑再更新，后面的 nginx 为 deployment 资源名。

# 更新镜像版本
kubectl set image deployment nginx nginx=nginx:1.25.0 --record
# 或者使用编辑方式更新
kubectl edit deployments.apps nginx

kubectl get pod

可以看到之前的nginx-595dff4799的pod正渐渐退出，新nginx慢慢产生，完成后将保持4个pod数量（下面的图片不是很直观，只是一个对比图）

kubectl get rs

查看replicaSet资源列表，之前的rs控制器nginx-595dff4799下的pod已经清空了，剩的是新生成的 rs资源

注意: 当且仅当 Deployment 的 Pod 模板 (即.spec.template) 更改时，才会触发，Deployment更新， 例如更改内存、CPU 配置或者容器的 image。

5.回滚 Deployment

# 查看更新历史
kubectl rollout history deployment nginx

# 查看特定版本详情
kubectl rollout history deployment nginx --revision=1

# 回滚到上一版本
kubectl rollout undo deployment nginx

# 回滚到指定版本
kubectl rollout undo deployment nginx --to-revision=2

查看更新历史，有1，2版本

查看特定版本1的详情

回滚到上一版本1

回滚到指定版本2

完整示例：

6.扩容 Deployment

# 命令行扩容
kubectl scale deployment nginx --replicas=7

# 编辑 YAML 扩容
kubectl edit deployments.apps nginx  # 修改 replicas 值

kubectl get po

从原来的四个扩容到七个，前后对比图

kubectl edit 调整副本数量，从七个修改成5个，并查看

7.暂停和恢复 Deployment 更新

# 暂停更新
kubectl rollout pause deployment nginx

# 在暂停状态下进行多项更新
kubectl set image deploy nginx nginx=nginx:1.19.0
kubectl set resources deploy nginx -c=nginx --limits=cpu=200m,memory=256Mi
#注意手动多处更新，不会被记录，可使用命令 kubectl rollout history deployment nginx 查看记录

# 恢复更新
kubectl rollout resume deployment nginx

#查看 deployment 描述信息，更新完成
kubectl rollout history deployment nginx

从版本1.25.0更新为1.19.0，cpu和memory也修改了

8.更新策略配置

历史版本清理策略

在默认情况下，revision 保留 10 个旧的 ReplicaSet，其余的将在后台进行垃圾回收，可以在 yaml 文件 内 .spec.revisionHistoryLimit 设置保留 ReplicaSet，当设置为 0 时不保留历史记录。

更新策略

yaml 文件内修改配置：

1. .spec.strategy.type==Recreate，表示重建，先删掉旧的 Pod 再创建新的 Pod

2. .spec.strategy.type==RollingUpdate，表示滚动更新，可以指定maxUnavailable和maxSurge 来 控制滚动更新过程

3. .spec.strategy.rollingUpdate.maxUnavailable，指定在回滚更新时最大不可用的Pod数量，可选 字段，默认为25%，可以设置为数字或百分比，如果 maxSurge 为 0，则该值不能为 0

4. .spec.strategy.rollingUpdatemaxSurge 可以超过期望值的最大 Pod 数，可选字段，默认为 25%，p 以设置成数字或百分比，如果 maxUnavailable为 0，则该值不能为 0。

Ready 策略 .spec.minReadySeconds 是可选参数，指定新创建的 Pod 应该在没有任何容器崩溃的情况下视Ready (就绪)状态的最小秒数，默认为 0，即一旦被创建就视为可用，通常和容器探针连用。

# 方法1：编辑现有Deployment（根据个人情况，编辑的文件名可能不同）
kubectl edit deployments.apps nginx
# 方法2：修改YAML文件后重新apply
kubectl apply -f deployment.yaml

spec:
  strategy:
    type: RollingUpdate  # 或 Recreate
    rollingUpdate:
      maxUnavailable: 25%  # 最大不可用比例
      maxSurge: 25%       # 最大超出比例
  revisionHistoryLimit: 10 # 历史版本保留数量
  minReadySeconds: 0      # Pod 就绪最小等待时间

总结

这个文档展示了 Kubernetes Deployment 的核心功能：

（1）声明式管理 Pod 副本集

（2）滚动更新和无缝迁移

（3）版本回滚能力

（4）弹性扩缩容

（5）更新策略控制

Deployment 是管理无状态应用(如微服务)的理想选择，它提供了高可用性、自动恢复和灵活的更新策略，是 Kubernetes 中最常用的控制器之一。