Rolling Update - 每天5分钟玩转 Docker 容器技术(140)

滚动更新是一次只更新一小部分副本,成功后,再更新更多的副本,最终完成所有副本的更新。滚动更新的最大的好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性。

下面我们部署三副本应用,初始镜像为 httpd:2.2.31,然后将其更新到 httpd:2.2.32。

httpd:2.2.31 的配置文件如下:

通过 kubectl apply 部署。

部署过程如下:

  1. 创建 Deployment httpd
  2. 创建 ReplicaSet httpd-551879778
  3. 创建三个 Pod
  4. 当前镜像为 httpd:2.2.31

将配置文件中 httpd:2.2.31 替换为 httpd:2.2.32,再次执行 kubectl apply

我们发现了如下变化:

  1. Deployment httpd 的镜像更新为 httpd:2.2.32
  2. 新创建了 ReplicaSet httpd-1276601241,镜像为 httpd:2.2.32,并且管理了三个新的 Pod。
  3. 之前的 ReplicaSet httpd-551879778 里面已经没有任何 Pod。

结论是:ReplicaSet httpd-551879778 的三个 httpd:2.2.31 Pod 已经被 ReplicaSet httpd-1276601241 的三个 httpd:2.2.32 Pod 替换了。

具体过程可以通过 kubectl describe deployment httpd 查看。

每次只更新替换一个 Pod:

  1. ReplicaSet httpd-1276601241 增加一个 Pod,总数为 1。
  2. ReplicaSet httpd-551879778 减少一个 Pod,总数为 2。
  3. ReplicaSet httpd-1276601241 增加一个 Pod,总数为 2。
  4. ReplicaSet httpd-551879778 减少一个 Pod,总数为 1。
  5. ReplicaSet httpd-1276601241 增加一个 Pod,总数为 3。
  6. ReplicaSet httpd-551879778 减少一个 Pod,总数为 0。

每次替换的 Pod 数量是可以定制的。Kubernetes 提供了两个参数 maxSurge 和 maxUnavailable 来精细控制 Pod 的替换数量,我们将在后面结合 Health Check 特性一起讨论。

下一节我们讨论如何回滚。

书籍:
1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

原文地址:http://blog.51cto.com/cloudman/2085355

时间: 2024-10-09 10:38:12

Rolling Update - 每天5分钟玩转 Docker 容器技术(140)的相关文章

外网如何访问 Service?- 每天5分钟玩转 Docker 容器技术(139)

除了 Cluster 内部可以访问 Service,很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部.Kubernetes 提供了多种类型的 Service,默认是 ClusterIP. ClusterIP Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP. NodePort Service 通过 Cluster 节

在 Scale Up 中使用 Health Check - 每天5分钟玩转 Docker 容器技术(

对于多副本应用,当执行 Scale Up 操作时,新副本会作为 backend 被添加到 Service 的负责均衡中,与已有副本一起处理客户的请求.考虑到应用启动通常都需要一个准备阶段,比如加载缓存数据,连接数据库等,从容器启动到正真能够提供服务是需要一段时间的.我们可以通过 Readiness 探测判断容器是否就绪,避免将请求发送到还没有 ready 的 backend. 下面是示例应用的配置文件. 重点关注 readinessProbe 部分.这里我们使用了不同于 exec 的另一种探测方

Kubernetes Dashboard - 每天5分钟玩转 Docker 容器技术(173)

前面章节 Kubernetes 所有的操作我们都是通过命令行工具 kubectl 完成的.为了提供更丰富的用户体验,Kubernetes 还开发了一个基于 Web 的 Dashboard,用户可以用 Kubernetes Dashboard 部署容器化的应用.监控应用的状态.执行故障排查任务以及管理 Kubernetes 各种资源. 在 Kubernetes Dashboard 中可以查看集群中应用的运行状态,也能够创建和修改各种 Kubernetes 资源,比如 Deployment.Job.

如何访问 Service?- 每天5分钟玩转 Docker 容器技术(99)

前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性.不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题. 为了便于分析,我们重新部署 web_server. ① docker service rm 删除 web_server,service 的所有副本(容器)都会被删除. ② 重新创建 service,这次直接用 --replicas=2 创建两个副本. ③ 每个 worker node 上运行了一个副本. 好了,

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv

验证 Swarm 数据持久性 - 每天5分钟玩转 Docker 容器技术(104)

上一节我们成功将 Rex-Ray Volume 挂载到了 Service.本节验证?Failover 时,数据不会丢失. Scale Up 增加一个副本: docker?service?update?--replicas?2?my_web 运行之前我们先推测一下,理想的结果应该是:swarm 在?swarm-worker2?上启动第二个副本,同时也将挂载 volume?my_web. 对比一下实际的运行结果: 出现了一点复杂的状况: swarm 首先尝试在?swarm-worker2?上启动第二

用 Label 控制 Service 的位置 - 每天5分钟玩转 Docker 容器技术(106)

上一节我们讨论了 Service 部署的两种模式:global mode 和 replicated mode.无论采用 global mode 还是 replicated mode,副本运行在哪些节点都是由 Swarm 决定的,作为用户我们有没有可能精细控制 Service 的运行位置呢? 答案是:能,使用 label. 逻辑分两步: 为每个 node 定义 label. 设置 service 运行在指定 label 的 node 上. label 可以灵活描述 node 的属性,其形式是 ke

管理和安装 chart - 每天5分钟玩转 Docker 容器技术(168)

安装 chart 当我们觉得准备就绪,就可以安装 chart,Helm 支持四种安装方法: 安装仓库中的 chart,例如:helm install stable/nginx 通过 tar 包安装,例如:helm install ./nginx-1.2.3.tgz 通过 chart 本地目录安装,例如:helm install ./nginx 通过 URL 安装,例如:helm install https://example.com/charts/nginx-1.2.3.tgz 这里我们使用本地

如何安装和配置 Rex-Ray?- 每天5分钟玩转 Docker 容器技术(74)

Rex-Ray 是一个优秀的 Docker volume driver,本节将演示其安装和配置方法. Rex-Ray 以 standalone 进程的方式运行在 Docker 主机上,安装方法很简单,在需要使用 Rex-Ray driver 的主机 docker1 和 docker2 上运行如下命令: curl -sSL https://dl.bintray.com/emccode/rexray/install | sh - 然后创建并编辑 Rex-Ray 的配置文件 /etc/rexray/c