阿里巴巴云原生应用安全防护实践与 OpenKruise 的新领域

Posted 2021-04-02 阿里巴巴云原生

作者 | 王思宇(酒祝)

 

得益于 Kubernetes 面向终态的理念，云原生架构天然具备高度自动化的能力。然而，面向终态的自动化是一把“双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。

因此，充分了解云原生环境下那些潜在的影响应用安全的问题，提前掌握多方位的安全防护、拦截、限流、熔断等技术手段来保障云原生应用的运行时稳定性至关重要。

本文整理自作者阿里云容器服务技术专家，OpenKruise 作者 & 初创人员之一，Kubernetes、OAM 社区贡献者王思宇（酒祝）于 1 月 19 日在阿里云开发者社区“周二开源日”的直播分享，介绍了云原生环境下应用安全与可用性的“处处危机”，分享阿里巴巴保障云原生应用运行时稳定性经验，并且详细解读了后续这些能力将如何通过 OpenKruise 赋能给开源。

<文末点击阅读原文，可回看完整视频>

云原生环境应用安全“危机”

1. 阿里巴巴云原生应用部署结构

这里的云原生应用部署结构是在阿里巴巴原生环境最简化的抽象图，如下图所示。

首先我们来看几个 CRD。CloneSet CRD 可以理解成 deployment 的一个 workload，也就是给应用部署 Pod 的模板。有了 CloneSet CRD 之后，不同的业务以及不同的应用会建立对应的 CloneSet，在 CloneSet 下面再建立对应的 Pod，以及对 Pod 做一些部署、发布相关的管理。

除了 CloneSet 之外，还提供了 SidecarSet CRD，这个 CRD 做的事情是在业务 Pod 创建阶段注入 SidecarSetCRD 中定义的 Sidecar 容器。也就是说，在 CloneSet 中业务只需要定义 Pod 中的 app 容器，也就是业务容器。在 Pod 创建过程中，通过 SidecarSet 在其中定义业务中要注入哪些 sidecar 容器。

2. OpenKruise：阿里巴巴应用部署基座

开源的 OpenKruise 是阿里巴巴应用部署的基座。OpenKruise 提供了多种的 workload。其中包括：CloneSet、Advanced StatefulSet、SidecarSet、Advanced DaemonSet。

• CloneSet：是面向无状态应用部署的工具，也是阿里巴巴中使用规模最大的部分，绝大部分泛电商业务都是通过 CloneSet 来部署发布，包括 UC 神马、饿了么、电商业务等。

• Advanced StatefulSet：针对一个原生 StatefulSet 兼容的增强版本，是面向有状态应用部署的工具，目前主要是用于中间件在云原生环境的部署。

• SidecarSet：是在阿里巴巴环境中 sidecar 生命周期管理的工具。阿里巴巴的运维容器，以及阿里内部的 Mesh 容器，都是通过 SidecarSet 定义、部署以及注入到业务 Pod 中的。

• Advanced DaemonSet：是针对原生 DaemonSet 兼容增强版本。将宿主机级别的守护进程部署到所有节点上，包括各种用于给业务容器配置网络、存储的基础组件。

介绍完基础环境之后，我们已经对云原生部署结构有了一个基本的了解。下面，我们来了解在云原生部署结构之下存在哪些云原生应用安全危机。

3. 云原生应用安全危机

1）workload 级联删除

Workload 级联删除，这一点不只针对于 Kruise 的 CloneSet，对于 Deployment，对于原生的 StatefulSet 都存在类似的问题。指的是当我们删除一个 Workload 之后，假设使用采用默认删除，没有使用 orphan 删除这种策略的话，底下的 Pod 都会被删掉，这里存在一种误删风险。也就是说，一旦某个 Deployment 被误删，那么它底下的所有 Pod 都会级联被删掉，导致整个应用不可用。如果有多个 Workload 被删掉，就可能导致很多个业务出现不可用的情况，这是一个对可用性造成的风险。如下图所示：

2）namespace 级联删除

那么我们再往上看，如果 Namespace 被删掉，那么整个 Namespace 底下的所有资源，包括 Deployment、CloneSet 这些 Workload，也包括 Pod、Service 等所有资源都会被删除，这是一种很高的误删风险。

3）CRD 级联删除

如果有用 Helm 部署的同学可能会遇到过类似的情况，也就是如果你的 Helm 中包含了一些 CRD，这些 CRD 都被定义在 template 中， 那么当 Helm uninstall 的时候，基本上这些 CRD 都会被 Helm 包级联删除掉，包括有人手动误删了某个 CRD，那么 CRD 底下对应的 CR 都会被清理。这是一个很高的风险。

如果 CRD 是 CloneSet 这种 Workload 级别的 CRD，那么一旦删除这个 CRD 之后，会导致所有 CRD 底下的 CloneSet 的 CR 对象全部被删掉，从而导致所有的业务 Pod 全部被删掉。也就是说，删除一个 Workload，只是这个 Workload 底下的 Pod 被删掉；删除一个 Namespace 可能只是 Namespace 底下的 Pod 被删掉。但如果像阿里巴巴这种场景下，如果有人把 CloneSet 或者一些很关键的 CRD 删掉的话 ，其实很可能导致整个集群环境所有 NameSpace 底下的 Pod 都会被级联删掉，或者说都会处于应用不可用的状态，造成云原生环境对于应用可用性的风险。如下图所示：

从上文可以看出来，云原生这种理念架构为我们带来的好处是面向终态，也就是说我们定义终态，从而整个 Kubernetes 集群就会向终态靠拢。而一旦出现一些误操作导致定义了一种错误的终态，那么 Kubernetes 也会向错误的终态靠拢，导致出现错误的结果，从而影响到整个应用的可用性。因此我们说，面向终态是一把“双刃剑”。

 

4）并发 Pod 更新/驱逐/删除

除了几种误删的情况，还有更多针对可用性的风险。如下图所示，假设左边 CloneSetA 部署了两个 Pod，这两个 Pod 中又被 SidecarSet 注入了对应的 sidecar 容器。在这种情况下，如果通过 CloneSet 做应用发布，假设说我们设置的 Max Available 是 50%，也就是说，两个 Pod 是逐个升级，前一个升级完成，后一个才能开始升级，默认情况下这种发布策略是没有问题的。

但是如果 Pod 有多个 Owner，比如 CloneSet 是其中一个 Owner，CloneSet 对上面的 Pod 开始做原地升级，SidecarSet 对第二个 Pod 做 sidecar 的原地升级，那么同一时刻可能这个应用的两个 Pod 都在被升级。因为在 CloneSet 定义了 Max Unavailable 是 50%，从它的视角来看，只要选取两个 Pod 中的一个开始做升级。CloneSet 本身是无法感知到其它控制器甚至其他人为的行为去对其它 Pod 做操作，缺乏全局视角，每一个控制器都认为自己在升级的 Pod 是符合升级策略，符合最大不可用测略。但当多个控制器同时开始工作的时候，可能会导致整个应用 100% 不可用。

如上图右边的情况，CloneSetC 底下有 3 个 Pod，如果它开始做升级的时候只升级其中一个 Pod，假设是重建升级，它会把旧版本 Pod 删掉，先建新版本 Pod。在这过程中，假设另外两个 Pod 一个可能被 Kubelet，或者 kube-controller-manager 中的 node lifecycle controller 驱逐，这时候已经有两个 Pod 不可用，已经超过 Workload 中定义的最大不可用发布策略。在这个过程中，还可能有一些 Pod 被其他一些控制器其他有人工手动删除。种种可能性导致一个 Workload 下 Pod 的不可用数量，很可能是超过本身 workload 中定义的不可用发布策略的。

也就是说，在 Deployment 中定义了 Max Unavailable 是 25%，那么 Deployment 在发布的时候，从它自身角度来看保证 25% 的 Pod 在被发布。其他 75% 的 Pod 并不保证完全可用，这 75% 的 Pod 可能被 Kubelet 驱逐、可能被人为手动删除、可能被 SidecarSet 外部热升级等等，种种情况可能会导致 Deployment 超过 50% 不可用，甚至更高，使整个应用受到影响。

云原生应用安全防护实践

针对以上种种危机，我们能采取怎么样的措施，保证原生环境下应用安全的可用性、安全性。下面介绍一些实践的经验。

1. 防护实践 - 防级联删除

由于级联删除对应用可用性危害非常大，包括了删除 CRD 节点，删除 Namespace 节点，以及删除 Workload 节点。防级联删除定义了针对多种资源，包括 CRD、Namespace、包括原生 Deployment 在内的各种 Workload 等，对这些资源提供了针对的 labels 定义。

下面是针对各种重要节点防级联删除的语名：

apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: labels: policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: v1kind: Namespacemetadata: labels: policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: apps/v1kind: Deploymentmetadata: labels: policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: apps.kruise.io/v1alpha1kind: CloneSetmetadata: labels: policy.kruise.io/disable-cascading-deletion: true

labels 定义是关闭级联删除，用户的任何 CRD、Namespace、workload 里带有防级联删除标识之后，kruise 就会保证资源防级联删除校验。也就是说，当用户删除一个 CRD 时，如果这个 CRD 里带有防级联删除这个 label，那么 kruise 就会去查看 CRD 底下是否还有存量 CR，如果有存量 CR 那么 kruise 会禁止 CRD 删除。

同理，在 Namespace 删除时，也会校验 Namespace 底下是否还有存量的运行状态的 Pod，如果有，会禁止用户直接删除 Namespace。

对于 workload 逻辑相对简单，就对于 Deployment、CloneSet、SidecarSet，当用户去删除 workload 时，如果 workload 中用户已经定义了防级联删除的 label，那么 kruise 会检查 workload 的 replica 是否为 0，如果 replica 大于 0，那么 kruise 是禁止用户直接删除带有防级联删除标识的 workload。也就是说，当一个存量 Deployment，如果 replicas 大于 0 的情况下，如果 Deployment 中存在带有防级联删除标识，kruise 禁止用户直接删除。

如果真的需要删除 Deployment 有两种办法：

• 第一，先把 replica 调为 “0”，这时底下 Pod 开始被删除，这时删除 Deployment 是没问题的。

 

• 第二，可以把 Deployment 中防级联删除标识去掉。

以上是关于防级联删除的介绍，大家应该将防级联删除理解成安全防护最基础的一个策略，因为级联删除是 Kubernetes 中非常危险的一个面向终态的能力。

2. 防护实践 – Pod 删除流控 & 熔断

针对 Pod 删除流控 & 熔断的策略，指的是用户调用、或用控制器用 K8s 去做 Pod 驱逐时，一旦出现误操作或者出现逻辑异常，很可能导致在整个 K8s 集群范围内出现 Pod 大规模删除的情况。针对这种情况做了 Pod 删除留空策略，或者说是一个 CRD。这个 CRD 用户可以定义在一个集群中，不同的时间窗口内，最多有多少 Pod 允许被删除。

apiVersion: policy.kruise.io/v1alpha1kind: PodDeletionFlowControlmetadata: # ...spec: limitRules: - interval: 10m limit: 100 - interval: 1h limit: 500 - interval: 24h limit: 5000 whiteListSelector: matchExpressions: - key: xxx operator: In value: foo

如上面这个例子，10 分钟之内最多允许 100 个 Pod 被删除，1 小时之内最多允许 500 个 Pod 被删除，24 小时内最多允许 5000 个 Pod 被删除。当然也可以定义一些白名单，比如有些测试应用，每天频繁地巡检、测试，频繁删除会影响整个流控，可以提供一个白名单，符合白名单的应用不计算在窗口内。

除了白名单之外，可能 90% 的常规应用或者核心应用，是受到删除流控保护的。一旦存在规模性误删除操作，就会被删除流控以及熔断机制保护。包括在保护之后或者触发阈值之后，最好提供这种报警机制、监控机制，让集群的管理者能快速的感知到线上出现的熔断事件。还包括帮助管理者去判断熔断事件是一个正常的事件，还是一个异常的事件。

如果在这段时间内，需要存在很多删除请求，可以把对应策略值相应放大。如果真的是一些误删除，拦截到之后，及时根据请求来源做溯源，及时在搜索层面做熔断，拒绝这些请求。

3. 防护实践 - 应用维度不可用数量保护

对应用维度不可用数量保护，对于 K8s 原生，原生的 Kubernetes 提供了 PDB(PodDisruptionBudge) 策略，但是 PDB 只能拦截 Pod eviction 驱逐操作，也就是 Pod 驱逐操作。

apiVersion: policy/v1beta1kind: PodDisruptionBudgetmetadata: name: xxxspec: minAvailable: 2 selector: matchLabels: app: xxx

上面的这个例子，假设其中有 5 个 Pod，这时定义了 minAvailable=2，就保证最少有 2 个 Pod 处于可用。一旦有 3 个 Pod 不可用，还剩下 2 个 Pod 可用，这时候如果 Pod eviction 针对存量 2 个 Pod 做驱逐，这个时候 PDB 会保护 Pod 可用性，拒绝这次驱逐操作。但是相应的如果对存量 2 个 Pod 做删除或者原地升级，或者去做其他导致 Pod 不可用的事情，PDB 是没有办法拦截，尤其是针对 Pod 删除请求，比 Pod 驱逐更为常见，但是 PDB 是没办法拦截删除等请求。

对于这些问题，阿里巴巴做了 PodUnavailableBudget 拦截操作，也就是 PUB。这里的 Unavailable 能做的操作就更多了，基本上所有可能导致 Pod 不可用的操作，都在 PodUnavailableBudget 保护范围内，包括了驱逐请求、Pod 删除请求，应用原地升级、Sidecar 原地升级、容器重启等，所有导致应用不可用的操作都会被 PUB 拦截。

如下面这个例子：

apiVersion: policy.kruise.io/v1alpha1kind: PodUnavailableBudgetspec: #selector: # app: xxx targetRef: apiVersion: apps.kruise.io kind: CloneSet name: app-xxx maxUnavailable: 25% # minAvailable: 15status: deletedPods: pod-uid-xxx: "116894821" unavailablePods: pod-name-xxx: "116893007" unavailableAllowed: 2 currentAvailable: 17 desiredAvailable: 15 totalReplicas: 20

定义了一个 PUB，这个 PUB 可以像原生 PDB 一样写一个 selector 范围，也可以通过 targetRef 直接关联到某一个 Workload，保护范围就是在 Workload 底下的所有 Pod，同样也可以定义最大不可用数量，以及最小可用数量。

假设对于 CloneSet 底下总共 20 个 Pod，当定义了 maxUnavailable：25% 时，一定要保证至少有 15 个 Pod 处于可用状态。也就是说，PUB 会保证这 20 个 Pod 中最多有 5 个处于不可用状态。回到我们之前在“危机”部分讲到的一个例子，如果这 20 个 Pod 同时在被 Cloneset 发布，以及被 Kubelet 驱逐，或是人工手动删除，一旦 Pod 不可用数量超过 5 个，不管是 Kubelet 对剩余 15 个 Pod 做驱逐，还是人为手动删除剩余的某些 Pod，这些操作都会被 PUB 所拦截，这种策略能完全保证应用在部署过程中的可用性。PUB 可以保护的范围比 PDB 大很多，包括在实际使用过程中预期之外的一些删除请求、升级请求，从而保证整个应用在运行时的稳定性和可用性。

4. 防护实践 - PUB/PDB 自动生成

对于真正的 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 的认知。 是阿里云开源的 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与原生能力对比

橙色：开源中  /  绿色：已开源

那么，对于这场景而言，Kruise 已经做了比较完备的一个无状态以及有状态应用的部署，通过上图表格能看到 Kruise 提供的 workload 和原生 deployment、StatefulSet、DaemonSet 的对比。

4. OpenKruise 2021 规划

如上图所示，OpenKruise 是一个云原生应用自动化引擎，目前提供的 workload 能力在应用部署，但不会仅局限于应用部署这一个领域的。

1）风险防控

在 2021 年上半年的规划中，我们会针对上面讲到的云原生应用的风险和防控的策略，会通过 OpenKruise 输出给社区。包括 CRD 删除防护、级联删除防护、全局 Pod 删除流控、Pod 删除/驱逐/原地升级防护、自动为 workload 生成 PDB/PUB 等。

2）Kruise-daemo

除此之外之前 OpenKruise 只是作为一个中心的控制器部署，下个版本中会提供一个 Kruise-daemon 通过 daemon set 部署到每个节点上，可以帮用户去做一些镜像预热，发布加速，容器重启 ，单机调度优化的一些策略。

3）ControllerMesh

ControllerMesh 是 OpenKruise 提供出来帮助用户管理用户集群中其他运行时的一些控制器运行时的能力，通过流量控制等方式解决传统控制器单住模式带来的种种问题。

 

最后，在 OpenKruise 项目社区建设方面，已经在 2020 年 11 月 11 号经 CNCF 技术监督委员会全体成员投票，一致同意正式进入 CNCF Sanbox，在整个过程中也得到了 CNCF 积极的回应，表示 OpenKruise 项目与 CNCF 倡导的理念很契合，鼓励有更多像 OpenKruise 这样能做一些通用化的，面向更复杂的场景，更大规模的一些这种自主的 Workload 能力的项目出现。

现在已经有很多公司在使用 OpenKruise 的这些能力，比如：

• 基于原地升级、灰度发布等需求，携程在生产环境使用CloneSet、AdvancedStatefulSet 来分别管理无状态、有状态应用的服务，单集群 Kruise workload 数量达到万级别。

 

• OPPO 公司不仅大规模使用了 OpenKruise，还在下游配合其定制化的 Kubernetes 进一步加强了原地升级的能力，广泛应用在多个业务的后端运行服务中，通过原地更新覆盖了 87% 左右的升级部署需求。

 

• 此外，国内的用户还有苏宁、斗鱼 TV、有赞、比心、Boss 直聘、申通、小红书、VIPKID、掌门教育、杭银消费、万翼 科技、多点 Dmall、佐疆科技、享住智慧、艾佳生活、永辉科技中心、跟谁学，国外的用户有 Lyft、Bringg、 Arkane Systems 等。

• Maintainer 5 位成员来自阿里巴巴、腾讯、Lyft

 

• 51 位贡献者

• 国内：阿里云、蚂蚁集团、携程、腾讯、拼多多...

• 国外：微软、Lyft、Spectro Cloud、Dsicord...

• 2000+ GitHub Stars

 

• 300+ Forks

如果大家对 OpenKruise 项目感兴趣，有任何希望交流的话题，欢迎大家访问 、 ，以及加入钉钉交流群：

“Kubernetes 与云原生应用开源实践大讲堂”

4 场云原生与 Kubernetes 技术前沿话题直播、70 节经典课程、3 本云原生电子书，来“Kubernetes 与云原生应用开源实践大讲堂”，和阿里云容器技术专家一起，将热门的容器开源项目和前沿的云原生应用落地实践一网打尽！

<点击阅读原文，可回看完整视频>