带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(四)-阿里云开发者社区

开发者社区> 电子工业出版社> 正文
登录阅读全文

带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(四)

简介: 《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(四)

3.6.3 实现技术

与社区开源的Kubernetes 相比,阿里云Kubernetes 服务除了提供便捷的安装、升级及轻松地实现 Kubernetes 集群的扩容和缩容等管理功能,还提供了更为强大的功能,其相关实现组件如图3-78 所示。

…… 

image.png

图 3-78  Kubernetes 相关实现组件

1. 自研网络插件

以网络插件为例,围绕Kubernetes 实现的CNI 插件种类丰富、数量繁多。而如何选择一款稳定、高性能,并能支持流量控制、网络策略等高级特性的网络插件, 对于Kubernetes 的网络运行至关重要。以阿里云容器服务的Terway 插件为例,它遵从业界的CNI 设计方式,针对阿里云VPC 网络进行了优化,在Kubernetes 场景下使用,支持网络策略,可以实现Pod 之间的访问隔离。同时,通过在Pod 上声明annotation: k8s.aliyun.com/ingress-bandwidth 和k8s.aliyun.com/egress-bandwidth 可以限制Pod 的入网和出网带宽。

按照部署和调用方式划分,Terway 包含Daemon 和Binary 两部分,如图3-79 所示。

image.png


图 3-79  网络插件Terway 

Daemon: 供Binary 调用,分配和管理网络资源。

Binary: 与Kubelet 交互及Daemon 交互,配置Pod 的网络连接


Kubelet 监听到Pod 创建在自己的节点上时, 会通过容器运行时创建Sandbox 容器,然后通过cni 调用Terway Binary 来处理网络命名空间,Terway Binary 调用Terway Daemon 来获取网络资源,Terway Daemon 调用Aliyun Open API 分配网络资源并返回给Terway Binary,最后Terway Binary 为容器的网络命名空间配置网络和联通网络。

Serverless Kubernetes 的实现依赖弹性容器实例ECI 和Virtual Kubelet。

2. 弹性容器实例ECI 技术实现

弹性容器实例ECI 提供面向云原生的免运维容器组(Pod)资源交付。用户只需要提供容器镜像,指定ECI 实例规格,即可运行容器实例,无须关心容器运行在哪台物理服务器上。

作为弹性计算的“一等公民”,ECI 充分发挥底层的计算、网络、存储能力,不仅在资源上与ECS 复用整个阿里云弹性计算资源池,还复用了阿里云网络的基础设施,ECI 和ECS 可以在同一个VPC 内,中间没有虚拟网关的转发开销。ECI 也复用了阿里云存储的基础设施,基于ESSD 的系统盘和数据盘最高可以支持100 万的随机读写IOPS,稳定性和读写带宽都有充分的保障。

资源复用技术

这样做的好处是大幅提升调度的弹性深度。用户直观的感受就是,创建 ECI 的时候除了可以单独指定 CPU、存储容量进行灵活搭配,还可以直接通过 ECS 实例的

规格指定 ECI 的规格,ECI 与 ECS 的资源复用技术,ECI 与 ECS 的资源复用技术如图 3-80 所示。

除了库存的复用,单台物理服务器还支持 ECS/ECI 混合部署,结合新的库存调度算法,提高单台物理机的资源利用率,降低 ECI 甚至整个弹性计算的成本。ECI 目前支持远比 ECS 更小的规格,这在一定程度上可以弥补目前物理机调度的资源碎片的缺陷。

ECI 的成本

ECI 的成本主要包含ECI 实例、网络和存储的使用费用。ECI 实例能够支持两种资源申请和计费模式。

模式一:根据 CPU/ 内存进行资源申请和计费。ECI 会利用 ECS 多个规格族的库存,保障资源的交付。例如:2C4G,会尝试使用 ECS 的 ecs.c6.large、ecs.sn1ne. large、ecs.se1ne.large 等规格进行资源的交付。

模式二:根据 ECS 规格进行资源申请和计费,价格参考各地域 ECS 按量价格, 用户可以根据需要指定 ECS 规格族来使用各规格族的指定能力,例如:指定使用 ecs. sn1ne 规格族,来使用网络增强能力。网络的使用费用主要包括VPC 网络中的负载均衡设备、弹性公网IP、privateZone 等费用;存储的使用费用主要包括NAS、OSS、EBS 快照等的使用费用。

ECI 和ECS 最大的不同就在于ECI 是按量秒级计费的,而不是ECS 常用的包年包月形式。ECI 只会收取用户从开始拉取业务镜像,到实例状态从Running 变成Succeed 或者Failed 之间的费用。ECI 与ECS 如图3-81 所示,用一个2C4G 的实例来说明,如果每天业务运行的时间正好是14 个小时的话,那么ECI 按量付费的成本和ECS 包月的成本是持平的。如果业务每天运行的时间小于14 个小时,那么按量的ECI 成本会比包月的ECS 更低。

除了帮助用户降低显性的使用成本,ECI 还能帮助用户降低隐性成本。Serverless 容器不向用户收取机器的资源成本,而直接按应用消耗的资源来收费。Serverless Kubernetes 提供了开箱即用的容器服务,大大降低了环境部署成本和时间, 同时阿里云在官网上提供了大量的帮助文档和最佳实践,大大降低了开发人员的使用门槛。

image.png


ECI 的启动速度

ECI 的弹性能力在很大程度上取决于ECI 并发创建时的启动速度,因此优化ECI

实例的并发启动速度非常关键。

这里以Nginx 容器的端到端的创建时间(如图3-82 所示)为例,除去实例启动占到的7% 的时间,资源调度的时间占到了43%,而镜像拉取的时间占到了50%。

image.png

图 3-82  Nginx 容器端到端创建时间分析

容器在每次启动时,都会检查本地是否有相应的镜像,如果不存在,则会从远端的容器镜像仓库拉取镜像。在阿里云上的容器实例是运行在阿里云的安全沙箱内的,实例每次重建时都会销毁整个安全沙箱,其中也包括了已缓存到本地的镜像, 这就导致容器重建后依然会拉取镜像。为了减少拉取时间,业界主要有以下三种优化方法。

第一种方法是在所有的计算节点上都缓存基础镜像层,比如centos、ubuntu 等, 如果本地存储资源足够,还可以缓存部分常用的业务镜像。

第二种方法是采取P2P 传输的方式,从多台物理机并行拉取业务镜像的不同层,已缓存该业务镜像的物理机越多,并行拉取镜像的效率越高。

第三种方法是把系统盘和数据盘保存至分布式存储系统,借助存储系统的快照技术,在启动容器时,将快照克隆出的云盘动态挂载到容器中去。


经过大量的优化,目前ECI 启动时已经不需要从远端的容器镜像仓库拉取镜像, 并发创建实例的并行效率提升了数十倍。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: