OpenKruise云原生应用全生命周期自动化实战

1、OpenKruise云原生应用全生命周期自动化实战技术创新，变革未来目录云原生环境下，大规模应用的场景和挑战是什么OpenKruise 解决规模化应用部署发布问题的思路与实现后续应用 Operator 编写和运维管控提供的能力规划大规模应用的场景和挑战扩展能力：编写标准的 K8s 扩展优化 operator 框架和模式集群性能：ApiserverList watchOperator容器 vs 虚拟机故障迁移保活机制0业务稳定性：复杂部署策略：扩缩容发布迁移（驱逐）多可用区管理123应用负载管理（workload）原生workload能力缺陷原生 workload 发布模式原地升级模式原地升级:

2、Node不变，不经过重新调度IP不变、升级过程网络不断Volume不变，完全复用挂载发布速度大幅提升（只涉及拉镜像增量部分）CloneSet 升级策略Workload 能力对比功能DeploymentCloneSetStatefulSetAdvanced StatefulSetPod 名字GeneratedGeneratedOrderedOrdered先扩再缩（主动迁移）NoYesNoNo流式扩容NoYesNoNoPod重建升级YesYesYesYesPod原地升级NoYesNoYes分批（灰度）发布NoYesYesYes最大不可用数量YesYesNoYes最大弹性数量YesYesNoNo发布

3、顺序 可配置 (优先级、打散)NoYesNoYesPod 升 级 前 后 hook (preUpdate/postUpdat e)NoYesNoYesSidecar 管理方式定义在应用workload中当应用和workload数量众多时，很难统一增 加应用开发者不知道（甚至也不关心）自己的 应用需要配置哪些sidecar容器当sidecar镜像需要升级时，如果把所有应 用的workload全部升级一遍？通过SidecarSet注入单独定义sidecar容器的模板和注入规则， 和应用workload解耦应用开发者们不需要再关心workload中需要 写哪些sidecar容器支持懒升级和原地升级s

4、idecar容器，后者 主动升级过程中不会影响应用容器运行Sidecar 注入示例CloneSet(A)Pod-aPod-bPod-cCloneSet(B)Pod-xPod-yPod-zSidecarSet通过admission control注入原地升级，与应用解耦OpenKruise 现有能力应用 operator 现存问题Operator“mesh”Runtime 机制：将operator的核心功能从 框架SDK中移出，使用户 operator变得更轻量化， 可以聚焦处理逻辑本身。从框架中移出的operator 核心功能被下沉到sidecar 中，提供标准化的gRPC 接口给用户operator。Operator 灰度升级传统operator/controller升 级过程：单主模式，直接把leader从v1 版本切到v2版本，无法灰度Platform提供的灰度升级：保留v1版本不动，扩出v2版 本operator，此时v2无流量用户通过修改灰度规则CR， 指定v2版本需要承接流量的 规 则 （Namespaces