多云环境下的应用管理与交付实践.pdf

《多云环境下的应用管理与交付实践.pdf》由会员分享，可在线阅读，更多相关《多云环境下的应用管理与交付实践.pdf（40页珍藏版）》请在三个皮匠报告上搜索。

1、多云环境下的应管理与交付实践郭耀星(雪尧)个简介郭耀星2017 年本科毕业于武汉学软件程专业，前就职于阿云计算平台数据基础程技术团队，从事运维平台的研发作，证了数据运维平台的持续迭代演进过程。主导了 ABM(数据运维平台 Apsara Big Data Manager)专有云产品/公共云服务由物理机到 on K8s 的转型，过程中也沉淀出了套多云环境下的云原应管理与交付的服务 AppManager 以及相对应的实践经验。技术专家录 多云环境应管理与交付痛点 理论先：OAM 多云环境交付实践 微服务/数据产品/SREWorks 开源社区 关键能实现与解析：AppManager(OAM Runti

2、me)多云环境应管理与交付痛点痛点 1 多云环境下的 K8s 底座适配问题由于在统底层基础架构细节的出表现，K8s 已经成为企业上云的事实基础。但单服务商的单 K8s 集群真的满需求么？常诉求：需要物理隔离，避免业务间相互影响需要混合云，避免受限于单云商，或降低成本需要应异地多活，避免单 Region 故障需要环境分离，区分开发测试与产环境需要定的集群扩展性，突破单集群容量上限痛点 1 多云环境下的 K8S 底座适配问题在纯粹的多集群视，有 Federation V1/Federation V2/OCM/Karmada 等解决案，或多个 kubeconfig 式更进步：如何在个分裂的常严重，位

3、于多个不同环境、不同络下的异构 K8s 底座下，效率的进应管理与交付？痛点 2 研发与运维的诉求冲突痛点 3 研发与运维的分冲突理论先：OAMOAM 模型-为什么会出现 OAM 开发者花费了太多的时间在基础设施的细节中 可扩展性低 云服务供应商绑定 团队膨胀后，研发/运维/平台员分与诉求冲突OAM 模型OAM（Open Application Model）是个标准的、基础设施关的跨云应部署模型-应为先。个应的交付与部署应该是包含的，其中的各类操作为应该作为应定义的部分，这些内容与实际基础设施关-清晰和可扩展性。定义套开放标准，可以模块化整个应交付流程，根据个需要将这些模块由组装，达成想要的结果

4、-云服务供应商关。定义的开放标准应该是套更级别的抽象，可以跨本地集群、跨云服务供应商，不会被锁定到任何个商的底座OAM 模型 概念Workload：作负载类型。般由云服务供应商提供 Workload，如 K8s 原 Workload Component：Component 代表了个运单元，是于定义应的基本组件，其中包含了对 Workload 的引，个 Component 中只能包含个 WorkloadTrait:Trait 于定义 Component 的运维属性，是对 Workload 运时的叠加Application:将 Component 和 Trait 组合成完整的应的配置。Compon

5、ent 每部署次就会产个组件实例(ComponentInstance)，实例是可以被升级的（or 回滚），每次部署或升级就会产个新的发布（Release）OAM 模型 概念(v0.3.1 Draft 新增)Policy:应执策略。负责定义应级别的部署特征。应策略的扩展性和功能与运维特征类似，可以灵活的扩展和对接所有云原应命周期管理的能。相对于运维特征，应策略作于个应的整体，运维特征作于应中的某个组件(v0.3.1 Draft 新增)Workflow:定义了从部署开始到达到部署终态的条完整路径。Runtime 实现需要按这个流线执作流中定义的各个步骤来完成整个应交付。除了常规的组件依赖编排、数据

6、流传递等功能，还需要持向多环境/多集群的部署过程与策略描述关注点分离应开发员：负责组件 Component 的定义应运维员：?定义适于不同 Workload 的运维属性 Trait 和管理应层的 Policy?将应开发员定义好的 Component 与运维属性 Trait 绑定在起，辅以 Policy+Workflow，成 Application，提交到 Runtime 实现，维护应程序的命周期基础设施运维员：提供不同的 Workload 类型多云交付实践多云环境交付实践 我们的业务场景 专有云：将 ABM 交付到各个客户现场环境中，依赖统的阿专有云 K8s 底座。部分的客户环境是络隔离的，不