k8s replicaSet，deployment 学习笔记

replicaSet 和 deployment 两者的关系。

在 Kubernetes 中，ReplicaSet 和 Deployment 都是用来确保某种 Pod 的副本数目。但是，ReplicaSet 和 Deployment 是有差别的，二者的关系可以粗略地理解为 Deployment 对 ReplicaSet 的进一步封装。

1. ReplicaSet 是为了确保任意时刻都有特定数量的 Pod 副本在运行。换句话说，如果有 Pod 出现故障被删除，ReplicaSet 会自动创建新的 Pod 来替代。但 ReplicaSet 本身并不支持滚动更新，如果要更新 Pod，就需要手动删除老的 Pod，然后 ReplicaSet 会自动创建新的 Pod。

2. Deployment 是一个更高层次的概念，它管理 ReplicaSet，并提供了声明式更新的能力。它包含了 ReplicaSet 所有的功能，并且增加了版本更新的功能。当有新的版本需要部署时，Deployment 会自动创建一个新的 ReplicaSet，并逐步将老的 Pod 替换为新的 Pod，直到达到预期的 Pod 数量。这个过程是滚动更新。

总结起来，Deployment 是对 ReplicaSet 进一步的封装，提供了滚动更新的能力，使得更新 Pod 变得更加方便。在实际使用中，大部分时候都是直接使用 Deployment，很少直接使用 ReplicaSet。

创建

nginx-deploy.yaml

apiVersion: apps/v1   # deployment api版本
kind: Deployment  # 资源类型为deployment
metadata: # 元信息labels: # 标签app: nginx-deployname: nginx-deploy    # deployment的名字namespace: default
spec:replicas: 3  #副本数量revisionHistoryLimit: 10  #进行滚动更新后保留的副本数量selector: #选择器，用于找到匹配的rsmatchLabels:app: nginx-deploystrategy: #更新策略rollingUpdate:  #滚动更新策略maxSurge: 25%		# 后面的滚动更新中会详细介绍maxUnavailable: 25%	# 后面的滚动更新中会详细介绍type: RollingUpdatetemplate:metadata:creationTimestamp: nulllabels:app: nginx-deployspec:containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresent #拉取策略name: nginxresources:limits:cpu: 50mmemory: 128Mirequests:cpu: 50mmemory: 128MiterminationMessagePath: /dev/termination-logterminationMessagePolicy: FilerestartPolicy: Always #重启策略terminationGracePeriodSeconds: 30 #删除操作最多宽限多长时间

kb create -f nginx-deploy.yaml

由上图可知，创建了一个deployment，这个deployment管理着一个rs，而这个rs管理这个三个replica。

kb describe deploy nginx-deploy

滚动更新

maxSurge 和 maxUnavailable 是 Kubernetes 的 Deployment 对象中用于控制滚动更新策略的两个参数。
这两个参数的合理配置可以确保滚动更新过程中服务的连续性和资源的高效利用。

1. maxSurge：这个参数表示滚动更新过程中，新副本 Pod 能超过原始 replicas 数量的最大值。例如，如果 replicas 为3，maxSurge 为1，那么滚动更新过程中最多可以有4个 Pod 同时运行。这个参数可以是绝对数量（例如，1），也可以是相对于 replicas 的百分比（例如，10%）。值得注意的是，当你设置的 maxSurge 和 maxUnavailable 都为0时，Kubernetes将不会允许这样的配置，因为这样就无法完成滚动更新。

2. maxUnavailable：这个参数表示滚动更新过程中，可以同时不可用的老副本 Pod 个数的最大值。例如，如果 replicas 为3，maxUnavailable 为1，那么滚动更新过程中，最多可以有1个老的 Pod 不可用。这个参数也可以是绝对数量或者相对于 replicas 的百分比。同样，如果 maxSurge 和 maxUnavailable 都设为0，Kubernetes 是不会接受的。

滚动更新流程
这个滚动更新的过程确保了服务在更新过程中的不中断，提供了零停机时间的更新体验。同时，通过灵活设置 maxSurge 和 maxUnavailable 参数，我们可以平衡服务的稳定性和资源的利用率。

1. 当你更新了 Deployment 的配置（例如，更改了 Pod 的 Docker 镜像）后，Deployment 会创建一个新的 ReplicaSet 并将 maxSurge 参数设定的额外 Pods 数量添加到新的 ReplicaSet 中。这意味着新的 Pod 已经启动并准备接受请求。
2. 一旦这些新的 Pod 就绪并开始运行，Deployment 会按照你设置的 maxUnavailable 参数的值，停止相应数量的旧的 Pods。这些被停止的 Pods 被新的 Pods 替代。这个终止和启动 Pods 的过程被称为 “滚动更新”。
3. 如果在更新过程中新的 Pod 出现问题，Deployment 将停止创建新的 Pod 并开始回滚。这意味着，它会停止新的 Pods，并开始回滚到旧的 ReplicaSet。
4. 如果新的 Pod 正常运行，Deployment 会继续停止更多的旧的 Pods，启动新的 Pods，直至所有的旧的 Pods 都被新的 Pods 替代。此时，更新完成。

注意，Deployment 还记录了所有的旧的 ReplicaSet（即历史版本），以便于在必要时回滚到旧的版本。

1. kb edit deploy nginx-deploy，修改镜像。
   

2. kb describe deploy nginx-deploy，查看deploy更新event事件。
   

3. 查看deploy，rs，pod
   

总结：deploy滚动更新并不是直接删除rs然后创建新rs；它是保持已有的rs不变，创建一个新的rs，然后根据yaml里设置的maxSurge和maxUnavailable；例如，我这里都是设置为1，所以在event里可以看到deploy每次在新的rs里创建一个pod，然后在旧的rs里关闭一个pod，如此这般操作直到旧的rs里的pod数量为0完全关闭，新的rs里的pod数量为3，至此滚动更新成功。

回滚

假设我们更新的nigin1.9.1版本是有问题的，那么我们就需要回退到之前的1.7.9。

1. 查看历史版本。
   

2. 查看指定版本的信息。
   

3. 回退之前先看看当前的deploy信息，kb describe deploy nginx-deploy
   

4. 版本1就是我们需要回退的目标版本，回退到版本1。
   

5. kb describe deploy nginx-deploy；查看回退之后的deploy信息。
   

6. 可以看到回退是直接使用之前滚动更新时停用的rs。整个回退过程也是遵循滚动更新的规范，先开一个新的pod再关一个旧的pod，直到pod数量达到要求就完成了回退。