做网站算新媒体运营吗,网站底部版权信息格式,wordpress cdn配置,做网站需要执照嘛文章目录 replicaSet 和 deployment 两者的关系。创建滚动更新回滚 replicaSet 和 deployment 两者的关系。
在 Kubernetes 中#xff0c;ReplicaSet 和 Deployment 都是用来确保某种 Pod 的副本数目。但是#xff0c;ReplicaSet 和 Deployment 是有差别的#xff0c;二者的… 文章目录 replicaSet 和 deployment 两者的关系。创建滚动更新回滚 replicaSet 和 deployment 两者的关系。
在 Kubernetes 中ReplicaSet 和 Deployment 都是用来确保某种 Pod 的副本数目。但是ReplicaSet 和 Deployment 是有差别的二者的关系可以粗略地理解为 Deployment 对 ReplicaSet 的进一步封装。 ReplicaSet 是为了确保任意时刻都有特定数量的 Pod 副本在运行。换句话说如果有 Pod 出现故障被删除ReplicaSet 会自动创建新的 Pod 来替代。但 ReplicaSet 本身并不支持滚动更新如果要更新 Pod就需要手动删除老的 Pod然后 ReplicaSet 会自动创建新的 Pod。 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 对象中用于控制滚动更新策略的两个参数。 这两个参数的合理配置可以确保滚动更新过程中服务的连续性和资源的高效利用。 maxSurge这个参数表示滚动更新过程中新副本 Pod 能超过原始 replicas 数量的最大值。例如如果 replicas 为3maxSurge 为1那么滚动更新过程中最多可以有4个 Pod 同时运行。这个参数可以是绝对数量例如1也可以是相对于 replicas 的百分比例如10%。值得注意的是当你设置的 maxSurge 和 maxUnavailable 都为0时Kubernetes将不会允许这样的配置因为这样就无法完成滚动更新。 maxUnavailable这个参数表示滚动更新过程中可以同时不可用的老副本 Pod 个数的最大值。例如如果 replicas 为3maxUnavailable 为1那么滚动更新过程中最多可以有1个老的 Pod 不可用。这个参数也可以是绝对数量或者相对于 replicas 的百分比。同样如果 maxSurge 和 maxUnavailable 都设为0Kubernetes 是不会接受的。 滚动更新流程 这个滚动更新的过程确保了服务在更新过程中的不中断提供了零停机时间的更新体验。同时通过灵活设置 maxSurge 和 maxUnavailable 参数我们可以平衡服务的稳定性和资源的利用率。 当你更新了 Deployment 的配置例如更改了 Pod 的 Docker 镜像后Deployment 会创建一个新的 ReplicaSet 并将 maxSurge 参数设定的额外 Pods 数量添加到新的 ReplicaSet 中。这意味着新的 Pod 已经启动并准备接受请求。一旦这些新的 Pod 就绪并开始运行Deployment 会按照你设置的 maxUnavailable 参数的值停止相应数量的旧的 Pods。这些被停止的 Pods 被新的 Pods 替代。这个终止和启动 Pods 的过程被称为 “滚动更新”。如果在更新过程中新的 Pod 出现问题Deployment 将停止创建新的 Pod 并开始回滚。这意味着它会停止新的 Pods并开始回滚到旧的 ReplicaSet。如果新的 Pod 正常运行Deployment 会继续停止更多的旧的 Pods启动新的 Pods直至所有的旧的 Pods 都被新的 Pods 替代。此时更新完成。 注意Deployment 还记录了所有的旧的 ReplicaSet即历史版本以便于在必要时回滚到旧的版本。 kb edit deploy nginx-deploy修改镜像。 kb describe deploy nginx-deploy查看deploy更新event事件。 查看deployrspod 总结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。 查看历史版本。 查看指定版本的信息。 回退之前先看看当前的deploy信息kb describe deploy nginx-deploy 版本1就是我们需要回退的目标版本回退到版本1。 kb describe deploy nginx-deploy查看回退之后的deploy信息。 可以看到回退是直接使用之前滚动更新时停用的rs。整个回退过程也是遵循滚动更新的规范先开一个新的pod再关一个旧的pod直到pod数量达到要求就完成了回退。
