基于OAM和Kubernetes构建开放Serverless平台

1、基于OAM和Kubernetes构建开放 Serverless 平台技术创新，变革未来大纲为什么我们需要 Serverless？当前社区的 Serverless 框架介绍Serverless 方案落地遇到的挑战基于 OAM 和 Kubernetes 构建开放 Serverless 平台1.为什么我们需要 Serverless？Why Serverless为什么我们需要 Serverless？以开发者为中心：零运维/轻运维；无需关心基础设施；门槛低。极致弹性：快速扩缩容；无限资源池；缩容到0。低成本：按量付费，按服务负载扩缩容。快速使用：部署和更新非常简单；灰度和流量管理。ServerlessB

2、aaSFaaSResource Pool为什么阿里基于 Kubernetes 构建 Serverless？阿里基于 Kubernetes 的无限资源池与基础设施能力大规模 单集群最高可达 10000 节点、百万 Pod高性能 秒级扩容，智能伸缩，神龙 + 安全容器极致弹性 分钟级拆借公有云计算资源，无限资源池2. 社区围绕 Kubernetes 已经具备的 Serverless 基础功能：Istio（流量治理）OpenFaaS（FaaS 能力）, Knative ServingKEDA , Eventing（事件驱动、弹性）Argo , Teckton（工作流）必要 条件2.当前社区 Serv

3、erless 框架介绍Serverless SolutionsKubernetes + KnativeEventing：完备的事件模型（注册、订 阅、外部事件系统接入等）Building：从源码到镜像的构建Serving：版本管理与灰度Service对应用 Serverless 编排的抽象，通过 Service 管理应用的生命周期Configuration当前期望状态的配置。每次更新 Service 就会更新 ConfigurationRevisionService 的每次更新都会创建一个快照，一个快照就是一个车 RevisionRoute将请求路由到 Revision，并可以向不同的 Rev

4、ision 转发不同比例的流量Knative Serving 资源模型Kubernetes Resource PoolKubernetes + OpenFaaSKubernetes Resource PoolFunction CRFunction 的 CR 中包含了所有 Function 需要的信息（镜像、实例 数、策略等）3. Serverless 方案落地遇到的挑战Serverless Challenges云服务对接缺失云服务需要用户单独手动购买，体验割裂扩展和接入新的云服务能力困难/不自然手动购买和配 置 OSS配置 Serverless 及 RDS、OSS信 息手动购买和配 置 SLB

5、手动购买和配 置 RDS上线成功Knative Gateway自动生成子域名开源生态对接缺失Knative 和 OpenFaaS 的模型均无法直接对接 K8s 社区大量的OperatorMysql OperatorMongoDB Operator数据库编排/依赖管理MinIO Operator存储Ceph Operator安全Vault OperatorFalco Operator发布一切皆 Annotation扩展能力缺失，过度使用 annotation这些零散的运维能力如何治理?冲突关系如何判定？如何让用户知道新增的能力？如何描述能力的作用？应用描述与运维属性耦合Knative 修改扩缩容

6、参数会触发新建 Revision（需要重新部署生效）KnativeRevisionRevisionServiceRouteConfiguration修改产生新的Revision重新灰度才生效Issues： #6717官方理念：Revision（应用描述）是 immutable 的。但是：Scale （运维属性）描述作为annotation混杂在Revision中运维属性不应该是 immutable 的。Workload 锁定OpenFaaS 限定了只能使用 Function 模型； Knative 限定了只能 使用Service 模型。ECSKataContainerOpenKruiseFaa

7、S真实的场景下：应用需要迁移过度复杂应用需要自定义模型满足安全场景下需要自定义运行时Apps Apps不适合直面最终用户是编程框架想要扩展能力只能侵入到原有实现OpenFaaS all-in-one 的定义Knative 大量 annotation总结：为什么当前 Serverless/FaaS 落地困难？基础设施能力不具备： 可以通过 Kubernetes（基础设施抽象） 和 云（资源池）解决。能力封闭：当前 Serverless/FaaS 实现的能力层是封闭的；基于 K8s 的解决方案，封装了 K8s ，丢失了开放能力；没有可扩展性和可定制性；仅在有限场景可用，没有覆盖主流场景。4.基于

8、OAM 和 Kubernetes 构建 开放 Serverless 平台Open Application Model什么是 OAM?“以应用为中心”的上层抽象ApplicationComponentWorkloadApplicationConfigurationTraitScope从 应用 和 应用配置 两个维度，为平台构建者提供了一个基于 K8s 定义 应用层抽象的标准化规范OAM 层Workload InstanceDeploymentKnativeKruiseTraffic RolloutManuel Scalertrait影响（旁路控制）应用描述运维属性具体实现ComponentCom

9、ponent BCComponent DComponentapiVersion: serving.knative.dev/v1 kind: ConfigurationComponent AComponent工作负载组件：完全从研发视角定义的应用模块工作负载：应用模块的具体描述“我要运行什么？”Knative ServiceComponentComponent BCComponent DComponentapiVersion: /v1 kind: FunctionComponent AComponent工作负载组件：完全从研发视角定义的应用模块工作负载：应用模块的具体描述“我要运行什么？” Op

10、enFaaSComponentComponent BCComponent D在 OAM 中，云服务实例也通过组件进行 定义Component# a redis instance provided by aws operator apiVersion: service-operator.ros/v1alpha2 kind: ElastiCacheComponent AComponent云资源纳入到统一定义中。工作负载Application ConfigurationApplicationConfigurationcomponents:#web service-componentName:web-

11、service#redis-componentName:redisApplication ConfigurationComponent BComponent CComponent DComponent A多组件组合，构成最简单的应用ApplicationConfigurationcomponents:- componentName: web-server traits:- trait:apiVersion: networking.knative.dev/v1 kind: Routespec:traffic:- configurationName: webapp latestRevision:

12、true percent: 100- componentName: redisApplicationApplication ConfigurationComponent BTraitsComponent CTraitsComponent DTraitsComponent ATraits特征：TraitTrait 和 Workload 都拥有高度可扩展性。一个组件所需的运维策略与配置 应用 = 组件 + 特征如：helloworld app =云Redis + Knative Configuration + Knative Route应用 = 组件 + 特征 + 边界ApplicationCon

13、figuration- apiVersion: /v1 kind: HPAspec:minReplicas: 1maxReplicas: 10targetCPUUtilizationPercentage: 30- apiVersion: /v1 kind: Ingressspec:hostname: path: /service_port: 8001scopes:- scope:apiVersion: core.oam.dev/v1alpha2 kind: Networkname: my-vpc-network-X-: redisscopes:- scope:apiVersion: core.

14、oam.dev/v1alpha2 kind: Networkname: my-vpc-network-XApplicationIdentity Scope YNetwork Scope XApplication ConfigurationComponent BTraitComponent CTraitComponent DTraitComponent ATraitOAM 应用灵活扩展、纳入 K8s 生态已有能力apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: helloworld sp

15、ec:components:# web server- componentName: web traits:- trait:apiVersion: /v1 kind: Ingressspec:hostname: path: /service_port: 8001apiVersion: core.oam.dev/v1alpha2 kind: Componentmetadata:name: web-server spec:workload:apiVersion: core.oam.dev/v1alpha2 kind: ContainerizedWorkload spec:containers:na

16、me: frontendimage: frontend:latest env:name: OAM_TEXTUREvalue: texture.jpg ports:containerPort: 8001 name: http protocol: TCPComponentWorkloadTraitsTraitK8s Custom Resource objectK8s Custom Resource objectOAM 模型下的KnativeComponentRevisionRevisionRevisionApplicationConfigurationRoute TraitKnative Rout

17、eWorkload (Knative Configuration)框架解决依赖编排与参数传递Redis ComponentWeb ComponentTrait CTrait D启动Redis启动完成后才启动ComponentApplicationConfigurationRoute TraitScaling TraitWorkload运维属性从 Annotation 解耦Scaling 设置的问题迎刃而解HPA可发现、可管理的 Traits 系统apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:n

18、ame: helloworld spec:components:- componentName: frontend traits:- trait:apiVersion: scaling.A/v1 kind: CronHPAspec:timezone: “America/Log_Angeles”schedule: “0 0 06 * * ?”cpu: 50- trait:apiVersion: core.oam.dev/v1 kind: HPAspec:minimum: 1maximum: 9发现OAM runtime 控制器保证 Trait 之间的兼容性apiVersion: core.oam.dev/v1alpha2 kind: TraitDefinitionmetadata:name: cron-scaler annotations:version: v0.3.0 spec:conflictLabel： hpa: cronappliesTo:- core.oam.dev/v1alpha1.Server definitionRef:name: $ kubectl get traitDefinitions NAMEAGEcron-scaler19mauto-scaler10mOAM Kubernetes RuntimeTraits流量管理发布弹