作者|李毅阿里云高级技术专家关注“阿里云原生”公众号，回复关键字“转型”即可下载本PPT。今天和大家分享的话题是《拐点已至，云原生引领数字化转型升级》。首先让我做一个简短的自我介绍。我叫易立，来自阿里云容器平台。2015年开始负责阿里云容器产品，之前在IBM工作14年，主要负责企业中间件和云计算的产品研发。今天和大家分享一下我们对云原生领域的简单思考，以及我们对云原生发展的四大趋势的总体介绍：拥抱Serverless——极致弹性，无需运维；服务网格——将服务治理能力从应用中解耦，并下沉到基础设施层；云原生应用管理标准化——构建高效、自动化、可靠的应用交付系统；计算无边界——实现云边物联网设备的高效协同。云原生的基本概念首先简单介绍一下云原生的一些基本概念。我们联系了很多客户。对于这些客户来说，上不上云都不是问题。他们关心的是如何接入云端？如何充分利用云的能力，实现云的价值最大化？AllinCloud时代，企业的技术能力成为核心竞争力，非常愿意将云作为企业IT能力的倍增器。云原生计算是一组最佳实践和方法。在公共云和私有云环境中，可以构建可扩展、健壮和松散耦合的应用程序，以实现更快的创新和低成本的试错；容器、服务网格、无服务器计算等新的计算范式不断涌现。容器拉开了云原生技术的序幕：Docker镜像形成了应用分发和交付的标准，可以将应用与底层运行环境解耦；Kubernetes技术已经成为分布式资源调度和编排的标准，Kubernetes屏蔽了底层基础设施架构的差异，帮助应用运行在不同的基础设施上；在此基础上，社区开始构建上层应用抽象。比如在服务治理层，Istio成为服务通信的网络协议栈，将服务治理能力与应用层解耦。在此之上，面向领域的云原生框架也在迅速涌现，比如面向机器学习的云原生平台Kubeflow、面向serverless的Knative等。通过这样的分层架构，开发者只需要关注自己的业务逻辑，不需要关注底层实现的复杂度。我们可以看到，一个云原生操作系统的雏形已经开始出现。这是开发者最好的时代，大大提高了业务创新的速度。早期的Kubernetes主要运行无状态的Web应用，比如基于ApacheDubbo/SpringCloud的微服务应用。现在，越来越多的企业核心业务、数据智能业务、创新业务也在运行在Kubernetes上。以阿里云自有云产品为例，企业级分布式应用服务EDAS、实时计算平台Flink、弹性AI算法服务EAS、区块链平台BaaS等也都部署在阿里云的Kubernetes服务ACK上。K8s已经成为云时代的操作系统，成为应用程序使用云基础设施能力的接口。阿里云ACK实现云基础设施的优化整合，提供敏捷、灵活、可移植的云原生应用平台；能够在公有云、私有云、边缘云上实现应用的统一部署和管理。从Container到ServerlessKubernetes我们来谈谈Kubernetes的Serverless演进。每个人都喜欢K8s提供的强大功能和灵活性，但操作和维护Kubernetes生产集群极具挑战性。阿里云的Kubernetes服务ACK简化了K8s集群的生命周期管理，托管了集群的主节点。但是用户仍然需要维护worker节点资源池和维护节点，比如升级安全补丁等，并根据自己的使用情况对资源层进行容量规划。针对K8s复杂的运维挑战，阿里云推出ServerlessKubernetes容器服务ASK，全面兼容现有K8s容器应用，但所有容器基础设施都由阿里云托管，让用户专注于自己的应用.它有几个特点：第一，用户没有任何预留资源，按容器应用实际消耗的资源付费；用户无节点概念，零维护；所有资源都是按需创建的，没有任何容量规划。ServerlessKubernetes大大降低了运维的复杂度，其自身的设计非常适合突发应用负载，比如CI/CD、批计算等。例如，对于一个典型的在线教育客户，教学应用根据教学需求按需部署，课程结束后自动释放资源，整体计算成本仅为包月节点的1/3。Cloud-scaleNodeless架构——Viking是如何实现的？2017年底，当我们启动ServerlessKubernetes项目时，我们一直在思考：如果Kubernetes诞生在云端，它的架构应该如何设计？我们将其内部产品代号为Viking，因为古代维京战舰以速度快、操控方便着称。首先，我们要与Kubernetes兼容。用户可以直接使用Kubernetes的声明式API，兼容Kubernetes的应用定义。Deployment、StatefulSet、Job、Service等不需要修改。其次，Kubernetes底层充分利用了云基础设施服务和云服务的计算、存储、网络、资源调度等能力；从根本上简化了容器平台的设计，增加了规模，降低了用户运维的复杂度。我们遵循Kubernetescontroller设计模式来驱动整个IaaS资源的状态不断逼近用户应用声明的状态。我们在资源层提供ElasticContainerInstance-ECI。与Azure容器实例ACI、AWSFargate不同，ECI提供对KubernetesPod的原生支持，而不是提供单独的容器实例。ECI提供基于轻量级虚拟机的沙箱环境实现安全隔离，完全兼容Pod语义，支持多容器进程、健康检查和启动顺序。这使得在上层构建K8s兼容层变得非常简单和直接。在编排调度层，我们使用微软的Virtual-Kubelet，并对其进行深度扩展。Virtual-Kubelet提供了一个抽象的控制器模型来模拟Kubernetes节点。当一个pod被调度到一个虚拟节点上时，controller使用ECI服务创建一个ECI实例来运行这个pod。同时控制器支持双向状态同步。如果正在运行的ECI实例被删除，控制器将根据应用目标状态恢复一个新的ECI实例。同时，基于阿里云的云服务，我们实现了Kube-Proxy、Kube-DNS、IngressController的行为，提供完整的KubernetesService能力支持：例如使用阿里云的DNS服务PrivateZone动态配置ECI实例的DNS地址解析，支持HeadlessService；通过内网SLB提供集群IP，提供负载均衡能力；入口路由规则是通过负载均衡提供的七层路由来实现的。我们还为ECI提供了端到端的可观察性能力，并与阿里云日志服务、云监控等服务深度集成，可以轻松支持HPA水平扩展。容器启动加速——“零秒”镜像下载对于Serverless容器技术来说，应用启动速度是一个核心指标。容器对应用启动速度的影响主要在于：资源准备：ECI通过端到端控制环节的优化，以及容器场景虚拟化和操作系统的剪裁优化，将资源准备时间优化到秒级等级;图像下载时间：从Docker注册表下载图像并在本地解压缩是一项非常耗时的操作。下载时间取决于图像大小，通常从30秒到几分钟不等。传统Kubernetes中，worker节点会将下载的镜像缓存在本地，这样下次启动时不会重复下载和解压。为了实现极致的弹性和成本效率，ECI和ECS采用了池化策略，计算和存储分离的架构，这也意味着我们不可能以传统方式使用本地磁盘来缓存容器镜像。为此，我们实现了一个创新的解决方案：容器镜像可以做成数据盘快照。ECI启动时，如果镜像快照存在，可以直接根据快照创建只读数据盘，实例启动时自动挂载。容器应用可以直接使用挂载的数据盘作为rootfs启动。基于盘古2.0架构和阿里云ESSD云盘极致的I/O性能，我们可以将图片加载时间缩短到1秒以内。为了简化用户操作，我们在K8s中提供了CRD，让用户可以指定哪些镜像需要构建镜像快照。同时，在ACR镜像仓库服务的软件交付管道上，我们可以声明哪些镜像需要加速，这样当用户推送新镜像时，会自动构建对应的快照缓存。终极弹性让我们谈谈弹性。对于绝大多数企业来说，弹性是上云最重要的需求。双11是典型的脉冲计算，峰值计算资源会是平时的很多倍。也有意想不到的高峰。比如一款热门游戏火了之后，需要在云上快速扩容。Kubernetes可以最大化云的弹性。ACK在资源层和应用层提供了丰富的弹性策略。在资源层，目前主流的方案是通过cluster-autoscaler对节点进行水平伸缩。当Pod由于资源不足而无法调度时，cluster-autoscaler会选择一个伸缩组，并自动将实例添加到该组中。在弹性伸缩组中，我们可以根据应用负载需求选择ECS虚拟机、神龙裸机和GPU实例进行扩展。值得一提的是Spot实例，Spot实例可以利用阿里云闲置的计算资源，成本折扣可低至按量付费实例的90%。Spot实例非常适合无状态和容错的应用程序，例如批量数据处理或视频渲染，可以大大降低计算成本。基于阿里云强大的弹性计算能力，我们可以在几分钟内扩展到数千个节点。进一步结合上面提到的ECI，我们可以实现基于ACK中虚拟节点的弹性伸缩。virtual-kubelet可以注册为理论上无限容量的虚拟节点。Pod调度到虚拟节点时，会使用ECI动态创建Pod，非常适合大数据离线任务、CI/CD作业、突发线上负载等。在大客户的生产环境中，弹性容器实例30秒内可启动500个Pod，轻松应对突如其来的请求高峰。在应用层，Kubernetes提供了HPA来水平扩展Pod，VPA来垂直扩展Pod。阿里云提供了alibaba-cloud-metrics-adapter，可以提供更丰富的弹性指标，如IngressGateway的QPS指标、云端监控指标等，动态调整应用Pod的数量。另外，对于很多行业客户来说，应用负载的资源画像是周期性的。比如我们的一个证券行业的客户，每周一到周五，股市开盘时间就是交易时间，而其他时间只能查询不能提供交易，峰谷资源需求的差异高达20倍。为了解决这个场景，阿里云容器服务提供了一个时序伸缩组件，专门用来应对资源配置文件周期性的场景。开发者可以定义一个时间进度表，提前扩充资源，低谷到来后定时回收资源；结合底层cluster-autoscaler的节点可扩展性，在系统稳定性和资源成本节省之间取得了很好的平衡。未来我们会发布一些基于机器学习的弹性伸缩策略，可以实现更好的资源预测，基于历史资源画像提高弹性SLA。赋能下一代Serverless应用上面提到了为什么Serverless受到越来越多开发者的欢迎，因为大家更关注自己的业务，而不是基础设施的维护。Serverless是云服务发展的必然趋势。我们需要将资源调度、系统运维能力下放到基础设施上。Google、IBM、CloudFoundry等联合推出了Knative作为serverless编排框架，可以非常简洁高效的实现serverless应用。它提供了几个核心功能：Eventing-提供了一个事件驱动的处理模型。我们为阿里云扩展了丰富的事件源。例如OSS收到用户上传的视频片段，会触发容器中的应用进行视频转换。代码;Serving——提供灵活的服务响应能力，可根据业务请求量自动弹性伸缩，甚至支持零伸缩。使用阿里云的弹性基础设施，可以大大降低资源成本；Tekton-可以轻松实现从代码到应用程序部署的自动化管道。结合应用管理能力和应用性能监控服务，我们可以基于Knative快速构建具有领域特性的应用托管服务（MicroPaaS），大大降低直接操作Kubernetes资源的复杂度，让开发者更专注于应用迭代和服务交付效率提升。安全沙箱容器技术演进刚刚讲完了编程模型，我们来看看底层实现。所有Serverless的核心实现是安全容器沙箱。传统的DockerRunC容器与宿主机Linux共享内核，通过CGroup和命名空间实现资源隔离。这种方式效率很高，但是由于操作系统内核的攻击面比较大，恶意容器一旦利用内核漏洞，可以影响到整个主机上的所有容器。越来越多的企业客户关注容器的安全性。为提升安全隔离，阿里云与蚂蚁金服团队合作引入安全沙箱容器技术。今年9月，我们发布了基于轻量级虚拟化技术的RunV安全沙箱。与RunC容器相比，每个RunV容器都有一个独立的内核。即使容器内核被攻破，也不会影响其他容器。非常适合运行来自第三方的不受信任的应用程序，或者在多租户场景下更好的安全隔离。经过性能优化后，安全沙箱容器现在可以达到原生RunC90%的性能，RunV容器提供与RunC容器相同的用户体验，包括日志、监控、弹性等。同时，ACK可以混合一个神龙裸机实例上同时运行RunC和RunV容器，用户可以根据业务特点自主选择。在本财年末，我们将推出基于英特尔SGX可信计算技术的可信容器沙箱RunE。容器应用程序在称为CPU飞地的安全且可信的执行环境中运行。打个比方：我们把容器放在保险箱里，任何人，包括云服务提供商，都无法从外部篡改或拦截其中的数据。客户可以在RunE容器中运行密钥签名、验证、隐私数据处理等高机密应用。从微服务到ServiceMesh，再来说说另一个方面——微服务架构的演进。互联网应用架构催生了微服务架构的发展。其核心思想是通过应用功能拆分，将复杂的应用拆解成一组松散耦合的服务，每个服务都遵守单一职责原则（SingleResponsibilityPrinciple）。每个服务都可以独立部署和交付，大大提高业务敏捷性；每个服务都可以独立地横向扩展/收缩，以应对互联网规模的挑战。下沉服务治理能力微服务框架，如HSF/Dubbo或SpringCloud，提供强大的服务治理能力，如服务发现、负载均衡、断路器降级等，这些服务治理能力与应用一起构建，形式为FatSDK，与应用一起发布和维护，服务治理能力与业务逻辑的生命周期耦合。微服务框架的升级将导致整个应用程序的重建和部署。另外，由于FatSDK通常绑定特定的语言，难以支持企业应用的多语言（polyglot）实现。为了解决上述挑战，社区提出了ServiceMesh（服务网格）架构。它将服务治理能力下沉到基础设施，通过独立的Sidecar进程提供服务治理能力，应用端只保留协议的编解码器。这样就实现了服务治理和业务逻辑的解耦，两者可以独立演进，互不干扰，提高了整体架构的灵活性；同时，服务网格架构减少了业务逻辑的侵入，降低了多语言支持性的复杂性。服务网格在阿里巴巴经济体内部，我们开始大规模应用服务网格技术，提供多语言支持，降低业务对接门槛；提供统一的架构模型，加快技术迭代速度。以Istio为代表的服务网格技术前景广阔，但在规模化生产中仍面临诸多挑战。首先是Istio服务网格技术本身的复杂性；二是扩展带来的稳定性和性能挑战：在海量服务的情况下，控制平面能否支持服务配置的高效分发？数据面能不能尽量增加两跳后降低通信时延？将可观察性和策略管理功能部署到数据平面，以避免集中式Mixer引入的性能瓶颈。最后，兼容现有微服务架构，支持现有微服务的统一配置管理服务和通信协议。为了解决上述挑战，阿里巴巴和蚂蚁金服基于兼容Istio社区的技术体系构建了ServiceMesh能力。今年618，蚂蚁金服已经完成了对SOFAMosn核心系统的验证。刚刚结束的双11，阿里巴巴和蚂蚁金服在核心系统大规模上线了ServiceMesh。同时，阿里巴巴经济体会将自身技术演进的成果及时向上游反馈，与社区共同推动ServiceMesh的发展。比如在阿里巴巴开源的服务发现和配置管理项目Nacos的最新版本中，Istio就支持了MCP协议。稍后，阿里云将推出托管的ServiceMesh服务，帮助云端的开发者轻松使用ServiceMesh技术。关注应用程序生命周期另一个焦点是应用程序生命周期的自动化和标准化。我们知道Kubernetes的定位是PlatformforPlatform，帮助企业实现应用的自动化运维和管理。Kubernetes为分布式应用程序管理提供了许多基本的元语言抽象，例如用于无状态应用程序的Deployment和用于有状态应用程序的StatefulSet。但在企业生产环境中，面对应用的不同需求，现有能力还存在一些不足。在参与技术分享的时候，我们经常听到每个企业都在谈论如何修改K8s来解决自己的问题，很多都是类似的。OpenKruise作为云原生技术的领导者，积累了我们在云原生计算技术规模化生产的最佳实践，并通过开源项目OpenKruise与社区一起开放共建。一方面帮助企业客户在云原生探索过程中少走弯路，减少技术碎片；另一方面推动上游技术社区逐步完善和丰富Kubernetes的应用周期自动化能力。以下面新增的控制器为例：BroadcastJob：允许在机器上的指定节点上运行一个一次性的任务，比如我们要在节点上安装一个安全补丁，或者预先下载一个容器镜像到机器上。节点;SidecarSet：越来越多的运维能力以sidecare的形式提供，比如日志、监控、服务网格中的数据面组件Envoy。我们可以通过SidecarSet以声明的方式管理Sidecar的生命周期；AdvancedStatefulSet：支持就地发布和批量升级，让大家更容易支持有状态服务。这些控制器解决了很多客户的痛点。OAM——第一个开放的应用模型11月16日，微软和阿里云联合发布了开放应用模型（OAM），希望建立一个标准化的云原生应用模型，帮助开发者、应用运维、基础设施OAM维度团队更高效合作。它采用的焦点设计标准包括不同的维度。开发人员负责定义应用程序组件、依赖项和架构；应用运维人员负责定义应用运行时配置和运维需求，如发布策略、监控指标等；维护团队可以针对不同的应用部署环境配置自定义参数。通过这种SeparationofConcerns设计，应用定义、运维能力、基础设施都可以被解构。使应用交付更加高效、可靠和自动化。在计算无边界的最后一个方面，我们来谈谈我们对未来无边界云计算的思考。随着5G时代的到来，低时延网络、AI硬件算力、智能应用的快速发展，一个万物智能连接的时代将到来，计算能力从云端延伸到边缘侧和设备侧，并通过云。统一的应用交付和资源管控将是云计算发展的必然趋势。云边端一体化协同基于容器，我们建立了云边端一体化协同平台——ACK@Edge。这样，我们就可以将一些需要低延迟处理的应用部署在边缘节点上，实现就近访问。例如，我们可以将AI模型预测和实时数据处理放在边缘进行实时智能决策，将模型训练、大数据处理等需要海量算力的应用放在云端。ACK边缘版提供统一管控能力，可在K8s集群中同时支持云ECS、边缘ENS节点、物联网设备。并且针对边缘的特殊性，提供单元化隔离、断线自治、自愈能力。我们已经在阿里云视频云、优酷等场景开始大规模应用。优酷腾空云我们以优酷腾空云为例，介绍其计算架构的演进。优酷是中国最大的视频平台。随着优酷业务的快速发展，需要将部署在多个IDC的集中式架构向云+边缘计算架构演进。这时候，我们就需要一种方式来统一管理阿里云的十几个区域和众多的边缘节点。优酷选择了ACK@Edge，可以统一管理云端和边缘节点，实现统一的应用发布和弹性伸缩。通过弹性节省高达50%的机器成本。采用新架构后，用户终端就近接入边缘节点，端到端网络时延降低75%。源于社区，回馈开源最后，云原生技术源于社区的共同建设。作为云原生的践行者和引领者，阿里巴巴全方位拥抱云原生技术，并将我们在规模化生产中的最佳实践回馈社区，与社区一起共建更好的云原生技术生态系统。原文链接本文为云栖社区原创内容，未经允许不得转载。
