摘要

容器和Kubernetes是构建云原生基础设施的关键所在，有助于提升软件效能和开发生产率，预计2020年所有领先的容器管理软件均内置服务融合技术，到2022年有75%的全球化企业将在生产中使用容器化的应用(当前不足30%)、还有50%的应用软件将容器化适应超融合环境（目前少于20%），Gartner总结出类似八大发展趋势以及相应对策建议，企业架构师和技术创新领导者应随之而动。

术语“云原生基础设施（Cloud-native infrastructure）”定义尚不明确，但含义丰富，通常般指由API管理（可编程）亦即软件定义的基础设施，通过将应用程序抽象化，从而可与底层基础设施分离，具有四个特点：

■模块化：抽象独立的服务包（如容器化或无服务器架构）；

■可编程性：通过声明API和策略来实现资源调配和管理；

■伸缩性：协调器通过自动化和策略驱动的方式纵向动态扩展资源；

■弹性：服务就是松散耦合的单元，相互独立且兼具容错能力。

云原生应用并非针对在传统的基础设施中运行而设计，需要更高程度的服务发现、可编程性、自动化、可观测性、强大的网络通信及安全性等。以往三年，容器和Kubernetes推动云原生基础设施发展，并产生重大革新，出现三种新兴趋势：新用例、超越核心构建块的技术演进、生态系统成熟度，重塑云原生基础设施的未来任一种趋势都对技术创新领导者未来的现代化战略产生影响。在Gartner的研究评估了这些关键的新兴趋势（如图1所示），并为企业架构和技术创新领导者如何应对新趋势提供指导。本研究的聚焦在基础设施层，而非应用程序层，当前这类技术发展尚不成熟，也不普遍，但保持关注极为重要

图1-云原生基础设施的未来

关键发现

■技术创新领导者热衷于在云原生基础设施技术领域投资，目的是提升软件效能、提高开发敏捷性、保证应用程序的可扩展性和弹性、并减少技术欠账。

■技术创新领导者乐于开发云本地基础设施技术，但生产部署仍然受技能差异和技术诀窍的约束。

■支持云原生技术的开源社区和供应商有三个核心目标：稳定和简化核心技术、拓展潜在用例、集成新技术转化为以Kubernetes为核心的软件平台和云服务。

■新项目、新产品、新供应商、新商业模式不断涌现，云原生生态系统将快速演进，技术创新领导者难以持续领先。

主要建议

企业架构（EA）和技术创新领导者通过技术创新推动业务转型：

■与供应商研讨其产品战略及应对新趋势的能力，对您所在的组织至关重要。

■培训员工，鼓励他们拥抱开源软件（OSS）社区，锻造企业内部能力。

■在不同的操作环境中使用标准蓝图，提高工具的熟悉度，避免配置和工具链迁移。

■新兴技术有着稳定性和特性不足等问题，确保部署过程简化，接受快速失败并迅速迭代。

趋势

      趋势1：混合和多云（Hybrid & multicloud)

        原因：

（1）云服务提供商之间差异增大；

（2）减少对开发商依赖，保证应用可移植性。

      市场状态：Docker运行时引擎（及容器化）和kubernetes成为跨环境的标准，可提供跨私有云与公共云环境之间的一组公共抽象，但由于基础设施支持过于分散以及各云商的服务差异，实现混合目标不易，但Kubernetes生态在发展中，出现Kubernetes联邦和开放式服务代理（open service broker，OSB）这两类概念可能有助简化多云部署。

      推动厂商及其产品：AWS （Outposts ）、Docker（Docker Enterprise）、Google（Anthos）、Mesosphere（DC/OS ）、Microsoft （AKS on Azure Stack）、Pivotal（ PAS/PKS）、Rancher（Rancher）、Red Hat（OpenShift ）、VMware（PKS）等；

       建议：

■选择支持跨云本地堆栈的OSS项目的供应商。

■与现有或潜在供应商探讨对OSB及多环境Kubernetes管理的支持。

■优先选择为混合云提供端到端支持的供应商。

     趋势2：边缘计算（Edge Computing）

      原因：

（1）轻量级容器比虚拟主机更适应边缘环境；

（2）微服务带来的模块化。

      市场状态：

容器化很可能成为边缘计算应用的主流分发方式，物联网平台商开始采用容器作为边缘计算基础设施。Microsoft Azure物联网边缘计算平台允许供应商添加Docker容器作为边缘模块、AWS IOT Greengrass支持部署Docker容器或快照、Balena.io项目支持跨设备部署和管理容器。Kubernet虽为数据中心而生，但在边缘环境中也有应用，Chick-fil-A在其2000多家门店中构建三节点kubernetes集群，像Rancher这样软件供应商也在开发可用于边缘计算的轻量级kubernetes。

推动厂商及其产品：AWS IoT Greengrass (IoT edge software)、Microsoft Azure IoT Edge (IoT platform service)、Rancher k3s (Lightweight Kubernetes distribution)等。

建议：

■选择支持容器的物联网平台，在边缘尝试部署容器。

■轻量级Kubernetes可能有效，要确保与边缘设备及运行的应用兼容。

      趋势3：服务网格（Service Mesh）

  原因：

（1）服务网格是微服务运行时基础设施的重要组成部分，可确保应用程序服务之间的通信快速、可靠和安全；

（2）服务网格在逻辑上分为数据面板和控制面板，共同作用保证微服务安全运行。

 市场状态：

 服务网格尚处于早期，多数为开源项目，由Google、Lyft、Netflix和Twitter等支持。服务网格中数据面板技术主要由Envoy、HAProxy和Nginx等支持，控制面板技术有Consul、Istio和SmartStack），还有如Linkerd将两者结合。Gartner认为，Isito将是Kubernetes和CloudFoundry实际使用和分发的标准服务网格，Gartner也希望云商的选择更多元一点。

推动厂商及其产品： Consul、Envoy、Istio、Linkerd等。

建议：

■明确可在服务网格中收益的微服务应用。

■跨多个服务网格技术进行概念验证（POC）。

     趋势4：基于Kubernetes融合fPaaS（Convergence of Serverless fPaaS on Kubernetes）

 原因：

（1）容器化和无服务器fpaas服务是下一代应用的关键构建块；

（2）操作管理繁重，人们开始使用无服务器作为设计准则。

 市场状态：

 可用于内部部署fPaaS及无服务器容器产品开始成熟，如Azure Container Instances、AWS Fargate、Google的Cloud Run (Beta)等。而Kubernetes的广泛应用及其API事实标准，也有少数厂商开始支持，如Fission、Fn 、Kubeless等，还有就是Google刚开源的Knative框架，这个框架Pivotal和 Red Hat均表示支持。

 建议：

■在高伸缩的事件驱动用例中，尝试fPaaS产品。

■在战术层面上部署基于Kubernetes的无服务器容器服务。

      趋势5：裸机容器和微虚拟机（Bare-metal containers µVMs）

原因：

（1）当前容器主要在虚拟机上，有两点原因：一是简化节点操作管理，二是虚拟机硬件隔离提高安全性。但虚拟机资源和性能开销高，同时购置成本也高；

（2）大型用户希望消除这种因素，并提高成本效率和性能，而推动裸机容器和微虚拟机。

市场状态：

部分CAAS供应商提倡裸机容器以简化操作，如，Red Hat在Red Hat Openshift 4.0版中增加可用于裸机容器的自动化特性，还将OpenShift与OpenStack平台集成，同样增强裸机容器性能。另有部分供应商在研究容器优化、轻量级的虚拟机技术，也就是微虚拟机（MicroVM），其开销远少于传统的虚机。第三种方法基于内核的沙盒容器，实现不使用虚拟机的情况下实现隔离。哪种方法最终将成为标准，有待观察。

推动厂商及其产品： 

AWS（Firecracker，MicroVM方法）、OpenStack基金会（Kata Container，MicroVM方法）、VMware（vSphere Integrated Containers，MicroVM方法）、Google（gVisor，沙盒方法）等。

      建议：

■评估采用裸机容器实现大规模部署，另外资源受限的环境（如边缘计算）也裸机容器的适用场景。

■在要求高安全性尝试使用安全容器技术，但要考虑生产环境验证及是否支持Kubernetes及是否与开放容器计划（Open Container Initiative，OCI）兼容能力。

     趋势6：第三方ISV支持容器化（Third-Party ISV Support for Containers）

 原因：

（1）容器镜像目前大都基于开源软件，如Elasticsearch, NGINX、 Postgres等。

（2）容器化支持的商业应用面临许可证及产品支持，因此进展极慢。

 市场状态：

 主要的独立软件供应商（ISV）开始改进容器支持，如，IBM在2018年宣布，将支持所有IBM中间件产品组合作为容器，包括WebSphere和DB2等。SAP则与SuSE和IBM合作开发Kubernetes上的Cloud Foundry，其Data Hub产品对容器和Kubernetes实现原生支持。另外如ApacheKafka和ApacheSpark等开源项目开始扩展支持Kubernetes。由于ISV对容器支持增加，CAAS供应商也将其市场拓展到容器镜像。到2018年11月，谷歌云平台（GCP）市场已支持39个Kubernetes应用程序和44个容器镜像。2018年11月AWS在Re:invent 2018峰会发布AWS容器市场，目前已有200多个产品。

  推动厂商及其产品： AWS（AWS Marketplace for Containers）、Google（GCP Marketplace）、IBM（IBM Cloud Marketplace）、Microsoft（Azure Marketplace）等。

建议：

■如果计划现有应用程序容器化，应用提前确认商业许可及支持性。

■借助CAAS供应商的容器市场，可提高容器化及软件采购的效率。

    趋势7：支持有状态应用（Support for Stateful Applications）

原因：

（1）容器起初服务于为短暂应用，针对无状态应用程序进行优化。当前，自动化部署、扩展和管理有状态的应用程序（如数据库）已变得非常重要。（2）支持有状态的应用、新技术开始出现（如Kubernetes、存储解决方案和存储接口）。

市场状态：

自2017年12月Kubernetes发布的1.9版就开始通过状态集支持有状态应用程序（statefulset）。2018年12月发布Kubernetes 1.13版本，用于容器编排引擎的标准存储接口container storage interface（CSI）已普遍可用，三种因素可用于为容器提供持久存储：存储设备、软件定义存储（SDS）和云存储服务。在这些产品中，容器本地数据服务的需求对于支持微服务结构变得非常重要，这些需求包括硬件不可知性、API驱动、基于分布式架构，能够支持边缘、核心或公共云部署等。

推动厂商及其产品：

主要有三类厂商。

■存储设备类：Diamanti, NetApp, Pure Storage；

■软件定义存储（SDS）：Elastifile, NetApp, Nutanix, Portworx, Red Hat, Robin Systems, StorageOS, Vmware；

■云存储：AWS, GCP, Microsoft Azure；

建议：

■选择存储解决方案时，应参照容器本地数据服务需求、标准存储接口、容器存储接口（CSI）等一致。

■当部署通用有状态应用存储，应使用社区或销售商提供的参考架构，如MYSQL、PostgresQL、Apache Kafka、Apache Cassandra及Apache Spark等。

趋势8：跨过Kubernetes的成熟项目（Maturing Projects Beyond Kubernetes）

原因：

（1）Kubernetes是构建云原生应用的基础，但还不是全部。

（2）还需要额外的工具来增强Kubernetes的能力，并与Kubernetes的API和接口紧密集成。

市场状态：Kubernetes是CNCF稳定期内最知名、最成熟、最受广泛支持的项目，除此之外，其他项目已逐步进入生产准备阶段。

推动厂商及其产品：

已毕业的项目及其主要贡献者。

■Prometheus （Google、Red Hat、SoundCloud）；

■Envoy（Google、Lyft、Tetrate）；

■CoreDNS（Google、Infoblox）；

■Containerd（Docker、Google、IBM）；

建议：

■优先考虑那些为CNCF项目提供支持并与Kubernetes建立联系的供应商。

■实施这些新技术之前制定一个为期六个月的培训计划，来测试新用例和实施最佳实践。

      本报告由赛博研究院编译，部分图片来源于网络（如有侵权，请联系删除），转载请注明：本文来源于赛博研究院官网。

      更多精彩内容请关注“赛博研究院”公众号。