1、KubeMeet 开发者沙龙云原生应用管理专场2021/04/07 杭州阿里巴巴基于KubeVela的新一代应用交付管理系统实践主讲人姓名：王仁达阿里云-云原生应用平台2021/04/17目录云原生应用交付面临的问题与挑战基于KubeVela的标准化应用交付核心原理基于KubeVela的应用管理实践01云原生应用交付云原生应用交付面临的问题与挑战面临的问题与挑战云原生应用交付领域痛点云原生应用交付面临挑战多样化的交付环境 Workload 多样：对接不用集群环境、灰度发布、流量管理方案 部署环境多样：公共云、专有云、私有化部署，对接不同APM方案 云资源使用多样：对接不同Provider、云资

2、源管理方案，对接云产品差异化配置应用开发者 门槛高，学习各种K8s使用平台开发者 开发成本高，写各种Controller云原生应用交付领域痛点基于K8s资源组合 复杂、难懂、门槛高 能力局限、不同场景各不相同 不统一，每个模式需要重新编写发布对接Kubernetes/DeploymentKubernetes/StatefulSet云原生应用交付领域痛点K8s-sigs Application 只描述应用模型元数据，研发、运维无从入手 无人维护、缺乏活跃度 信息不足以对接发布kubernetes-sigs/application云原生应用交付领域痛点Helm Chart 黑盒，不明确内部有哪些资

3、源 缺失发布能力，helm upgrade没有灰度能力 无法使用/对接云资源云原生应用交付领域痛点基于CRD自定义实现 需要大量K8s经验 扩展性、灵活性、可移植性不足 增加用户心智某游戏公司自定义某游戏公司自定义workloadPinterest02基于基于KubeVelaKubeVela的的标准化应用交付系统核心原理标准化应用交付系统核心原理What is KubeVela？标准化的云原生应用平台构建引擎 基于 Kubernetes 和 OAM 模型构建 纯 Golang 编写 社区发起，社区构建 2021.03 KubeVela 1.0 发布 1.7k star，60+contribut

4、orsKubeVela 1.0 主要能力丰富的抽象模板能力（组合、转换、拆分、状态回流、数据传递等）渐进式发布能力应用云资源创建和绑定多集群、多环境的应用部署使用 Helm chart 对接 KubeVelaTraits 生态KubeCon NA发布发布KubeVela的Application对象 完整的应用描述文件（以应用为中心）灵活的“Schema”（能力模板自由组合）GitOps友好（放置于应用代码库中）无需学习K8s细节（完整的用户侧抽象）可适配任意K8s集群与部署环境（环境无关）镜像与启动参数多组件弹性扩缩组件类型可灵活扩展的其他能力KubeVela 的能力模板 组件类型抽象封装方式

5、K8s 对象模板CUE 模板工作负载类型Helm chart 封装其他封装使用方式(jsonschema)KubeVela 的能力模板 运维能力抽象封装方式抽象封装方式可作用的工作负载可作用的工作负载K8s对象模板对象模板CUE模板模板Helm chart封封装装其他封装其他封装Trait自身自身CRD对象对象使用方式使用方式(jsonschema)示例：上线新功能 metrics平台研发团队：开发了一个新 Operator 叫做 metrics（监控）编写一个 K8s 能力描述文件 metrics.yaml平台管理员：执行$kubectl apply-f metrics.yaml用户：立刻就

6、可以在 Application 中定义一个新的字段 metrics无需系统更新或重启Platform Builder 模型层能力注册查看“能力模板”的用法1.能力模板注册时，KubeVela 控制器会自动生成 OpenAPI v3 的 json schema 文件和文档。2.通过 vela 的命令行工具可以查看。3.用户也可以自己基于 json schema 去渲染集成进自己的前端KubeVela 为什么能对不同 Workload 做统一发布？工作负载类型工作负载类型 统一统一 类型注册和识别类型注册和识别健康检查健康检查 统一统一 状态检查和回流状态检查和回流发布模式发布模式 统一统一 发布

7、方式发布方式资源模板资源模板 统一统一 抽象方式抽象方式03基于基于KubeVelaKubeVela的应用管理实践的应用管理实践KubeVela使用方式应用平台团队CanaryAutoscaleRouteWeb ServiceDatabase能力模板业务用户选择并初始化部署环境部署环境模板选择能力模板填写模板参数组装能力为“应用应用”RDS生产集群生产集群PodNginxPod测试集群测试集群生产集群生产集群https:/myapp.ioRunning Instances注册工作负载类型运维特征发布/部署CRD 注册中心注册中心WorkerWeb ServiceDatabaseRoute应用管

8、理依赖的能力企业级应用发布能力 版本化 分批发布 滚动发布/原地发布 发布暂停 发布回滚 日志监控 健康检查 多版本部署 多版本流量灰度 多集群/多环境灰度云资源管理能力 多种资源编排方案(Terraform、Crossplane)标准化应用绑定抽象能力 各种资源组合、拆分 无需写各种Controller对接 安全的patch方案应对交付场景 支持helm用于交付场景抽象能力组合、拆分资源容器基本参数容器基本参数VolumeCconfigMapService抽象能力支持helmpatch helm资源资源渐进式发布-面向终态模式发布策略定义发布策略定义ApplicationApplicatio

9、nAppRevisionAppRevisionv1v1AppRevisionAppRevisionv2v2AppRevisionAppRevisionv3v3 创建创建 第一次更新第一次更新 第二次更新第二次更新控制器循环发布完毕发布完毕ComponentDefinitionComponentDefinitionTraitDefinitionTraitDefinitionApplicationApplicationsnapshot(v1)1)统一从统一从Definition中获取中获取应用工作负载类型和特征。应用工作负载类型和特征。2)根据策略根据策略按批按批自动灰度。自动灰度。K8sK8sR

10、esourceResource渐进式发布-发布单模式ApplicationApplicationAppRevisionAppRevisionv1v1AppRevisionAppRevisionv2v2AppRevisionAppRevisionv3v3 创建创建 第一次更新第一次更新 第二次更新第二次更新发布状态机发布单模式下发布单模式下Application的更新的更新不再实际操作资源，只生成版本快不再实际操作资源，只生成版本快照照AppAppRolloutRollout-1 1开始开始暂暂停停继续继续成功成功AppAppRolloutRollout-2 2新的发布使用新的发布单新的发布使用

11、新的发布单对象对象K8sK8s ResourceResourcev1v1-v2v2渐进式发布-扩缩ApplicationApplicationAppRevisionAppRevisionv1v1AppRevisionAppRevisionv2v2AppRevisionAppRevisionv3v3 创建创建 第一次更新第一次更新 第二次更新第二次更新发布状态机发布单模式下发布单模式下Application的更新的更新不再实际操作资源，只生成版本快不再实际操作资源，只生成版本快照照AppAppRolloutRollout-1 1开始开始暂暂停停继续继续成功成功AppAppRolloutRollo

12、ut-2 2扩缩跟发布使用相同模型扩缩跟发布使用相同模型K8sK8s ResourceResourcepatchpatch replicasreplicas渐进式发布-面向终态的多版本共存cluscluster2ter2cluscluster1ter1ApplicationApplicationAppRevisionAppRevisionv1v1AppRevisionAppRevisionv2v2AppRevisionAppRevisionv3v3 创建创建 第一次更新第一次更新 第二次更新第二次更新多版本模式下多版本模式下Application的更新的更新不再实际操作资源，只生成版本快不再实

13、际操作资源，只生成版本快照照控制器循环ApplicationApplicationDeploymentDeploymentK8sK8sResourceResource v1v1K8sK8sResourceResource v2v2K8sK8sResourceResource v3v3指定不同版本的流量配比指定不同版本的流量配比多集群部署多集群部署渐进式发布-多环境/多集群/多版本ENVENV 2 2ENVENV 3 3ENVENV 1 1AppRevisionAppRevisionv1v1AppRevisionAppRevisionv2v2AppRevisionAppRevisionv3v3多

14、环境模式下多环境模式下Application的更新不的更新不再实际操作资源，只生成版本快照再实际操作资源，只生成版本快照控制器循环ApplicationApplicationDeploymentDeploymentK8sK8sResourceResource v1v1K8sK8sResourceResource v2v2K8sK8sResourceResource v3v3ApplicationApplicationENVENV 1 1ENVENV 2 2ENVENV 3 3不同不同ENV对对Application做做不同参数的不同参数的Patch生成不同版本生成不同版本基于环境的基于环境的P

15、atch定义定义环境、环境、集群、依赖包集群、依赖包patchpatchpatch云资源管理-单应用完成供给和消费云资源配置云资源配置资源绑定资源绑定开通云资源开通云资源指定指定绑定绑定secret连接信息写入连接信息写入secretsecret patch到到pod通过模板抽象能力屏蔽复杂参数，通过模板抽象能力屏蔽复杂参数，用户友好用户友好云资源管理-不同应用完成供给和消费连接信息写入连接信息写入secret指定绑定指定绑定secret资源供给资源供给资源消费资源消费/+insertSecretTo=dbConn将secret数据注入dbConndbConn注入注入podK8sK8s Sec

16、retSecret资源绑定资源绑定云资源管理-集成Terraform云资源管理-集成Terraformoutput写入指定写入指定secret配置参数配置参数资源模板资源模板欢迎广大 Gopher 加入到 KubeVela 社区！KubeVela地址地址:http:/kubevela.io/https:/ Next 云资源管理 多环境管理 组件生命周期管理 ADP能力集成KubeMeetTHANK YOUTHANK YOUA I O S 应 用 管 理 和 交 付 实 践马浩第四范式机器学习平台工程师2021/04/17目录背景实践和落地场景问题和挑战探索第四范式1998年图灵奖获得者 Jim

17、 Gray于2005年提出第四范式第一范式第一范式实验科学第二范式第二范式理论科学第三范式第三范式计算科学第四范式第四范式数据科学数据科学人类记录现象人类记录现象（钻木取火、摩擦起电钻木取火、摩擦起电）重复记录的现象重复记录的现象人类总结理论人类总结理论诠释自然现象诠释自然现象通过计算机推演理论通过计算机推演理论模拟现象模拟现象计算机从海量数据中计算机从海量数据中发现规律、形成理论诠释发现规律、形成理论诠释自然现象自然现象背景AIOS Era:Before AIOS:All-In-OneDevOps Module TemplateEverything Is AppInternal App,Ec

18、o Partner App,Developer AppPlug-inUnified or Independently ReleasedSlow IterationPoor FlexibilityNot Enough OpennessAIOS:Machine Learning Platform背景What is App?What does App look like?Distributed Applications on KubernetesMulti-Runtime Microservices Architecture-BilginIbryamOpen Application Model Sp

19、ecificationInitial Research and Investigation背景Designing SchemeApp static file-NexusApp backend module-componentOperator PlatformModel-ServingHypercycle ML实践Base on oam-kubernets-runtimeTaskWorkloadServerWorkloadFlinkWorkloadManualScalerTraitAutoScalerTraitIngressTraitFlaggerTraitVolumeMounterTrait-

20、Workload:Trait:实践实践App Integration Formatapp static resourceservice.yaml templatecomponents:app:docker tar component.yamltemplate flyway,落地场景App Integration落地场景Operator Platform落地场景Model Serving落地场景HyperCycle MLParts of online modules Parts of offline modules问题与挑战ManualScalerTrait replicas resource

21、memory,cpu,gpu,https:/ create deploytrait update replicas to 3update appconfig image from 1.0.0 to2.0.0replicas back to 0pre patch the deployment of workload use the managedFields问题与挑战VolumeMouterTraithttps:/ workload create sts trait management volume volumeMounts volumeClaimTemplates volumes stora

22、geclass sts 禁止更新volumeClaimTemplates探索Service Binding service invocationsolution templates:binding set+ComponentHub+middleware statusgovernance event driver sidecar探索欢迎加入 4ParadigmKubeMeetTHANK YOUTHANK YOU扫码填写有奖调研OpenKruise：实现Kubernetes中容器粒度的不可变基础设施主讲人姓名：王思宇（酒祝）阿里云 技术专家2021/04/17目录：OpenKruise 是什么什么

23、是容器粒度的不可变基础设施如何对 K8s 无侵入实现容器粒度操作通过 OpenKruise 优化应用部署管理OpenKruise OpenKruise 是什么是什么01OpenKruise 是什么https:/ Kruise 是是Cruise 的谐音，的谐音，K for Kubernetes，寓意，寓意Kubernetes 上应用的自上应用的自动化巡行动化巡行CNCF托管的托管的Sandbox项目项目阿里云开源的基于阿里云开源的基于Kubernetes 的云原生应用自动化套件的云原生应用自动化套件阿里巴巴经济体上云全面使用的部署基座阿里巴巴经济体上云全面使用的部署基座用户：用户：阿里巴巴集团、

24、蚂蚁集团、携程、阿里巴巴集团、蚂蚁集团、携程、OPPO、斗鱼、斗鱼TV、有赞、苏宁、比心、有赞、苏宁、比心、Boss直聘、申通、小红书、火花思维、直聘、申通、小红书、火花思维、VIPKID、掌门教育、杭银消费、万、掌门教育、杭银消费、万翼科技、多点翼科技、多点Dmall、佐疆科技、享住智慧、艾佳生活、永辉科技中心、跟、佐疆科技、享住智慧、艾佳生活、永辉科技中心、跟谁学、谁学、Deepexi、哈啰出行、哈啰出行Lyft、Bringg、Arkane Systems、Spectro Cloud、LinkedinOpenKruise 当前提供的功能CloneSet-提供了更加高效、确定可控的应用管理和

25、部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略，可以满足更多样化的应用场景。Advanced StatefulSet-基于原生 StatefulSet 之上的增强版本，默认行为与原生完全一致，在此之外提供了原地升级、并行发布（最大不可用）、发布暂停等功能。SidecarSet-对 sidecar 容器做统一管理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。Advanced DaemonSet-基于原生 DaemonSet 之上的增强版本，默认行为与原生一致，在此之外提供了灰度分批、按 Node label 选择、暂停、热升级等

26、发布策略。UnitedDeployment-通过多个 subset workload 将应用部署到多个可用区。BroadcastJob-配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 任务。AdvancedCronJob-一个扩展的 CronJob 控制器，目前 template 模板支持配置使用 Job 或BroadcastJob。ImagePullJob-支持用户指定在任意范围的节点上预热镜像。OpenKruise 即将提供的功能容器重启容器重启-支持对 running Pod 中的指定容器触发重启操作。级联删除防护级联删除防护-防护 CRD、Namespace、W

27、orkload 的删除操作，避免批量 Pod 等资源被误删除。PodUnavailableBudget-应用 Pod 可用性保护，相对于只能限制驱逐的 PDB，PUB 能保护 Pod 的删除、驱逐、原地升级等所有会导致服务不可用的操作。全局全局Pod删除流控删除流控 可配置集群中 Pod 删除流控规则，在限定时间范围内删除 Pod 数量超过阈值后则发生熔断。通用 operator 扩展-支持对 operator 做运行时管控，通过水平扩展、灰度升级能力解决 controller 单主问题，在外部对 controller 的异常行为做拦截防护、控制爆炸半径，同时带来更灵活的集群内多租能力什么是容

28、器粒度的不可变基础设施什么是容器粒度的不可变基础设施02单个 Pod 运行态apiVersion:v1kind:Podmetadata:labels:#.spec:initContainers:-name:init#.containers:-name:sidecar#.-name:app#.status:#.initsidecarappCRIkubeletnetworksandboxKubernetes Pod 维度的不可变基础设施Pod 创建即不可变（主要对于 spec 配置）原生原生workload发布特点：发布特点：修改 image 镜像 重建 Pod 升级修改 env 等环境变量 重建

29、 Pod 升级甚至修改 labels/annotation 还是重建 Pod 升级OpenKruise 所提供的容器粒度管控能力应用部署层面，以 CloneSet 为例：支持修改 image 以及 labels/annotations 原地升级sidecar容器定义：容器定义：支持独立定义 sidecar 容器一次声明，应用规模化注入容器管理：支持对任意 running Pod 中一个或多个容器做重启操作镜像预热：指定任意范围的节点上批量拉取镜像OpenKruise 带来的容器粒度不可变基础设施基本特性：延续容器技术所特有的环境一致性容器层面不可变，同个镜像创建出的容器不会变化已创建的容器自身

30、不可修改升级特性：以“容器组”的角度来对待 Pod，允许对组中一个或多个容器做升级灵活组合，定义通用 sidecar“组员”解决 K8s 中应用自主重启需求镜像粒度的控制能力如何对如何对 K8s K8s 无侵入实现容器粒度操作无侵入实现容器粒度操作03node原生 Kubernetes 基础形态CRIkubeletkube-controller-managerkube-apiserverkube-apiservercontainercontainercontainercontainerCNIkube-schedulerKubernetes+OpenKruise 形态kube-controlle

31、r-managerkube-apiserverkube-apiserverkube-schedulernodeCRIkubeletcontainercontainercontainercontainerCNIkruise-daemonkruise-managercontrollerswebhooks原地升级 技术背景(1)kubelet计算容器计算容器hash(2)apiserver对对Pod更新限制更新限制(3)containerStatuses上报上报(4)readinessGate控制控制Pod readyspec:containers:-name:sidecarimage:.env:.

32、-name:appimage:.env:.appkubeletsidecarhash1hash2/validate updateable fields:/1.spec.containers*.image/2.spec.initContainers*.image/3.spec.activeDeadlineSeconds目前对于存量目前对于存量Pod只允许更新只允许更新spec中以下字段：中以下字段：spec:containers:-name:nginximage:nginx:lateststatus:containerStatuses:-name:nginximage:nginx:mainlin

33、eimageID:docker-pullable:/nginxsha256:xxxx可能不一致可能不一致spec:readinessGates:-conditionType:MyDemostatus:conditions:-type:MyDemostatus:True两个前提条件：两个前提条件：1.容器全部容器全部Ready（ContainersReady）2.readinessGates 中定义的都对应中定义的都对应conditions 中中status:“true”原地升级 技术实现 推导(1)单个单个Pod如何升级如何升级(2)如何判断升级成功如何判断升级成功(3)如何保证流量无损如何保

34、证流量无损(4)原地升级是否存在一些问题？原地升级是否存在一些问题？由背景由背景(1)可知：对可知：对Pod中中spec.containersx修改后，修改后，kubelet会感知到会感知到hash变化，因此重建新容器。变化，因此重建新容器。由背景由背景(2)可知：对一个存量可知：对一个存量Pod 的的spec.containersx 中中的修改，仅限于的修改，仅限于image 字段。字段。结论：对于一个现有的结论：对于一个现有的Pod，我们能且只能修改其中的，我们能且只能修改其中的spec.containersx.image 字段，来触发字段，来触发Pod 中对应容器中对应容器升级到一个新的

35、升级到一个新的image。由背景由背景(3)可知：比较可知：比较spec 和和status 中的中的image 字段是不字段是不靠谱的，因为很有可能靠谱的，因为很有可能status 中上报的是中上报的是Node 上存在的上存在的另一个镜像名（相同另一个镜像名（相同imageID）。）。结论：判断结论：判断Pod 原地升级是否成功，相对来说比较靠谱的原地升级是否成功，相对来说比较靠谱的办法，是对比升级前后的办法，是对比升级前后的imageID是否变化。是否变化。隐含的问题：不能用隐含的问题：不能用tag不同、实际不同、实际imageID相同的镜像相同的镜像做原地升级。做原地升级。由背景由背景(4

36、)可知：可知：addon组件可以通过设置组件可以通过设置readinessGates 和更新和更新pod.status.conditions 中的自定义状态，来控制中的自定义状态，来控制Pod 是否可用。是否可用。结论：定义一个叫结论：定义一个叫InPlaceUpdateReady的的readinessGate，升级前修改，升级前修改condition为为not ready，升，升级完成后修改级完成后修改condition为为ready。达到原地升级过程中摘。达到原地升级过程中摘流的目标。流的目标。Q：原地升级能否支持修改：原地升级能否支持修改env等字段？等字段？A：由于：由于apiserv

37、er的限制，目前只能支持针对的限制，目前只能支持针对image的原地的原地升级，修改升级，修改env等其他字段还是会触发重建升级。等其他字段还是会触发重建升级。Q：通过：通过imageID判断升级完成有什么隐含问题？判断升级完成有什么隐含问题？A：不能用：不能用tag不同、实际不同、实际imageID相同的镜像做原地升级。相同的镜像做原地升级。Q：通过：通过readinessGate切流是否有损？切流是否有损？A：为了避免摘流延迟，：为了避免摘流延迟，Kruise提供了优雅静默时间，可以等提供了优雅静默时间，可以等待摘流一段时间后再真正执行升级。待摘流一段时间后再真正执行升级。Sidecar

38、独立定义与注入Sidecar 独立定义与升级Comming in v0.9.0Pod 容器重启（重建）apiVersion:apps.kruise.io/v1alpha1kind:ContainerRecreateRequestmetadata:namespace:pod-namespacename:xxxspec:podName:pod-namecontainers:-name:appstrategy:failurePolicy:FailorderedRecreate:falseterminationGracePeriodSeconds:30unreadyGracePeriodSeconds

39、:3activeDeadlineSeconds:300ttlSecondsAfterFinished:1800status:containerRecreateStates:-name:appphase:Succeededphase:Completed#.kubeletapp_0kruise-daemonkruise-managercontrollerswebhookspreStophookstopapp_1noticecreate-startCRI通过通过 OpenKruise OpenKruise 优化应用部署管理优化应用部署管理04应用部署 workload 对比功能DeploymentD

40、eploymentCloneSetCloneSetStatefulSetStatefulSetAdvancedAdvancedStatefulSetStatefulSetDaemonSetDaemonSetAdvancedAdvancedDaemonSetDaemonSet指定缩容NoYesNoYesNoNoPod重建升级YesYesYesYesYesYesPod原地升级NoYesNoYesNoYes分批（灰度）发布NoYesYesYesNoYes最大不可用数量YesYesNoYesYesYes最大弹性数量YesYesNoNoNoYes发布顺序 可配置(优先级、打散)NoYesNoYesNoY

41、esPod生命周期hook(preUpdate/postUpdate/preDelete)NoYesNoNoNoNo应用原地升级用法与优势原地升级 vs 重建升级：节省了调度的耗时，Pod 的位置、资源都不发生变化节省了分配网络的耗时，Pod 还使用原有的 IP节省了分配、挂载远程盘的耗时，Pod 还使用原有的 PV（且都是已经在 Node 上挂载好的）节省了大部分拉取镜像的耗时，因为 Node 上已经存在了应用的旧镜像，当拉取新版本镜像时只需要下载少数的几层 layer原地升级 Pod 中某个容器时，其他容器保持正常运行，网络、存储均不受影响CloneSet、Advanced Statefu

42、lSet 均支持指定 多种 Pod 升级方式：ReCreate：重建 Pod 升级，和原生Deployment/StatefulSet 一致InPlaceIfPossible：如果只修改 image 和metadata 中的 labels/annotations 等字段，则触发 Pod 原地升级；如果修改了其他template spec 中的字段，则退化到 Pod 重建升级。InPlaceOnly：只允许修改 image 和 metadata 中的 labels/annotations 等字段，只会使用原地升级。使用 SidecarSet 管理 sidecar 容器原生 K8s 用法存在的问题

43、：1.业务Pod里面包含了运维、安全、代理等多个sidecar 容器，业务不仅要完成自身主容器的配置，而且还需要熟悉这些 sidecar 容器的配置（增加了业务方的工作量和风险）2.Sidecar 容器的升级需要连同业务主容器一起重建（原生 Deployment 等 workload 基于 Pod 重建来实现Pod的滚动升级），推动和升级支撑着线上数百款业务的sidecar容器（极大的业务阻力）3.作为 sidecar 容器的提供者对线上诸多各种配置以及版本的 sidecar 容器没有直接有效的升级手段（潜在的管理风险）SidecarSet 特性：配置单独管理：为每一个sidecar容器配置单

44、独的SidecarSet配置，方便管理自动注入自动注入：在新建、扩容、重建：在新建、扩容、重建pod的场景中，实现的场景中，实现sidecar容器的自动注入容器的自动注入原地升级原地升级：支持不重建：支持不重建pod的方式完成的方式完成sidecar容器容器的原地升级，不影响业务主容器，并包含丰富的灰度的原地升级，不影响业务主容器，并包含丰富的灰度发布策略发布策略热升级（comming in v0.9.0）：对于 envoy/nginx 这类接入流量的 sidecar 容器，默认原地升级过程中会导致流量中断。下个版本的 SidecarSet 会提供 sidecar热升级能力（同时也需要 sid

45、ecar 中的进程支持热切换）组合拳：镜像预热+扩容(1)原始原始Pod扩容扩容流程流程/耗时：耗时：createcreateschedulescheduleattach/mountattach/mount volumevolumecnicni allotateallotatepullpull imageimage forfor sidecarsidecarstartstart sidecarsidecarpullpull imageimage forfor appappstartstart appapp(2)用用ImagePullJob长期预热长期预热app基础镜基础镜像和像和sidecar

46、镜像：镜像：apiVersion:apps.kruise.io/v1alpha1kind:ImagePullJobspec:image:xxx/app-base:latext#.apiVersion:apps.kruise.io/v1alpha1kind:ImagePullJobspec:image:xxx/sidecar:latext#.(3)基础预热后的基础预热后的Pod扩容流程扩容流程/耗时：耗时：createcreateschedulescheduleattach/mountattach/mount volumevolumecnicni allotateallotatestartsta

47、rt sidecarsidecarpullpull imageimage forfor appappstartstart appapp终极组合拳：镜像预热+原地升级createcreateschedulescheduleattach/mountattach/mount volumevolumecnicni allotateallotatestartstart sidecarsidecarpullpull imageimage forfor appappstartstart appapp(1)基础预热后的基础预热后的Pod重建升级重建升级 流程流程/耗时：耗时：inplaceinplace up

48、dateupdatestartstart appapp(2)默认原地升级：默认原地升级：pullpull several several layers of imagelayers of image灰度分批发布灰度分批发布第一批第一批第二批第二批第三批第三批.正在灰度第一批正在灰度第一批Pod提前在后续批次提前在后续批次Pod的节点上预热即将发布的新版镜像的节点上预热即将发布的新版镜像(3)原地升级原地升级+镜像预热：镜像预热：(4)终态原地升级：终态原地升级：inplaceinplace updateupdatestartstart appappKubeMeetTHANK YOUTHANK

49、YOUO p e n K r u i s e 在 携程 的 应 用 实 践主讲人姓名：施燕携程 资深软件开发2021/04/17目录背景携程如何实现 K8s 云原生发布携程 PaaS 平台后续规划背景背景01背景部署模型 MileStone2015OpenStack 胖容器2016Mesos+Job2017K8s&PaaS 1.02019K8s&PaaS 2.0背景部署过程Group一组暴露同一服务的集合堡垒机Group 中第一台被发布测试的实例金丝雀Group 中第一台被发布验证的实例分批同一 Group 分成多个批次进行滚动部署拉入拉出Group 中某个实例是否接受流量和请求点火应用初始化

50、、预热、加载数据刹车当发布失败实例数量大于一定比例时停止发布回滚任何时间点可撤销，回到初态背景部署过程应用发布Group发布实例发布背景PaaS 1.0 经典部署模式不足虚机思维：先分资源再发布，限制扩容能力CMS 为中心化存储，多云场景实时性不足，无法满足快速变化场景K8s 只用来做资源调度，限制了发挥PaaS 需要负责实例的拉入拉出KubernetesPaaSDockerVMBMCDOSSLBCMS携程如何实现携程如何实现 K8s K8s 云原生发布云原生发布02携程如何实现 K8s 云原生发布PaaS 2.0 云原生部署模式DockerVMBMPaaSKubernetesRolloutS

51、LBOperatorCMSOperator私有云公有云核心：以 K8s 做为 PaaS 引擎改进：发布逻辑和中间件下沉 K8s，多云独立部署不再提前单独分配 IP，固定 IP 不支持跨宿主机漂移yaml 记录完整应用信息，由命令式改为声明式以 K8s 为元数据中心，适应更实时变化场景为 HPA/Serverless/Service Mesh 等云原生技术提供底座支持携程如何实现 K8s 云原生发布PaaS 2.0 云原生部署模式发布链路复杂，需要精确的状态校验与 K8s 交互频繁，流程控制与数据同步 解耦抽象出具有可扩展性的 工作流引擎操作皆可作为变更，细粒度拆分为 Step，过程用户透明，易

52、于排障变更支持在任意节点重试与回滚，降低用户试错成本携程如何实现 K8s 云原生发布基于 Kruise 的 Rollout 云原生发布方案 发布流程 Operator 化，下沉至 K8s 中间件 Operator 化，下沉至 K8s，简化发布流程 精确控制发布流程（堡垒，金丝雀，滚动）落地 Kruise 原地升级能力 同时支持无状态有状态发布无状态：28000+CloneSet有状态：200+StatefulSet携程如何实现 K8s 云原生发布基于 Kruise 的 Rollout 云原生发布方案 默认拉出，添加 finalizer Ready 且 Label in 拉入实例 实例删除时拉出

53、，拉出成功摘除 finalizer Not Ready 或 Label out 拉出实例携程如何实现 K8s 云原生发布Kruise 实践碰到的问题 scale panic when partition replicas map concurrent write maxUnavailable not work correctly current revision not correct client-go rest config not work inplace update lifecycle does not work correct support lifecycle hook for

54、AdvancedStatefulSet携程携程 PaaS PaaS 平台后续规划平台后续规划03携程 PaaS 平台后续规划控制面高可用 集群联邦目标 跨集群、跨 AZ 高可用 自动化容量管理挑战 发布涉及所有资源集群联邦改造 发布状态难以判断（zone、cluster）存量 Group 如何无损迁移到集群联邦携程 PaaS 平台后续规划控制面高可用 集群联邦目标 跨集群、跨 AZ 高可用 自动化容量管理挑战 发布涉及所有资源集群联邦改造 发布状态难以判断（zone、cluster）存量 Group 如何无损迁移到集群联邦携程 PaaS 平台后续规划Workload 对多状态实例管理现状 需要多余的一台机器资源消耗（虽可删除，但需要额外的成本）固定 IP 的集群无法删除堡垒 堡垒机和金丝雀机器不同导致一些系统无法灰度金丝雀，目前所有系统仅支持堡垒机标识 发布金丝雀比直接堡垒机拉入多出额外时间，对于小集群尤为明显目标堡垒机在堡垒发布用户确认后，能够将堡垒接入生产流量直接作为金丝雀使用携程 PaaS 平台后续规划Kruise 新特性落地 Pod 生命周期 hook:原地升级前执行拉出，原地升级后做流量拉入 安全防护：删除、更新、驱逐保护 原地升级与镜像预热结合