k8s原生提供了针对无状态应用、有状态应用、作业等多种应用负载，利用原生提供的应用负载，业务可以实现面向终态的各种应用交付特性。然而原生的应用负载在应用交付效率等方面无法满足很多实际应用的需求，例如原生的应用负载在发布新版本时，要求所有pod都进行重调度，从而导致镜像下载等操作都需要重新执行。为了解决原生应用负载在发布效率上的问题， 阿里巴巴最近开源了一组通用的扩展应用负载，涉及了有/无状态应用，作业，sidecar容器等的扩展交付能力,例如原地升级、热部署等。这次分享会介绍这些应用负载的原理，以及如何使用这些扩展应用负载解决应用交付的效率问题，并在CICD 流水线中集成这些应用负载。

1.  K8S 原生workload 的介绍、比较以及历史演进
2.  原生workload的问题分析
3.  滚动发布和原地升级的比较
4.  原地升级带来的收益和挑战
5.  不可变基础设施的理念和再思考
6.  Sidecar容器和多容器设计模式
7.  热更新容器模式
8.  阿里巴巴在应用负载领域的实践
9.  Kruise 介绍
10.Kruise-advance statefulset + demo
11.Kruise-sidecarset + demo
12.Kruise-BroadcastJob + demo
13.CICD流水线中集成Kruise的方法
14 Kruise未来的发展方向

目标：
Kruise在实现上，采用了标准的k8s扩展方式，方便用户接入和进一步扩展。 
成功点：
Kruise在部分云原生理念上，不可变基础设施，有别于原生k8s实现的云原生实践，为行业在云原生改造上的实践提供了新的思路；在多容器设计模式上， 丰富了sidecar容器的管理能力， 从而支持了热更新容器这种新的多容器模式，为数据管理、应用热部署等需求提供了新的可能。 
启示： 
Kruise为大规模的云原生应用交付提供了一组通用的扩展应用负载，这些应用负载可以独立使用，也可以成为更复杂的应用负载的基本构成单元。使用这些应用负载可以弥补原生应用负载在交付效率上的问题，帮助业务在生产环境构建更加高效稳健的云原生应用交付流程。