我是K8的新手，接触过多种部署策略。我发现关于金丝雀部署战略的理论有点不清楚。
我知道，在Canary策略中，整个目标是首先在当前pod实例的子集上测试新版本，然后，如果成功，升级其余实例。
当测试成功时，我对剩余实例的升级表示怀疑：
- 升级是否遵循重新创建类型的机制，即杀死所有pod并创建新pod，从而导致停机？(或(
- 它是否遵循滚动更新机制，将剩余的pod逐一更新，从而避免任何停机时间？(或(
- 它是不是像蓝色/绿色一样，我们已经有了一套更新版本的pod，我们只是交换，因此需要额外的资源？(或(
- 根据规范，它可以遵循这些机制中的任何一种
除了p Ekambaram的评论：
升级是否遵循重新创建类型的机制，即杀死所有pod并创建新pod，从而导致停机？
不正常。这取决于你选择如何设置你的金丝雀释放。如果你有10个pod，并且你想在20%的流量上进行测试，你会添加新版本的两个新pod，并终止其中两个旧pod，确保新pod与旧pod具有相同的标签，以确保它获得流量。通常情况下，这将作为第二次部署或类似Spinnaker的东西来完成，它可以管理上升/下降。
它是否遵循滚动更新机制，即对剩余的pod进行逐一更新，从而避免任何停机时间？
同样，这取决于情况。但通常情况下，是的，你会增加部署中新版本pod的数量，减少旧版本pod的数目，同时关注某个指标(例如，如果部署是例如web服务，则5xx错误的数量(。根据业务和服务的不同；用新版本检查20%的流量，如果一切都好，一次性完成剩余的80%；
是不是像蓝色/绿色一样，我们已经有了一组更新版本的pod，我们只是交换，因此需要额外的资源？
Blue/Green通常有一整套新版本的pod，并将DNS作为"新版本"翻转到新版本；"大爆炸"；转换
您可以使用加权DNS进行Canary部署，但由于无法控制不同的DNS缓存层，这是不可靠的。
根据规范，它可以遵循这些机制中的任何一种。
是的，完全由您(和/或产品/服务所有者(决定他们希望如何部署应用程序。
在canary部署策略中，新版本的应用程序逐渐部署到Kubernetes集群，同时获得非常少量的实时流量。一部分实时用户正在连接到新版本，而其余用户仍在使用以前的版本。
新版本的实时流量的一小部分可以作为新代码中可能存在的潜在问题的早期警告。随着我们信心的增强，金丝雀流量逐渐增加，越来越多的用户现在连接到更新版本。最终，所有的直播流量都流向了金丝雀，因此金丝雀版本成为了新的"生产版本">
使用canary策略的最大优点是，部署问题可以很早发现，而它们仍然只影响所有应用程序用户的一小部分。如果金丝雀出了问题，生产版本仍然存在，所有流量都可以简单地恢复到它
Canary版本基于以下假设：
- 应用程序的多个版本可以同时存在时间，获得实时流量
- 如果你不使用某种粘性会话机制，一些客户可能会在一个请求和另一个请求中的金丝雀服务器
如果您想进行canary部署，请考虑Istio。以下链接会有所帮助https://istio.io/latest/blog/2017/0.1-canary/