2021年阿里巴巴KubeMeet開發者沙龍會議PPT合集-云原生應用管理專場（98頁）.pdf

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:原地升級前執行拉出，原地升級后做流量拉入 安全防護：刪除、更新、驅逐保護 原地升級與鏡像預熱結合