对于真正的 Depoyment 应用开发者、运维人员来说，一般而言，只需要定义自身 workload 中 template，业务方只关心 Depoyment templatek 中业务的版本、环境变量、端口、提供的服务，但我们很难去强制每一个业务方在定义应用时，另外写一个 PUB 或者 PDB 保护策略的 CR。那么，我们怎样对每一个应用提供自动保护呢?
在阿里巴巴内部，我们针对每个 Workload 提供自动生成 PUB/PDB 的能力。比如说，如果用户此时新创建了一个 Deployment，会通过控制器自动为该 Deployment 生成一个匹配的 PUB。这个自动生成的功能即能支持原生 Deployment/StatefulSet，也支持 Kruise 的 CloneSet / Advanced StatefulSet / UnitedDeployment。第二，默认根据 strategy 中 maxUnavailable 策略。第三，允许 annotation 中单独定义保护策略。如下面的语句所示：
apiVersion: appskind: Deploymentmetadata: name: deploy-foo annotations: policy.kruise.io/generate-pub: "true" policy.kruise.io/generate-pub-maxUnavailable: "20%" # policy.kruise.io/generate-pub-minAvailable: "80%"spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% # ...---# auto generate:apiVersion: policy.kruise.io/v1alpha1kind: PodUnavailableBudgetspec: targetRef: apiVersion: apps kind: Deployment name: deploy-foo maxUnavailable: 20%自动生成的 PUB/PDB 内部填写的 maxUnavailable，既可以让用户在 kruise 中指定定义。比如用户可以直接把 kruise.io/generate-pub:"true"，也可以 kruise.io/generate-pub-maxUnavailable:"20%"，可以让用户指定应用最多允许有多少个不可用。这是用户指定的策略。
如果用户没有指定策略，会根据在发布策略中存在的maxUnavailable生成 PUB。就是指在发布的阶段，有多少个不可用数量，做为应用运行时最大不可能数量。这是允许单独定义策略。
OpenKruise 的新领域
1. OpenKruise 介绍
最后，和大家介绍上述开放的能力在 OpenKruise 新领域如何去开放，以及怎么拓展对 OpenKruise 的认知。OpenKruise 是阿里云开源的 Kubernetes 扩展应用负载项目，本质上是围绕 Kubernetes 云原生应用去做一系列自动化能力的引擎，同时也是阿里巴巴经济体上云全面使用的部署基座。
OpenKruise 的定位，做的不是一个完整的平台，更类似于是 Kubernetes 中一个拓展的产品。这个拓展的产品作为一个 add on 的组件，提供了一系列针对在 Kubernetes 中部署应用，以及后续保护防护应用可用、围绕云原生应用的一些自动化的能力，这些拓展能力或者增强能力，是原生 Kubernetes 所不具备，但也是迫切需要它所拥有这些能力，是阿里巴巴内部在云原生逐渐演进过程中去沉淀的一些通用能力。
目前，Kruise 提供了以下 workload 控制器：
CloneSet：提供了更加高效、确定可控的应用管理和部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略，可以满足更多样化的应用场景。
Advanced StatefulSet：基于原生 StatefulSet 之上的增强版本，默认行为与原生完全一致，在此之外提供了原地升级、并行发布(最大不可用)、发布暂停等功能。
SidecarSet：对 sidecar 容器做统一管理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。
UnitedDeployment：通过多个 subset workload 将应用部署到多个可用区。
BroadcastJob：配置一个 job 在集群中所有满足条件的 Node 上都跑一个 Pod 任务。
Advanced DaemonSet：基于原生 DaemonSet 之上的增强版本，默认行为与原生一致，在此之外提供了灰度分批、按 Nodelabel 选择、暂停、热升级等发布策略。
AdvancedCronJob：一个扩展的 CronJob 控制器，目前 template 模板支持配置使用 Job 或 BroadcastJob。
2. 原生 workload 能力缺陷
根据 Deployment 去 CloneSet、AdcancedStatefulSet 是因为原生 workload 能力缺陷有很多。大家可以看到，基本上从 Kubernetes 1.10 版本之后，其实其他的功能，包括 pod 里面，它的字段还是在不断丰富，包括更多的 pod 的能力支持、更多的策略等，但是对于 workload 层面，就是 deployment 和 StatefulSet 层面，已经不倾向于做任何改动。社区在这背后的考虑是因为在不同公司、不同业务场景下，应用部署发布层面需求很多。
Kubernetes 原生提供的 Deployment，是面向一些最通用最基础的一些环境，没办法用它去满足所有的业务场景，但实际上社区是非常鼓励有更高需求，更大更复杂场景规模需求的用户，自行通过 CRD 去拓展编写，利用更强大的 workload，来满足不同的业务的场景需求。
3. OpenKruise与原生能力对比
橙色：开源中 / 绿色：已开源