《多云环境下的应用管理与交付实践.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 底座。部分的客户环境是络隔离的,不
7、出差到现场的情况下,只能拍照来回解决问题 公共云:交付各个阿数据产品到公共云 ACK 集群上(资源集群 or 业务集群),多 Region,为云上客户提供服务 集团内部:部署各个数据产品到集团内部 K8S 集群上,多 Region,为集团内部各业务提供服务;另外还需要将我们身交付到 OXS(阿云内核区域)K8s 公共集群中(权限受限)开源社区:交付 SREWorks 到各类户建的集群下 or 各商公共云多云环境交付实践 产品形态多云环境交付实践 微服务多云环境交付实践 数据产品多云环境交付实践 SREWorks 开源社区https:/ 通过抽象通运维模型:实现五核价值场景 撑“质量、成本、效率
8、、安全”的运维需求 提供“交、监、管、控、营、服”全命周期能撑多云环境交付实践 SREWorks 开源社区https:/ 统管控案关键能实现与解析:AppManager(OAM Runtime)AppManager(OAM Runtime)因数据侧业务诉求,注重扩展能(基于Groovy)、络隔离环境交付、资源管理、版本管理AppManager 扩展能AppManager 扩展能 插件包AppManager 构建打包AppManager 应部署 整体介绍整个 ApplicationConfiguration Yaml 完整定义了个 应部署的模型,描述了个应应如何可靠灵活的交付到标环境中组件(Co
9、mponent/Addon)、运维能(Trait)为 向终态设计应执策略(Policy)、作流(Workflow)为 向过程设计部署层级关系:1 Workflow-N Applications1 Application-N Components1 Component-N TraitsAppManager 应部署 TraitAppManager 应部署 组件AppManager 应部署 应&组件&Trait 间依赖关系AppManager 应部署 应&组件&Trait 间依赖关系AppManager 应部署-WorkflowWorkflow 可包含多个 Step,执顺序可顺次,也可并发(data
10、Inputs/dataOutputs 依赖)Workflow Step 均由 Groovy 脚本实现Workflow Step Groovy 脚本中,可配合 Policy 对 Application 进次修改并提交部署Workflow 执过程中可以有更多的控制及介,如暂停、恢复、设置上下等,在灰度发布场景、涉及回滚动作的时候尤其有Workflow Step 可以继续产出 Workflow,实现复杂场景套娃效果AppManager 资源管理(Addon)Addon 资源共享与隔离:Namespace 间隔离,Namespace 内共享AppManager 多环境持UnitClusterNames
11、paceStageUnit(单元):单元间络隔离。每个单元需要个 AppManager 实例进管控。个单元可包括多个 ClusterCluster(集群):个独 K8s 集群,集群间络可达。集群直接注册 kubeconfig 到当前单元下的 AppManager 即可使Namespace(命名空间):对应 K8S 的 Namespace 概念,于个 Cluster 下的资源及应的隔离,个 Namespace 对应了个信息孤岛Stage(阶段/环境):个 Namespace 可包含多个 Stage,每个 Stage 共享了当前 Namespace 下的所有资源AppManager 应状态感知Ap
12、plication InstanceComponent Instance AComponent Instance BComponent Instance CRUNNINGRUNNINGE R R O RE R R O REvents:Insufficient CPU.AppManager 应状态感知 WatchAppManager 应状态感知 PullUserCustomCronHandler(Groovy)+get(request)UserComponent(Groovy)+buildScriptName()+deployScriptName()+destroyScriptName()+wa
13、tchKind()=return CRON+watchScriptName()=return UserCustomCronHandlerComponentHandler+buildScriptName()+deployScriptName()+destroyScriptName()+watchKind()+watchScriptName()Component InstanceComponentWatchCronHandler+get(request)RUNNINGComponentWatchCronManager+refresh5s()+refresh10s()+refresh30s()+re
14、fresh1m()+refresh2m()+refresh3m()+refresh4m()+refresh5m()-refresh(items)*5min?5s?*515min?10s?*1545min?30s?*45min1h45min?60s?*1h45min3h45min?2m?*3h45min6h45min?3m?*6h45min10h45min?4m?*10h45min?5m?RUNNING?5s?5m?总结&展望SREWorks 作为阿云数据SRE团队对SRE理念的程实践提供云原场景的企业应&资源管理及运维开发两核能Github:https:/ 项官:https:/ 我们是数据基础程团队我们专注于超规模集群的效稳定运我们期待与你交流阿智能运维 SREWorks