摘要：
云原生的应用负载从 Kubernetes 原生的 workloads（Deployment、StatefulSet）为人所熟知，但另一方面，我们也看到从中小型创业公司到大型互联网公司，越是大规模的应用场景下，这些原生的 workloads 越无法满足复杂的业务部署诉求。
OpenKruise 是阿里巴巴内部百万 Pod 调度场景中沉淀出来的最佳实践。本次分享的内容包括：原生 workloads 存在的问题、OpenKruise 带来了哪些新的能力、社区发展规划等。
分享人：赵明山（立衡），OpenKruise 作者&初创成员之一，阿里云技术专家，阿里云容器服务团队，负责阿里巴巴百万容器调度系统研发工作。
一、阿里巴巴应用部署基座：OpenKruise
1. OpenKruise 是什么？
OpenKruise 是基于 Kubernetes 的扩展应用管理套件，是 CNCF 托管的 Sandbox 项目，阿里巴巴经济体上云全面依赖的部署基座。
OpenKruise项目地址：https://github.com/openkruise/kruise
2. OpenKruise vs.PaaS
• OpenKruise 不是一个 平台，并且也不会提供任何 PaaS 层的能力；
• PaaS可以通过使用 OpenKruise 提供的扩展功能，使应用部署、管理流程更加强大与高效；
下图是基于 Kubernetes 部署容器的逻辑架构图，通过 GitLab 或 Jenkins 部署镜像，将应用通过容器部署到 Kubernetes 集群，与 Kubernetes 交互是以 Apiserver 的方式，OpenKruise是 Kubernetes 扩展的组件，与 Kubernetes 完全兼容。
基于 OpenKruise 部署 Kubernetes 的逻辑架构图
3. OpenKruise 能做什么？
a. OpenKruise 专注领域包括：
• 通用工作负载（部署、发布）；
• Sidecar容器管理；
• 应用分区管理；
• 增强运维能力；
• 可用性防护；
b. OpenKruise的通用性：
• 绝大部分能力都是基于 CRD 扩展来定义；
• 可以运行在任意纯净的 Kubernetes 集群中；
官方文档：https://openkruise.io/zh/docs/
4.阿里“双十一”全链路部署基座
OpenKruise是阿里“双十一”全链路部署基座。其中：
a. CloneSet部署了集团大部分无状态应用；
b. Advanced StatefulSet是针对原生StatefulSet的扩展，部署有状态的中间件应用；
c. SidecarSet是Sidecar管理的资源，针对Mesh容器、运维容器、安全容器的管理；
d. Advanced DaemonSet针对基础网络组件和基础存储组件；
e. Operation Capabilities针对运维能力。
二、OpenKruise为云原生带来高效的部署能力
1. 核心能力1 - 原地升级
a. Kubernetes - Pod维度的不可变基础设施
如下图所示，在K8s中Pod重建需要删除旧的Pod然后调度再拉起新的Pod，流程复杂且耗时长，如果在类似双十一的场景下就无法实现。
b. 容器维度的管控能力 - 原地升级
下图中CloneSet是针对Deployment的工作负载，省去中间的Replicas直接连Pod，如果Pod要升级，CloneSet先停止nginx v1，拉起v2版本镜像，这个过程不涉及Pod重建，Pod的网络、存储都不变，即为原地升级。
c. 原地升级的优势：
• 节省了调度的耗时，Pod的位置、资源都不发生变化；
• 节省了分配网络的耗时，Pod还使用原有的IP；
• 节省了分配、挂载远程盘的耗时，Pod还使用原有的 PV（且都是已经在Node 上挂载好的）；
• 节省了大部分拉取镜像的耗时，因为Node上已经存在了应用的旧镜像，当拉取新版本镜像时只需要下载少数的几层layer；
• 原地升级Pod中某个容器时，其他容器保持正常运行，网络、存储均不受影响。
2.核心能力2 - Sidecar管理
Sidecar管理是通过在Pod里定义专门容器，来执行主业务容器需要的辅助工作。比如：日志收集、Debug应用、Service Mesh Istio。
a. 优势：
将辅助能力同业务容器解耦，实现独立发布和能力重用；
b. 缺点：
• Sidecar升级将导致业务Pod重建；
• 业务Pod配置耦合（运维、安全、代理）多种sidecar，增加配置的复杂性，以及sidecar更新难度。
c. SidecarSet管理Sidecar容器的利器
针对上述缺点开发的SidecarSet工作负载，如下图：
• 业务只需要配置Pod中web-server服务，中间件logtail开发者配置SidecarSet中的selector和logtail containers细项。业务配置好将Pod放入K8s集群，OpenKruise会将webserver和Sidecar Container自动注入Sidecar容器，实现分开配置，以减轻业务压力；
• OpenKruise的另一个能力是原地升级Sidecar容器，中间件开发者需要升级logtail只需在Sidecar配置中将logtail镜像版本从v1改成v2，OpenKruise监测到后会选择适合的Pod停止其旧版本并原地拉起新版本，这一过程不会对业务有任何影响。
3.核心能力3 - 镜像预热
a. Pod的创建过程vs.用户期望：
• 用户的期望：极致弹性、妙极扩容、弹出即可用；
• 实际创建过程：
思考：镜像拉去占用了大量时间，能否有优化的空间？
b. OpenKruise提供“规模化镜像预热的能力”
OpenKruise提供ImagePullJob的CRD解决上述问题。
• 组合拳：镜像预热+扩容
1) 原始Pod扩容流程/耗时：
2) 用ImagePullJob长期预热app基础镜像和Sidecar镜像：
3) 基础预热后的Pod扩容/耗时：
• 终极组合拳：镜像预热+原地升级
1) 基础预热后的Pod重建升级流程/耗时：
2) 默认原地升级：
3) 原地升级+镜像预热：
CloneSet可以在灰度第一批Pod时，提前在后续批次Pod的节点上预热即将发布的新版镜像，以节约耗时，提升发布效率。
4) 终态原地升级：
4. 核心能力4 - 应用安全防护
a. 级联删除防护
面向终态是Kubernetes的一个核心能力，但同时也存在一定的风险（见下图）：
• CRD误删除导致所有CR对象丢失；
• Namespace误删除导致Namespac下所有对象被删除；
• Workload误删除导致Workload下面所有的Pod被删除。
因此，OpenKruise提供级联删除防护能力，将定义的资源增加一个label，当发生删除时，OpenKruise会对加label的资源进行再校验。
metadata: labels: policy.kruise.io/delete-protection: Cascading
• Cascading：这个对象如果还有可用的下属资源，则禁止被删除；
• Always：这个对象禁止被删除，除非上述label 被去掉。
支持防护的资源类型：
• Namespace
• CustomResourceDefinition（CRD）
• Built-in Workloads：Deployment，StatefulSet，ReplicaSet
• Kruise Workloads：CloneSet，Advanced StatefulSet，...
b. 应用Pod最小可用数量保护
Kubernetes原生PDB（PodDisruptionBudget）只能拦截 Pod eviction驱逐操作。OpenKruise的PUB（PodUnavailableBudget）会针对主动导致Pod不可用的操作进行整体的防护，包括：
• 驱逐；
• 删除；
• 应用原地升级；
• Sidecar原地升级；
• （主动）容器重启；
如下代码，当定义maxUnavailable：25%时，OpenKruise会尽量保证主动导致Pod不可用的操作数量在25%以下。
apiVersion: policy.kruise.io/v1alpha1 kind: PodUnavailableBudget spec: selector: # ... label selector targetRef: # ... workload reference maxUnavailable: 25% # minAvailable: 15
当所有会导致Pod不可用的操作，在经过ApiServer时全部被OpenKruise Webhook拦截，Webhook会根据客户定义的PUB结合Pod当前所用数量来决定当前操作是否可以执行。
5. 核心能力5 - 分区拓扑和弹性管理
a. 云时代的“部署挑战”
在K8s中部署都是均匀的，不会有优先等级。OpenKruise提供弹性调度能力，在业务高峰期时将Pod部署在ECI上按量付费，高峰期过后就可以将ECI中的Pod缩容。
b. Kubernetes原生提供的多区域打散能力
缺点：
• 只能按topology均等打散，不支持比例、不支持优先级、不支持动态选择；
• 调度器无法干预缩容，依赖workload自身实现。
c. WorkloadSpread“分区管理和弹性能力”
WorkloadSpread指针对一个Deployment下面应用部署分多个区域：固定区域和弹性区域，因此可以实现如下核心能力：
• 支持原生Workload；
• 按比例部署；
• 支持缩容优先级；
• 扩缩容均保持拓扑；
• 支持soft spread能力；
• 旁路方式，可插拔；
• Patch Pod Template：针对不同区域不同机器Pod可以进行差异化配置；
WorkloadSpread架构
d. “极致弹性调度”最佳实践
在上图代码中：
• subset-a和subset-b，分别对应右图中的自由资源池和弹性资源池；
• maxRelicas:300，是自由资源池最多300个Pod；
右图是饿了么的一个场景，由于其白天使用的多而晚上少，因此使用定时HPA，白天扩容机器到弹性资源池的Pod中，晚上再关闭，只保留自有资源池。
三、社区发展与规划
1. OpenKruise社区发展
• Star：2.9k
• Contributor：69
• 2019.7（v0.1）-> 2021.12（v1.0.0）
• 规划：2022 年CNCF Sandbox -> Incubation
• 双周周会（每周四晚19点）
业界用户：
• 国内：阿里巴巴、蚂蚁、携程、苏宁、OPPO、小米、斗鱼TV、有赞、Boss直聘、申通、小红书等25+ 登记企业用户；
• 国外：Lyft、Bringg、Arkane Systems、Spectro Cloud 等 5+ 登记企业用户。
感兴趣的朋友可以加入社区钉钉群了解更多内容，一起交流分享。
2. Roadmap
未来会针对以下领域开展工作：
a. 针对有状态的服务，比如固定IP或PV；
b. 资源分发；
c. 分批发布、流量发布、灰度发布；
欢迎对以上领域感兴趣的朋友加入社区一起分享。
