Module 03 · Managing Applications with Kubernetes
Deployment Strategies部署策略
Overview 概述
A Kubernetes deployment strategy defines an application’s lifecycle that achieves and maintains the configured state for objects and applications in an automated manner. Effective deployment strategies minimize risk.
Kubernetes 部署策略定义了应用程序的生命周期，以自动化方式实现并维护对象和应用程序的配置状态。有效的部署策略可以最小化风险。
Kubernetes deployment strategies are used to:
Kubernetes 部署策略用于：
- Deploy, update, or rollback ReplicaSets, Pods, Services, and Applications
部署、更新或回滚 ReplicaSets、Pods、Services 和应用程序 - Pause/Resume Deployments
暂停/恢复部署 - Scale Deployments manually or automatically
手动或自动扩展部署
Types of deployment strategies 部署策略类型
The following are six types of deployment strategies:
以下是六种部署策略：
- Recreate 重建
- Rolling 滚动
- Blue/green 蓝绿部署
- Canary 金丝雀发布
- A/B testing A/B 测试
- Shadow 影子
You can use either a single deployment strategy or a combination of multiple deployment strategies.
您可以使用单一部署策略，也可以使用多种部署策略的组合。
Recreate strategy 重建策略
In the recreate strategy, Pods running the live version of the application are all shut down simultaneously, and a new version of the application is deployed on newly created Pods.
在重建策略中，运行应用程序活动版本的 Pod 将同时关闭，并在新创建的 Pod 上部署应用程序的新版本。
Recreate is the simplest deployment strategy. There is a short downtime between the shutdown of the existing deployment and the new deployment.
重建是最简单的部署策略。在现有部署关闭和新的部署之间有一个短暂的停机时间。
Recreate strategy steps include:
重建策略的步骤包括：
- A new version of the application (v2) is ready for deployment.
一个新版本的应用程序（v2）已准备好进行部署。 - All Pods running the current version (v1) are shut down or deleted.
正在运行当前版本（v1）的所有 Pod 都被关闭或删除。 - New (v2) Pods are created.
新版本（v2）的 Pod 被创建。
The rollback process is completed in the reverse order, replacing version 2 (v2) with version 1 (v1).
回滚过程以相反的顺序完成，用版本 1（v1）替换版本 2（v2）。
| Pros 优点 | Cons 缺点 |
|---|---|
| Simple setup 简洁的设置 | Short downtime occurs between shutdown and new deployment 关闭和新部署之间有短暂的停机时间 |
| Application version completely replaced 应用程序版本完全替换 |
Rolling (ramped) strategy 滚动（渐变）策略
In a rolling strategy, each Pod is updated one at a time. A single v1 Pod is replaced with a new v2 Pod. Each v1 Pod is updated in this way until all Pods are v2. During a rolling strategy update, there is hardly any downtime since users are directed to either version.
在滚动更新策略中，每个 Pod 会逐一更新。一个 v1 Pod 被替换为一个新的 v2 Pod。每个 v1 Pod 都以这种方式更新，直到所有 Pod 都变为 v2。在滚动更新过程中，由于用户会被引导至任一版本，因此几乎不会出现停机。
Rolling strategy steps include:
滚动更新策略的步骤包括：
- A new version of the application (v2) is ready for deployment.
应用程序的新版本（v2）已准备好进行部署。 - One of the Pods running the current version (v1) is shut down or deleted.
正在运行当前版本（v1）的其中一个 Pod 被关闭或删除。 - A new (v2) Pod is created to replace the (v1) Pod that was removed.
一个新的（v2）Pod 被创建以替换被移除的（v1）Pod。 - Steps 2 and 3 are repeated until all (v1) Pods are removed and replaced with (v2) Pods.
步骤 2 和 3 将重复执行，直到所有（v1）Pod 都被移除并用（v2）Pod 替换。
The rollback process is reversed, where v2 Pods are replaced by v1 Pods.
回滚过程被逆转，其中 v2 Pod 被 v1 Pod 替换。
| Pros 优点 | Cons 缺点 |
|---|---|
| Simple setup 设置简单 | Rollout/rollback takes time 发布/回滚需要时间 |
| Suitable for stateful applications that need to handle rebalancing of the data 适用于需要处理数据再平衡的有状态应用程序 |
You cannot control traffic distribution 无法控制流量分配 |
Blue/green strategy 蓝绿部署策略
In a blue/green strategy, the blue environment is the live version of the application. The green environment is an exact copy that contains the deployment of the new version of the application. The green environment is thoroughly tested. Once all changes, bugs, and issues are addressed, user traffic is switched from the blue environment to the green environment.
在蓝绿部署策略中，蓝环境是应用程序的运行版本。绿环境是包含新版本应用程序部署的精确副本。绿环境会经过彻底测试。一旦所有变更、错误和问题都得到解决，用户流量就会从蓝环境切换到绿环境。
Blue/green strategy steps include:
蓝绿部署策略的步骤包括：
- Create a new environment identical to the current production environment.
创建一个与当前生产环境完全相同的新环境。 - Design the new version and test it thoroughly until it is ready for production.
设计新版本并彻底测试，直到它准备好投入生产。 - Route all user traffic to the new version.
将所有用户流量路由到新版本。
To perform a rollback, switch the environments back.
要执行回滚，请将环境切换回原状态。
| Pros 优点 | Cons 缺点 |
|---|---|
| Instant rollout/rollback (no downtime) 即时部署/回滚 （无停机时间） |
Expensive (requires double resources) 昂贵 （需要双倍资源） |
| New version is available immediately to all users 新版本立即对所有用户开放 |
Rigorous testing required before releasing to production 在生产环境中发布前需要进行严格测试 |
| Handling stateful applications is difficult 处理有状态的应用程序很困难 |
Canary strategy 金丝雀策略
In a canary strategy, the new version of the application is tested using a small set of random users alongside the current live version of the application. Once the new version of the application is successfully tested, it is then rolled out to all users.
在金丝雀策略中，新版本的应用程序是与当前运行中的应用程序一起使用一小部分随机用户进行测试的。一旦新版本的应用程序成功测试，它就会被推出到所有用户。
Canary strategy steps include:
金丝雀策略的步骤包括：
- Design a new version of the application.
设计应用程序的新版本。 - Route a small sample of user requests to the new version.
将一小部分用户请求路由到新版本。 - Test for efficiency, performance, bugs, and issues, and rollback as needed.
测试效率、性能、错误和问题，并根据需要回滚。 - Repeat steps 1 to 3. Once all issues are resolved, route all traffic to the new version.
重复步骤 1 至 3。一旦所有问题都得到解决，将所有流量路由到新版本。
Rollback has no downtime since few users are exposed to the new version.
回滚不会造成停机，因为只有少数用户接触到新版本。
| Pros 优点 | Cons 缺点 |
|---|---|
| Convenient for reliability, error, and performance monitoring 便于进行可靠性、错误和性能监控 |
Slow rollout, gradual user access 缓慢推广，逐步开放用户访问 |
| Fast rollback 快速回滚 |
A/B testing strategy A/B 测试策略
The A/B testing strategy, also known as split testing, evaluates two versions of an application (version A and version B). With A/B testing, each version has features that cater to different sets of users. You can select which version is best for global deployment based on user interaction and feedback.
A/B 测试策略，也称为分割测试，评估应用程序的两个版本（版本 A 和版本 B）。通过 A/B 测试，每个版本都针对不同的用户群体具有不同的功能。您可以根据用户交互和反馈选择哪个版本最适合全球部署。
A/B testing strategy steps include:
A/B 测试策略步骤包括：
- Design a new version of the application by adding mostly UI features.
设计应用程序的新版本，主要添加 UI 功能。 - Identify a small set of users based on conditions like weight, cookie value, query parameters, geolocalization, browser version, screen size, operating system, and language.
根据体重、cookie 值、查询参数、地理位置、浏览器版本、屏幕尺寸、操作系统和语言等条件，识别一小部分用户。 - Route requests from the user set to the new version.
将用户集的请求路由到新版本。 - Check for bugs, efficiency, performance, and issues.
检查错误、效率、性能和问题。 - Once all issues are resolved, route all traffic to the new version.
一旦所有问题都得到解决，将所有流量路由到新版本。
Rollbacks can be implemented, but downtime can impact the user.
可以实施回滚，但停机时间会影响用户。
| Pros 优点 | Cons 缺点 |
|---|---|
| Multiple versions can run in parallel 可并行运行多个版本 |
Requires intelligent load balancer 需要智能负载均衡器 |
| Full control over traffic distribution 对流量分配具有完全控制权 |
Difficult to troubleshoot errors for a given session, distributed tracing becomes mandatory 为给定会话调试错误很困难，分布式追踪变得强制要求 |
Shadow strategy 影子策略
In a shadow strategy, a “shadow version” of the application is deployed alongside the live version. User requests are sent to both versions, and both handle all requests, but the shadow version does not forward responses back to the users. This lets developers see how the shadow version performs using real-world data without interrupting user experience.
在影子策略中，除了实时版本外，还会部署应用程序的“影子版本”。用户请求被发送到两个版本，两个版本都处理所有请求，但影子版本不会将响应转发回用户。这允许开发人员使用真实世界数据查看影子版本的性能，而不会中断用户体验。
To perform a rollback, switch the environments back.
要执行回滚，请将环境切换回原状态。
| Pros 优点 | Cons 缺点 |
|---|---|
| Performance testing with production traffic 使用生产流量进行性能测试 |
Expensive (double resources) 昂贵（需要双倍资源） |
| No user impact 无用户影响 | Not a true user test, can lead to misinterpreted results 非真正的用户测试，可能导致结果被误解 |
| No downtime 无停机时间 | Complex setup 复杂设置 |
| Requires monitoring for two environments 需要监控两个环境 |
Deployment strategies summary 部署策略总结
| Strategy 策略 | Zero Downtime 零停机时间 | Real Traffic Testing 真实流量测试 | Targeted Users 目标用户 | Cloud Cost 云成本 | Rollback Duration 回滚持续时间 | Negative User Impact 负面影响 | Complexity of Setup 设置复杂性 |
|---|---|---|---|---|---|---|---|
| Recreate 重新创建 Version 1 is removed then version 2 is rolled out 版本 1 被移除，然后版本 2 被推出 |
X | X | X | •-- | ••• | ••• | - - - |
| Ramped 逐步增加 Version 1 is replaced by a slow rollout of version 2 版本 1 被版本 2 的缓慢推出所取代 |
✓ | X | X | •-- |
••• |
•-- |
•-- |
| Blue/Green 蓝绿部署 Version 2 is released together with version 1, then the traffic is switched to version 2 版本 2 与版本 1 一同发布，然后流量切换到版本 2 |
✓ | X | X | ••• |
- - - |
••- |
••- |
| Canary 金丝雀 Version 2 is first released to a subset of users, then fully rolled out when production ready 版本 2 首先向部分用户发布，然后在生产就绪时全面推出 |
✓ | ✓ | X | •-- |
•-- |
•-- |
••- |
| A/B Testing A/B 测试 Version 2 is only released to a subset of users with specific traits 版本 2 仅向具有特定特征的子集用户发布 |
✓ | ✓ | ✓ | •-- |
•-- |
•-- |
••• |
| Shadow 影子 Version 2 receives real-world traffic together with version A but doesn’t respond to users 版本 2 与版本 A 一起接收实际流量，但不会响应用户 |
✓ | ✓ | X | ••• | - - - | - - - | ••• |
To create a good strategy:
要制定一个好的策略：
- Consider the product type and the target audience
考虑产品类型和目标受众 - Shadow and canary strategies use live user requests, as opposed to using a sample of users.
影子策略和金丝雀策略使用真实的用户请求，而不是使用用户样本。 - The A/B testing strategy is useful if the version of the application requires minor tweaks or UI feature changes.
如果应用程序版本需要微调或 UI 功能更改，则 A/B 测试策略很有用。 - The blue/green strategy is useful if your version of the application is complex or critical and needs proper monitoring with no downtime during deployment.
如果您的应用程序版本复杂或关键，并且需要在部署期间进行适当的监控且无停机时间，则蓝/绿策略很有用。 - The canary strategy is a good choice if you want zero downtime and are comfortable exposing your version of the application to the public.
如果您希望实现零停机时间，并且愿意将应用程序版本公开展示给公众，则金丝雀策略是一个不错的选择。 - A rolling strategy gradually deploys the new version of the application. There is no downtime, and it is easy to roll back.
滚动策略逐步部署应用程序的新版本。没有停机时间，并且易于回滚。 - The recreate strategy is a good choice if the application is not critical and users aren’t impacted by a short downtime.
如果应用程序不是关键的，并且用户不会受到短暂停机的影响，则重建策略是一个不错的选择。