结合公众号小店做网站,私人20服务器,一键生成小程序免费制作平台,链接生成二维码文章目录 Deployment Deployment
Deployment 实现了 Kubernetes 项目中一个非常重要的功能#xff1a;Pod 的“水平扩展 / 收缩”#xff08;horizontal scaling out/in#xff09;。这个功能#xff0c;是从 PaaS 时代开始#xff0c;一个平台级项目就必须具备的编排能力… 文章目录 Deployment Deployment
Deployment 实现了 Kubernetes 项目中一个非常重要的功能Pod 的“水平扩展 / 收缩”horizontal scaling out/in。这个功能是从 PaaS 时代开始一个平台级项目就必须具备的编排能力。如果你更新了 Deployment 的 Pod 模板比如修改了容器的镜像那么 Deployment 就需要遵循一种叫作“滚动更新”rolling update的方式来升级现有的容器。而这个能力的实现依赖的是 Kubernetes 项目中的一个非常重要的概念API 对象ReplicaSet。ReplicaSet 的结构非常简单可以通过YAML 文件查看一下
apiVersion: apps/v1
kind: ReplicaSet
metadata:name: nginx-setlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9一个 ReplicaSet 对象其实就是由副本数目的定义和一个 Pod 模板组成的。它的定义其实是 Deployment 的一个子集。Deployment 控制器实际操纵的正是这样的 ReplicaSet 对象而不是 Pod 对象。
在具体的实现上这个 Deployment与 ReplicaSet以及 Pod 的关系是怎样的呢 将一个集群中正在运行的多个 Pod 版本交替地逐一升级的过程就是“滚动更新”。 **“滚动更新”的好处是显而易见的。**比如在升级刚开始的时候集群里只有 1 个新版本的 Pod。如果这时新版本 Pod 有问题启动不起来那么“滚动更新”就会停止从而允许开发和运维人员介入。而在这个过程中由于应用本身还有两个旧版本的 Pod 在线所以服务并不会受到太大的影响。当然这也就要求你一定要使用 Pod 的 Health Check 机制检查应用的运行状态而不是简单地依赖于容器的 Running 状态。要不然的话虽然容器已经变成 Running 了但服务很有可能尚未启动“滚动更新”的效果也就达不到了。而为了进一步保证服务的连续性Deployment Controller 还会确保在任何时间窗口内只有指定比例的 Pod 处于离线状态。同时它也会确保在任何时间窗口内只有指定比例的新 Pod 被创建出来。这两个比例的值都是可以配置的默认都是 DESIRED 值的 25%。这个策略是 Deployment 对象的一个字段名叫 RollingUpdateStrategy:
...
spec:
...strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1在上面这个 RollingUpdateStrategy 的配置中maxSurge 指定的是除了 DESIRED 数量之外在一次“滚动”中Deployment 控制器还可以创建多少个新 Pod而 maxUnavailable 指的是在一次“滚动”中Deployment 控制器可以删除多少个旧 Pod。同时这两个配置还可以用前面我们介绍的百分比形式来表示比如maxUnavailable50%指的是我们最多可以一次删除“50%*DESIRED 数量”个 Pod。
Deployment、ReplicaSet 和 Pod 的关系图 Deployment 的控制器实际上控制的是 ReplicaSet 的数目以及每个 ReplicaSet 的属性。而一个应用的版本对应的正是一个 ReplicaSet这个版本应用的 Pod 数量则由 ReplicaSet 通过它自己的控制器ReplicaSet Controller来保证。通过这样的多个 ReplicaSet 对象Kubernetes 项目就实现了对多个“应用版本”的描述。 kubectl rollout undo 命令就能把整个 Deployment 回滚到上一个版本kubectl rollout undo deployment/nginx-deployment
如果我想回滚到更早之前的版本要怎么办呢
首先需要使用 kubectl rollout history 命令查看每次 Deployment 变更对应的版本。还可以通过这个 kubectl rollout history 指令看到每个版本对应的 Deployment 的 API 对象的细节命令kubectl rollout history deployment/nginx-deployment --revision1在 kubectl rollout undo 命令行最后加上要回滚到的指定版本的版本号就可以回滚到指定版本了。命令kubectl rollout undo deployment/nginx-deployment --to-revision1
金丝雀发布Canary Deployment和蓝绿发布Blue-Green Deployment
金丝雀部署优先发布一台或少量机器升级等验证无误后再更新其他机器。优点是用户影响范围小不足之处是要额外控制如何做自动更新。蓝绿部署2组机器蓝代表当前的V1版本绿代表已经升级完成的V2版本。通过LB将流量全部导入V2完成升级部署。优点是切换快速缺点是影响全部用户。
你知道的越多你不知道的越多。
