二维码生成器哪个软件好,上海网站seo外包,营销型网站建设应该考虑哪些因素,wordpress更改ip后无主题简介#xff1a; 得益于 Kubernetes 面向终态的理念#xff0c;云原生架构天然具备高度自动化的能力。然而#xff0c;面向终态的自动化是一把“双刃剑”#xff0c;它既为应用带来了声明式的部署能力#xff0c;同时也潜在地会将一些误操作行为被终态化放大。 因此#…简介 得益于 Kubernetes 面向终态的理念云原生架构天然具备高度自动化的能力。然而面向终态的自动化是一把“双刃剑”它既为应用带来了声明式的部署能力同时也潜在地会将一些误操作行为被终态化放大。 因此充分了解云原生环境下那些潜在的影响应用安全的问题提前掌握多方位的安全防护、拦截、限流、熔断等技术手段来保障云原生应用的运行时稳定性至关重要。 得益于 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. 云原生应用安全危机
1workload 级联删除
Workload 级联删除这一点不只针对于 Kruise 的 CloneSet对于 Deployment对于原生的 StatefulSet 都存在类似的问题。指的是当我们删除一个 Workload 之后假设使用采用默认删除没有使用 orphan 删除这种策略的话底下的 Pod 都会被删掉这里存在一种误删风险。也就是说一旦某个 Deployment 被误删那么它底下的所有 Pod 都会级联被删掉导致整个应用不可用。如果有多个 Workload 被删掉就可能导致很多个业务出现不可用的情况这是一个对可用性造成的风险。如下图所示 2namespace 级联删除
那么我们再往上看如果 Namespace 被删掉那么整个 Namespace 底下的所有资源包括 Deployment、CloneSet 这些 Workload也包括 Pod、Service 等所有资源都会被删除这是一种很高的误删风险。 3CRD 级联删除
如果有用 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 是其中一个 OwnerCloneSet 对上面的 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/v1beta1
kind: CustomResourceDefinition
metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: v1
kind: Namespace
metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: apps/v1
kind: Deployment
metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata: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/v1alpha1
kind: PodDeletionFlowControl
metadata:# ...
spec:limitRules:- interval: 10mlimit: 100- interval: 1hlimit: 500- interval: 24hlimit: 5000whiteListSelector:matchExpressions:- key: xxxoperator: Invalue: foo
如上面这个例子10 分钟之内最多允许 100 个 Pod 被删除1 小时之内最多允许 500 个 Pod 被删除24 小时内最多允许 5000 个 Pod 被删除。当然也可以定义一些白名单比如有些测试应用每天频繁地巡检、测试频繁删除会影响整个流控可以提供一个白名单符合白名单的应用不计算在窗口内。
除了白名单之外可能 90% 的常规应用或者核心应用是受到删除流控保护的。一旦存在规模性误删除操作就会被删除流控以及熔断机制保护。包括在保护之后或者触发阈值之后最好提供这种报警机制、监控机制让集群的管理者能快速的感知到线上出现的熔断事件。还包括帮助管理者去判断熔断事件是一个正常的事件还是一个异常的事件。
如果在这段时间内需要存在很多删除请求可以把对应策略值相应放大。如果真的是一些误删除拦截到之后及时根据请求来源做溯源及时在搜索层面做熔断拒绝这些请求。
3. 防护实践 - 应用维度不可用数量保护
对应用维度不可用数量保护对于 K8s 原生原生的 Kubernetes 提供了 PDB(PodDisruptionBudge) 策略但是 PDB 只能拦截 Pod eviction 驱逐操作也就是 Pod 驱逐操作。 apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:name: xxx
spec:minAvailable: 2selector:matchLabels:app: xxx
上面的这个例子假设其中有 5 个 Pod这时定义了 minAvailable2就保证最少有 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/v1alpha1
kind: PodUnavailableBudget
spec:#selector:# app: xxxtargetRef:apiVersion: apps.kruise.iokind: CloneSetname: app-xxxmaxUnavailable: 25%# minAvailable: 15
status:deletedPods:pod-uid-xxx: 116894821unavailablePods:pod-name-xxx: 116893007unavailableAllowed: 2currentAvailable: 17desiredAvailable: 15totalReplicas: 20
定义了一个 PUB这个 PUB 可以像原生 PDB 一样写一个 selector 范围也可以通过 targetRef 直接关联到某一个 Workload保护范围就是在 Workload 底下的所有 Pod同样也可以定义最大不可用数量以及最小可用数量。
假设对于 CloneSet 底下总共 20 个 Pod当定义了 maxUnavailable25% 时一定要保证至少有 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: apps
kind: Deployment
metadata:name: deploy-fooannotations:policy.kruise.io/generate-pub: truepolicy.kruise.io/generate-pub-maxUnavailable: 20%# policy.kruise.io/generate-pub-minAvailable: 80%
spec:strategy:type: RollingUpdaterollingUpdate:maxUnavailable: 25%maxSurge: 25%# ...---
# auto generate:
apiVersion: policy.kruise.io/v1alpha1
kind: PodUnavailableBudget
spec:targetRef:apiVersion: appskind: Deploymentname: deploy-foomaxUnavailable: 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与原生能力对比 橙色开源中 / 绿色已开源
那么对于这场景而言Kruise 已经做了比较完备的一个无状态以及有状态应用的部署通过上图表格能看到 Kruise 提供的 workload 和原生 deployment、StatefulSet、DaemonSet 的对比。
4. OpenKruise 2021 规划 如上图所示OpenKruise 是一个云原生应用自动化引擎目前提供的 workload 能力在应用部署但不会仅局限于应用部署这一个领域的。
1风险防控
在 2021 年上半年的规划中我们会针对上面讲到的云原生应用的风险和防控的策略会通过 OpenKruise 输出给社区。包括 CRD 删除防护、级联删除防护、全局 Pod 删除流控、Pod 删除/驱逐/原地升级防护、自动为 workload 生成 PDB/PUB 等。
2Kruise-daemo
除此之外之前 OpenKruise 只是作为一个中心的控制器部署下个版本中会提供一个 Kruise-daemon 通过 daemon set 部署到每个节点上可以帮用户去做一些镜像预热发布加速容器重启 单机调度优化的一些策略。
3ControllerMesh
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 Stars300 Forks
作者 王思宇(酒祝)
原文链接
本文为阿里云原创内容未经允许不得转载
