引言
rancher cattle 提供两种升级服务（upgrading service）的方式，in-service upgrade 和 rolling upgrade，后者流程繁琐，根本不适合持续部署，这里只讨论前者。
所使用的 rancher 版本是 1.4.1。
存在的问题
无法实现 zero downtime upgrading
对于生产环境来说，升级时保证 100% 的可用性是非常重要的，但是 rancher 目前的实现存在诸多缺陷：
不支持配置 stop_grace_period ，见 support for stop_grace_period rancher/rancher#7715
使用 start_first: true 时，新 container 不等进入 healthy 状态就会被添加到 haproxy 的 backend 配置中（其实不是问题，见下面的更正），而老的 container 会被立即从 backend 中移除，如果不配合 --batch-size，必然导致青黄不接。
使用 start_first: false 时，老的 container 直到完全停止（自动退出或超过 10s 被强杀）后才会被从 haproxy 的 backend 配置中移除，新的 container 不等进入 healthy 状态就会被添加到 backend 配置中（其实不是问题，见下面的更正）。
新的 container 等进入 healthy 状态才会添加到 DNS 记录中，这个是对的，但是老的 container 直到完全停止（自动退出或超过 10s 被强杀）后才会被从 DNS 记录中移除。
DNS 响应 TTL 默认 600 秒，导致使用 DNS 作为服务发现机制时，比如 nginx + php-fpm，IP 地址不能及时更新，虽然有解决办法 ，但不够通用。
测试方式请参考：https://github.com/inetfuture/playground/tree/master/rancher/clock
理想的实现应该是这样的：
支持 container 级别的平滑关闭超时设置。
新启动的 container 只有等进入 healthy 状态才会被添加到 haproxy 的 dns 中。
要停止一个 container 时，停止之前就应该把它从 haproxy 和 dns 中移除。
默认 DNS TTL 应该很小。
更正 ：
不等新 container 进入 healthy 状态就把它放入 haproxy 配置其实是可以的，因为 haproxy 自己会做健康检查，没有达到健康标准前不会给它分发请求。
容易出现状态不一致或者卡住
测试过程中多次遇到以下情况：
container 状态没有被 metadata 服务正确追踪，比如在某个 host 上存在两个同名（rancher 内的名字，形如 stack-service-1）的 container，metadata 里只能查询到其中一个。
stoppend container 没有被正确清理掉，如下图：
报错： Finishing-Upgrade (State [purged] is not valid for process，只能 Cancel 或者删掉重新创建
备注
rancher 内 service、container 等状态更新流程：
rancher events -> metadata -> haproxy, dns 其中，rancher events 到 metadata 通过 websocket 连接，是实时的；metadata 到 haproxy 和 DNS 的更新机制都是长轮询 metadata 版本号（http://169.254.169.250/2015-12-19/version?wait=true&maxWait=5&value={oldValue}） ，5 秒超时，发现有新版本时再去查询需要的信息，接近于实时。
参考 https://merrychris.com/2017/03/06/rancher-dns
总结
rancher 在保障服务高可用这方面还不很成熟，使用在生产环境需谨慎。
引言
rancher cattle 提供两种升级服务（upgrading service）的方式，in-service upgrade 和 rolling upgrade，后者流程繁琐，根本不适合持续部署，这里只讨论前者。
所使用的 rancher 版本是 1.4.1。
存在的问题
无法实现 zero downtime upgrading
对于生产环境来说，升级时保证 100% 的可用性是非常重要的，但是 rancher 目前的实现存在诸多缺陷：
start_first: true时，新 container 不等进入 healthy 状态就会被添加到 haproxy 的 backend 配置中（其实不是问题，见下面的更正），而老的 container 会被立即从 backend 中移除，如果不配合--batch-size，必然导致青黄不接。start_first: false时，老的 container 直到完全停止（自动退出或超过 10s 被强杀）后才会被从 haproxy 的 backend 配置中移除，新的 container 不等进入 healthy 状态就会被添加到 backend 配置中（其实不是问题，见下面的更正）。测试方式请参考：https://github.com/inetfuture/playground/tree/master/rancher/clock
理想的实现应该是这样的：
更正：
不等新 container 进入 healthy 状态就把它放入 haproxy 配置其实是可以的，因为 haproxy 自己会做健康检查，没有达到健康标准前不会给它分发请求。
容易出现状态不一致或者卡住
测试过程中多次遇到以下情况：
container 状态没有被 metadata 服务正确追踪，比如在某个 host 上存在两个同名（rancher 内的名字，形如 stack-service-1）的 container，metadata 里只能查询到其中一个。
stoppend container 没有被正确清理掉，如下图：
报错：
Finishing-Upgrade (State [purged] is not valid for process，只能 Cancel 或者删掉重新创建备注
rancher 内 service、container 等状态更新流程：
其中，rancher events 到 metadata 通过 websocket 连接，是实时的；metadata 到 haproxy 和 DNS 的更新机制都是长轮询 metadata 版本号（http://169.254.169.250/2015-12-19/version?wait=true&maxWait=5&value={oldValue}） ，5 秒超时，发现有新版本时再去查询需要的信息，接近于实时。
参考 https://merrychris.com/2017/03/06/rancher-dns
总结
rancher 在保障服务高可用这方面还不很成熟，使用在生产环境需谨慎。