回顾｜领略云原生技术之美

4 月 14 日，「DaoCloud 道客」解决方案架构师 - 王钟汉，做客「凡泰讲堂」，分享《云原生技术发展前瞻》，与众多开发者一起回顾云原生的演进历程，探讨了新一代 CNI--Cilium 和服务网格等时下热门技术，并分享了Merbridge、Clusterpedia、HwameiStor，这些冉冉升起的开源项目。

下面将一一展开详细介绍，让我们一起洞见云原生技术，共赏 Kubernetes 技术的魅力！

01

「云」的
变迁与演进

首先，跟着上图几个重大事件的出现脉络，简单回顾一下，「云」是如何一步一步演化到「云原生」的。

虚拟化技术最早出现在大型机时代。直到 2001 年，VMware 发布了第一个针对 X86 服务器的虚拟化产品。之后几年，随着虚拟化技术的成熟，云计算市场逐渐形成，出现大批基于虚拟技术的云计算产品。

2006 年，AWS 推出首批云产品 Simple Storage Service (S3) 和 Elastic Compute Cloud (EC2)，基于 AWS 的基础设施，企业可以构建自己的应用程序，是 IaaS 产品的代表。

2009 年，Heroku 推出第一款公有云 PaaS (Platform-as-a-Service)，实现以更低的复杂度进行更高级的编程。基于 AWS，国内用得比较少。

2010 年 7 月，Rackspace Hosting 和 NASA 联合推出了一项名为 OpenStack 的开源云软件计划。OpenStack 是第一个开源的云平台，标志着云计算进入开源时代。

2011 年，Pivotal 推出了开源版 PaaS Cloud Foundry，作为 Heroku PaaS 的开源替代品。至此，PaaS 也加入了开源的行列。

2013 年，Docker 的发布掀起了一场影响深广的云计算技术变革，Docker 风靡一时，Container 逐步替代 VM，云计算进入容器时代。

2014 年10月，Google 开源 Kubernetes，并于 2015 年捐赠给 CNCF。

2017 年底，Mesos、Swarm、Kubernetes 的史诗大战，最终以 Kubernetes 全面胜利而告终，云计算进入 Kubernetes 时代。

2018 年 3 月，Kubernetes 从 CNCF 毕业，成为 CNCF 第一个毕业项目。[1]

Kubernetes 作为事实上的容器编排标准，屏蔽底层架构差异性，帮助应用平滑运行在不同基础设施上，是当前最流行的云原生底座。

CNCF 是 2015 年 7 月，Google 联合 Linux 基金会成立的，Kubernetes 是 CNCF 管理的首个开源项目。

02

云原生定义
演变过程

Pivotal 是 Cloud Native/云原生应用的提出者，其还推出了 Pivotal Cloud Foundry 和 Spring 系列开发框架，是云原生的先驱者和探路者。 

2015年，来自 Pivotal 公司的 Matt Stine 编写了一本名为《迁移到云原生应用架构》的电子书，提出云原生应用架构应该具备的几个主要特征：

• 符合12因素应用 (Twelve-Factor Applications)

• 面向微服务架构 (Microservices)

• 自服务敏捷架构 (Self-Service Agile Infrastructure)

• 基于API的协作 (API-Based Collaboration)

• 抗脆弱性 (Antifragility)

而在 Pivotal 最新的官方网站 https://pivotal.io/cloud-native 上，对 Cloud Native 的介绍则是，如下图所示的四个要点。

CNCF 建立之后，以云原生为核心打造云原生生态体系，初期对云原生的定义包含以下三个点：

应用容器化(software stack to be Containerized)、面向微服务架构(Microservices oriented)、应用支持容器的编排调度(Dynamically Orchestrated)

认为云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成，包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。

2018 年，随着社区对云原生理念的广泛认可和云原生生态的不断扩大，加入 CNCF 的项目和会员大量增加，起初的定义已经不再适用，因此 CNCF 对云原生进行了重新定位。

2018 年 6 月，CNCF 正式对外公布了更新之后的云原生定义 (包含中文版本)  v1.0 版本 (节选)：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。[2]

可以看到，云原生是不断生长和变化的，定义只是针对某一阶段的技术总括，重要的是技术的背后，如何为生产和发展带来变革和进步。

云原生全景图

云原生通过什么方式来实现呢？首先，来简单了解一下云原生全景图。

CNCF 自 2016 年 12 月起，开始维护云原生全景图，主要包含四行、两列，除此之外，最底部还展示了 Kubernetes 认证服务提供商和培训合作伙伴。云原生全景图汇总了社区成熟、使用范围较广以及具有最佳实践的产品和方案，为企业构建云原生体系提供参考。

四行包括应用定义及部署 (App Definition and Development)、编排与管理 (Orchestration & Management)、运行环境 (Runtime)、配置 (Provisioning) 等板块。

其中第四行配置板块，提供了构建云原生基础设施的工具。往上的运行环境指的就是容器运行环境，包括了容器存储、容器计算、容器网络三大类工具。编排与管理板块则涵盖了管理应用程序所需的工具，如服务网格、容器编排、服务代理、API 网关等。最上层的应用定义及部署板块，主要包括定义和开发应用程序的工具，比如数据库、镜像构建和 CI/CD 工具。

云原生全景图右侧的两列，包含平台 (Platform)、可观测性和分析 (Observability and Analysis)、无服务 (Serverless) 等板块。

其中可观测性和分析板块，主要罗列了监控、日志分析、追踪、混沌等各类工具，平台板块展示了从服务、安装、主机到分布管理的各厂家的技术分布情况。无服务板块包含的内容比较广泛，细分为工具、安全、框架、注册平台和可安装平台等五大模块。

「DaoCloud 道客」长期深耕开源社区，作为最早一批加入 CNCF 基金会的云原生企业，不仅入选了全景图平台类解决方案提供商，并于 2018 年成为 CNCF 官方认证的 Kubernetes 服务提供商和培训合作伙伴，其开源的 Merbridge 项目于近期入选了服务网格 (Service Mesh ) 模块。

03

新一代 CNI
Cilium

云原生这两年最火的技术，当属新一代 CNI--Cilium 和服务网格，为何都对它们青睐有加？它们有何重要作用？接着带大家了解，这两个技术的起源和技术架构。

发展脉络

从 2013 到 2018 年，Kubernetes 网络技术栈经历 flanel、weave、Calico、Mac Vlan 等网络方案，然而随着容器密度的增大，以及生命周期的变短，给原生容器网络带来的挑战也越来越大。2017 年 DockerCon 上 Cilium 第一次发布就备受瞩目，2019 年 Google 全面参与 Cilium 项目。

Cilium 是一个开源软件，用于透明地提供和保护使用 Kubernetes、Docker 和 Mesos 等Linux 容器管理平台部署的应用程序服务之间的网络和 API 连接及安全。

Cilium 基于一种名为 eBPF 的新 Linux 内核技术，可以在 Linux 内部动态插入强大的安全性、可见性和网络控制逻辑，不需要更新应用代码或重启服务本身就能实现强大的安全可视化功能。除了提供传统的网络级安全性之外，eBPF 的灵活性还可以在 API 和进程级别上实现网络安全管理，以保护容器或容器内的通信。[3]

Cilium 还可以提供传统网络第 3 层、4 层隔离功能，以及基于 http 层上隔离控制，来实现更强的安全性隔离，如高阶 Network Policy、7 层流量控制、取代 kube-proxy 等等。

Cilium 架构

Cilium 是沟通容器编排系统和 Linux Kernel 的中间层，可以为上层编排系统中大规模和高度动态的容器环境，提供弹性、可视化的网络安全管理。下层可以基于运行在 Linux 内核的 eBPF 程序，动态地插入和控制容器网络的转发行为以及安全策略执行。

Cilium 的架构分为以下几个部分：

• Key-Value 数据存储库用于存储策略信息等；

• Cilium Agent 组件是用户空间守护程序，沟通容器运行时和容器编排系统，接受上层配置；

• Cilium Operator 以集群为单位，管理和规范集群中的任务；

• 客户端的命令行工具 Cilium CLI，可以与 Cilium Agent API 交互，并提供直接访问 eBPF 的工具。 

此外，Cilium ClusterMesh 实现了一个 CNI 互联多个集群，扩展了 Cilium CNI 的能力。ClusterMesh 打通了多集群之间的网络通信能力，并提供全面可靠的安全策略、负载均衡、透明的跨集群服务发现、透明加密、Pod 路由等能力。

04

服务网格
ServiceMesh

微服务出现前，系统之间通过 SOA 和 ESB 服务总线，进行信息交换和通信治理。而进入微服务时代，每个服务执行一些离散的业务功能，随着分布式服务的部署 (比如基于 Kubernetes 的系统) 规模和复杂性的增长，业务系统可能会变得更加难以理解和管理。

服务与服务之间通信需求包括发现、负载平衡、故障恢复、度量和监视，通常还有更复杂的操作需求，比如 A/B 测试、canary 部署、速率限制、访问控制、加密和端到端身份验证等等。

而微服务治理体系也有不同的方案，其中以 Spring Cloud/Dubbo 为代表的传统微服务框架作为第一代治理体系，获得了很广泛的使用，但是它也带来了一些问题：代码侵入性、难以跨语言、升级困难等，这催生了云原生微服务治理体系的诞生 -- 服务网格，也就是 ServiceMesh。

Istio介绍

作为服务网格的实现产品，Istio 一经推出就备受瞩目，成为各大厂商和开发者争相追逐的 “香饽饽”，当前 Istio 已经成为 Service Mesh 的事实标准。

它是一个完全开源的服务网格，以透明层的方式构建在现有分布式应用中。它能够提供各种 API 的平台，可以与常见日志监控系统或策略系统集成，实现流量管理、访问策略、收集数据等功能，而所有这些功能都对业务代码透明，即不需要修改业务代码就能实现。

Istio 的多样化特性可以高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。[4]

Istio 的架构

对服务网格来讲，业务代码无侵入和网络层的全权代理是其重要的优势。

Istio 的架构分为数据面 (Data Plane) 和控制面 (Control Plane)，与Kubernetes 的架构非常相似，可以很好地解耦各个功能组件。

控制面，管理 Istio 的所有功能，包括 Pilot、Mixer、Citadel 和 Galley 服务组件。

数据面，通常以 Envoy 作为应用容器的代理程序，常被称为 “Sidecar”，主要接管服务的进出流量，接受控制组件的控制，并向控制面传递遥测数据 (日志、监控和链路追踪信息) 。

eBPF 加速服务网格

虽然 Istio 有很多优势，但是它却牺牲了服务通信的性能，增加了访问的延迟，而社区当中也有对其进行性能优化的方案。如，使用eBPF 加速服务网格，就是其中一个比较火热的话题。

在服务网格的情况下，代理在传统网络中作为 sidecar 运行，数据包到达应用程序的路径相当曲折，入站数据包必须穿越主机 TCP/IP 栈，通过虚拟以太网连接到达 Pod 的网络命名空间。[5]

而在 eBPF 加速、无 sidecar 的服务网格模型中，网络数据包通过的路径要短得多，支持 eBPF 的网络允许数据包走捷径，绕过内核的部分网络堆栈，这可以使 Kubernetes 网络的性能得到显著改善。 

在基于 eBPF 的 Kubernetes CNI 实现中，如 Cilium 还支持在每个节点使用一个 Envoy 代理实例，运行服务网格的数据平面，减少 sidecar 的资源开销，提升性能 

Merbridge

Merbridge 是「DaoCloud 道客」的一个开源项目，实现了通过一行代码开启 eBPF ，代替 iptables，在服务网格场景下，完全无感知地对流量通路进行加速。同时，不会对现有的 Istio 做任何修改，原有的逻辑依然畅通。这意味着，如果以后不再使用 eBPF，那么可以直接删除掉 DaemonSet，改为传统的 iptables 方式后，也不会出现任何问题。

05

更多开源项目

「DaoCloud 道客」是一个生长在开源、云原生上的一个企业，我们深耕云原生开源项目，同时，也把一些优秀的项目推到了开源社区，积极推动和贡献开源社区。除了上面提到的 Merbridge，我们还开源了以下项目。

Clusterpedia

在多集群时代，我们可以通过 cluster-api 来批量创建管理集群，使用 Karmada/Clusternet 来分发部署应用。但是，我们要如何去统一地查看多个集群中的资源呢？似乎还缺少一个趁手的工具。

Clusterpedia 解决了这一问题，通过加持 kubectl，即可实现多集群资源的复杂检索。

HwameiStor

在云原生时代， 应用开发者可以专注于业务逻辑本身，而应用运行时所需的敏捷性、扩展性、可靠性等，则下沉到基础设施软件和运维团队。

HwameiStor 正是满足云原生时代要求的储存系统。它具有高可用、自动化、低成本、快速部署、高性能等优点，可以替代昂贵的传统 SAN 存储。