大淘宝技术开放平台，是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。
聚石塔在淘宝天猫算是一个“古董级”技术平台，从诞生之初就承载了支持淘宝开放生态的使命。历经几代技术变革走到现在。
在2019年我们做了对三方开发生态的“云原生化”之后，基本上大部分电商生态ISV的主要业务系统都完成了云原生化，每个isv会自己保有若干个ACK集群，聚石塔的职责是帮助ISV来运维集群，并且基于k8s的能力搭建了一套应用运维PaaS，解决应用的CICD，监控运维，安全管控等问题。这套模式在电商场景下得到了比较好的验证，借助云原生标准化以及繁荣的云原生生态，帮助电商ISV完成了技术架构升级，平台侧则借此机会完成了应用架构标准化以及稳定性保障能力的提升。目前聚石塔容器集群的日常总规模已经达到万核的规模。
也是从19年开始，淘宝小程序生态开始蓬勃发展，越来越多的三方开发者涌入到开放平台，为千牛和手淘的商家以及消费者服务。这些生态的系统也都统一落在了聚石塔的容器PaaS上，随之而来也诞生了新的问题。
▐ 中小型开发者的第一座山
相比于传统电商类ISV，小程序ISV的体量要小很多，应用架构也要简单很多。通常1-2个应用就能完成一个小程序所需的所有功能。「容器集群+应用」的模式对于此类小型应用的开发者显得过于复杂，学习成本也太高，同时还会带来资源浪费的问题。对那些没有聚石塔基础以及云基础的开发者而言尤其严重，就好像打开淘宝开放平台大门之后看到了一座高山，还需要学习相关技术，付出精力勇攀高峰。
应用&集群创建的复杂度
一个云应用入驻小程序，通常的初始化路径：
申请开放平台应用 --> 聚石塔购买ECS资源 --> 聚石塔创建集群&初始化 --> 聚石塔创建并部署应用 --> 聚石塔购买SLB --> 应用关联至小程序云网关
对一个熟练的开发者，整个过程的时间统计如下：
购买ECS |
集群创建&初始化 |
创建并部署应用 |
购买配置SLB |
应用关联云网关 |
总时长 |
分钟级 |
小时级 |
小时级 |
分钟级 |
小时级 |
65min |
对于不熟悉平台的开发者，时间会更长，学习云基础设施、熟悉整个运维框架需要大概3-7天时间。
额外的成本付出
在小程序业务场景中，大部分的k8s集群都属于规模小于50核的小集群。
对于50核的集群（6个8核16G的ECS）而言，会被集群管控组件占用掉3.5核10G的资源；对于20核的集群（5台4核8G的ECS），会被集群组件占用掉3核8.5G的资源；集群估摸越小，用户实际可用资源越少，业务成本越高。
据统计，大部分小程序开发者集群规模都比较小，需要付出相当比例（1/10~1/5）的成本用于集群系统组件开销。
同时，开发者还面临大促运维困难（需要提前扩容，准备多可用区资源），日常集群组件运维复杂等问题。
▐ 平台开放的桎梏
在传统电商场景中，聚石塔已经定义了一套非常完整的开放标准方案。既让传统电商开发者“入塔”：服务商可以通过“入塔”把服务部署在聚石塔的IaaS或应用PaaS上，以获得更好的业务系统稳定性和业务数据安全保障，进而更好的服务淘宝的商家和消费者。
但是小程序生态场景则更加丰富，有更多垂直业务场景，比如涉及敏感数据的聊天语料场景，以及基本不涉及敏感数据的小游戏场景。更细分的业务场景，如果都统一使用老一套的管控标准明显是不合适的。那么如何面向不同的垂直业务场景，不同规模的三方应用，开放不同粒度的管控方案，也是聚石塔接下来需要解决的重要命题。
解决垂直业务场景平台业务开放标准的问题，解开平台业务开放的桎梏。
▐ 不能让入驻聚石塔成为业务的卡点
技术实现
-
计算资源托管，即计算容器的托管；使用ASI（k8s）集群运维管理资源； -
应用依赖的云资源（数据库、中间件）的托管；由平台管理各资源的购买，使用，以及运维。
-
ASI集群VPC：实际是公有云的云上VPC。内部包含开发者部署的应用，业务组件Addon应用，以及集群中的管控组件和集群运行必备组件； -
租户托管VPC：平台为开发者单独分配的VPC，开发者对此VPC无感知。该VPC的主要作用是用户资源的隔离，以及用户云资源归属托管。 -
阿里集团内网：集团内网内部署平台的管控应用以及对用户透出的控制台应用，通过网络打通的方式下发指令到ASI集群中。 -
小程序云网关：云网关用于连接手淘端流量，并通过跨网技术将流量下发到托管集群的用户应用pod中。
-
如何在集群中隔离多租户的应用和容器； -
如何在隔离的同时实现单租户的应用与资源网络通信，实现平台面向不同业务场景的网络管控； -
Serverless场景下的应用自动弹性伸缩方案；
▐ 多租计算隔离模型
我们在初期选择底层容器技术方案的时候，考虑了多种不同的容器集群托管方案，包括ACK，自建，以及阿里云ASI。后面考虑到面向二方业务的能力完备性，选择了ASI作为底层k8s托管方案。
而聚石塔并没有直接使用ASI的多租集群方案，而是使用ASI的单租集群，由聚石塔作为统一租户对集群进行整体管理，以及不同开发者（租户）在集群内的资源分割。
RunD容器构建在神龙裸金属服务器之上，租户容器的分配其实是和交换机挂钩的，在后面网络通信与管控的部分会详细介绍租户容器网络的分配规则。
▐ 网络通信与管控
网络通信与管控，主要需要解决两个方面的需求：
为pod分配网络，实现应用网络通信；
面向多业务场景，实现分级的网络管控；
通过Pod挂载多ENI分割业务管控流量和用户流量
从应用视角来看，我们可以把流量分为两种类型：
平台业务管控流量，比如从前台云网关导入的业务流量（南北流量）
用户应用内部流量，比如同租户应用间的流量访问，或应用与rds之前的访问流量（东西流量）
结合跨VPC双向通信的需求，我们选择了pod挂载多ENI网卡的方案。利用ENI网卡的跨租户挂载实现不同租户VPC的互通，利用ENI的边缘交换机来管理网络的通达。
租户间网络隔离
上面提到了每个pod都会挂两个eni网卡，一个是管控网卡，用于平台业务流量导入；一个是用户网卡，用于与用户独占的托管vpc通信。那如何解决多租户应用间的管控网卡隔离问题？（不需要考虑用户网卡的隔离，因为天然就是通过vpc隔离的）
共享交换机+安全组的方案，是多个租户共享一个交换机分配pod ip；这时候为了避免不同租户间的pod互访，需要将所有pod加入到一个统一的企业安全组内，利用企业安全组内成员默认不能互访的能力，隔离pod间互访。
实际上，这个方式是隔离了所有集群内的pod互访，包括同租户的pod互访；同租户的pod互访需要通过用户eni网卡来实现。
而由于kcm，kube-proxy的默认规则，k8s service选择ip的时候会默认选择eth0网卡ip，导致k8s service无法使用。想要突破该限制的方案会相对复杂，需要自己定制k8s的endpointController来实现service的realServer动态挂载，同时通过宿主机的路由和iptables定制实现网络包从正确的网络出口出去。
面向多业务场景的网络管控方案
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
由于有双网卡的便利性，我们可以将用户自己的流量封闭在用户eni网卡内，进而通过控制用户eni所在vpc的交换机和安全组来控制网络流量。
比如在封闭环境中，我们在用户eni网卡的安全组规则定制了禁止所有公网出入的规则，直接可以封闭用户应用的公网出入访问；而在开放环境中，我们并不会针对网络做特殊的管控和定制，用户甚至可以将自己的应用挂载slb对外提供服务。
▐ 应用稳定性银弹 —— 自动弹缩
提到Serverless方案，那不得不提的就是自动弹缩。应用自动弹缩是平衡应用稳定性与应用成本的利器。同样的，在聚石塔云托管环境中，云托管支持基于容器指标的自动弹性伸缩，比如CPU、内存水位；同时我们也支持基于业务水位的弹性伸缩，比如基于小程序云网关流量的弹性。
其中基于CPU内存水位使用了k8s原生的metric server作为数据源，提供给标准的HPA服务根据相应的算法计算做种做出弹性的决策；
官方的数据源和HPA都无法很好支持类似自定义业务指标类型的弹性，所以我们引入了KEDA作为弹性伸缩的前置决策工具，通过 KEDA 我们可以根据需要处理的事件数量来驱动 Kubernetes 中任何容器的扩展；同时我们定义了专用的数据采集器jst-externalscaler用于自定义业务指标数据的采集。
通过官方HPA+KEDA的扩展组合，最终实现了云托管的应用pod自动弹性基础设施。
本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
