云原生技术的初学者指引

当我们初接触云原生技术时，可能会觉得它有些复杂和混乱。不过，我们可以先来了解一个开放，活力的软件社区，即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且，CNCF有一张涵盖了全部云原生解决方案的全景图，许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使，致力于在加拿大推广社区活动和云原生的教育。同时，在CloudOps社区， 我还带领着Docker和Kubernetes研讨会，向大家普及云原生技术，帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议，邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时，我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。

CNCF的历史背景

2014年，谷歌开源了一个主要用于容器编排的，名为博格(Borg)的内部项目。由于没有机构来管理这个项目，谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes，并用Go语言重写了实现部分，成为了CNCF的启动捐赠项目。毫无疑问地讲，Kubernetes只是开始，后续有大批的新项目先后加入到CNCF，围绕着Kubernetes不断地扩展功能。

CNCF的使命

通过提供多种选项的开发软件社区，帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作，希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。

CNCF的历程

目前共有25个项目已经被CNCF接受，在跟进Kubernetes生态发展。希望加入到CNCF的项目，必须是由技术监督委员会(TOC)选定并通过投票评比，取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行，而TOC贡献者是来自CNCF成员公司的代表，我有幸也是其中一位。评选通过的项目就叫CNCF成员项目，CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。

沙箱阶段

这个阶段的项目非常早期，在部署到生产环境之前，需要显著地提升代码成熟度，积极参与开源社区的互动。项目之所以被选中，主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到，CNCF将帮助推动沙箱项目的公共可见性，并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少，并且每12个月都要接受审查，发展不够好的项目可能会被淘汰掉。

孵化阶段

当项目满足所有沙箱标准并具备明显的增长和成熟度特征时，它们就进入孵化阶段。这时，它们必须至少在三家公司的生产环境中使用过，具备稳定的团队，确保稳定提供对社区的贡献，包括处理来自社区的新功能和代码要求等。

毕业阶段

孵化项目一旦达到生产使用的临界点，TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率，并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织，具有文档化和结构化的管理流程，并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前，只有Kubernetes和Prometheus两个毕业项目。

CNCF项目介绍

我将CNCF成员项目划分了12个类别，分别是：编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么，如何演化的，以及如何与其他CNCF项目集成等。

编排

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置，可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排，而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层，将容器分组运行在Pod中，从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期，并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用，CNCF最新的调查显示，超过40%的企业受访者在生产过程中使用了Kubernetes。

应用程序开发

Helm

Helm(孵化阶段)——Helm是程序包管理器，以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm，用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然，这会涉及到创建YAML清单，根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart，可以基于应用程序或配置更改来进行版本控制，可以部署在各种环境中，还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端，但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’，与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司，包括Reddit、Ubisoft和Nike，我建议他们按照新的设计进行优化调整。

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面，有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为，目前大多数云原生应用都是资源密集型的，并且涉及多个数据库、服务和依赖项。此外，模拟云依赖关系非常复杂，例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案，就是使用完全远程的Kubernetes集群，但是这方案会影响IDE、调试器等本地开发工具的应用，并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务，同时保持与运行在远端Kubernetes集群上的其余部分应用的连接，我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境，而无需冻结用于编码、调试和编辑的本地工具。

监控

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程，Prometheus是第二个加入到CNCF的项目，也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统，通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus，用户可以监控VM、Kubernetes集群和运行在任何地方的微服务，尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控，如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式，而后者又是采用Borgmon的运营经验，Borgmon实现了“白盒监控”和低开销的海量数据收集，有着超过300家的服务输出商。在OpenMetrics之前，监控环境主要都是基于像SNMP之类，相对过时的标准和技术，使用专用指标格式，也很少有人关注指标格式规范，存在不少系统差异性的问题。而OpenMetrics出现后，在Prometheus的指标格式之上，定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段，但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此，它只运行在单节点或单容器内，所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言，我们认为是不错的补充。它让大型企业在使用Prometheus时，可以具备高可用性，可以访问长效存储设备。虽然在这个领域，目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是，Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试，而且EA和StorageOS也在prem平台上部署了它。

日志和跟踪

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法，对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式，实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志，但它真正的优势还是在云原生环境Kubernetes之上，作用于那些动态运行的微服务。

Fluentd以daemonset的方式，运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones)，还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力，并将格式化的日志发送到所配置的目的地，如Elasticsearch、Hadoop和Mongo，让用户可以进行后续处理。

Fluentd最初是用Ruby编写的，虽然功能比较完整，但运行时需要50Mb以上的内存，这对于配对容器部署运行显然不太合适。于是，与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的，在运行时只需要几Kb的内存，CPU和内存上效率更高，但功能比Fluentd要简单很多，存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目，只是Kubernetes的一个日志插件。较早的可部署版本是0.12，版本比较老、但非常稳定，已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进，例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配， 很大可能成为下一个CNCF毕业项目。

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为，这使用分布式跟踪对于大规模构建微服务的重要性不能被低估，然而，分布式跟踪非常具有挑战性，需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准，这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API，可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前，OpenTracing集成了开源(如Jaeger，Zipkin)和商业跟踪解决方案(如Instana，Datadog)。

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案，它与OpenTracing兼容，最初是由Uber开发和测试的。它的名字的发音是yā′gər，即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写，采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans，并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能，提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的，可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时，Jaeger集成了包括Istio和Linkerd在内的服务组件，使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标，并与Fluentd集成来进行日志传输，这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。

容器注册

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的，是一个开源可信任的容器注册器，用于存储、标记和扫描Docker镜像，提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目，稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用，包括TrendMicro、Rancher、Pivotal和AXA。

存储和数据库

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS，它运行在常规的硬件上，对外提供对象存储，块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上，然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度，增加工作挑战性，降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中，并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念，即将人的操作知识编码到软件中，从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比，Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例，Rook操作人员可以自动化存储管理员的工作，例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph，在0.8版本时，对Ceph的支持达到Beta版，随后发布了用于存储厂商的Rook框架，这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS，后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多，尤其是在Prem平台上，包括CENGN、Gini、RPR都有部署，还有许多公司正在评估阶段。

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩，在不影响应用的情况下，进行水平的无限扩展。 当用户的分片达到满负荷时，Vitess能以零停机时间和良好可观察性，重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题，项目成长趋势良好。

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库，它具备简化调度和自动平衡的能力。它充当了分布式存储层，提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase，但是它的优点是没有分布式文件系统。TiKV由PingCAP开发，目前还有有来自三星、腾讯云和UCloud的贡献者。

容器运行时

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器，属于Docker的备选项目。当时，Docker成为Kubernetes的默认容器，但遭遇到来自kubelet的压力，Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图，并且正在给Docker添加一些复杂的功能。例如，为Docker添加集群模式，以及将文件系统从AUFS更改为overlay2。但做这些工作时，并没有向外发布信息，导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且，Kubernetes用户需要用到的只是一个简单的容器，具备启停容器，并具备伸缩、升级等功能即可。因此，CoreOS就打算将RKT开发成Docker的替代品，专门为Kubernetes而构建。但令人意外的是，这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI)，这个接口可以连接任何类型的容器，并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响，但却没有被最终用户所接受，特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外，由于Kubernetes的流行，有许多容器解决方案都在争夺这一细分市场，例如Gvisor和基于OCI的cri-o都越来越流行，而RKT有点风景不再的感觉，可能会成为CNCF孵化器中被移除的项目。

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样，支持OCI和Docker镜像格式，但不同的是，Containerd设计的目的是嵌入到较大型的系统中，而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用，但随着时间的推移，集群模式等功能的加入，使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言，Docker的复杂功能反而有些多余。因此，Kubernetes开始寻找包括RKT在内的替代方案，来替代默认的Docker容器。这时，Docker项目决定将自己拆分为松耦合的组件，采用更模块化的体系结构。这也就是Moby项目，其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes，并改名为ri- Containerd。但从Kubernetes 1.10开始，默认采用Containerd通过内置的CRI插件实现集成，省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎，Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分，在Kubernetes生态系统中还保有一定的位置。

服务发现

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起，将CoreDNS作为默认的集群DNS服务器，而在更早以前，SkyDNS是Kubernetes集群的DNS组件，它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案，但体系结构不够灵活，很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时，分3个容器(Kube-dns，Dnsmasq和Sidecar)运行，容易出现Dnsmasq漏洞，在新功能扩展上也存在类似SkyDNS的问题。而恰好这时，CoreDNS用Go语言进行了全面重写，成为了基于插件的灵活可扩展的DNS解决方案，而且在Kubernetes上，运行时只需启动一个容器，也没有漏洞方面的问题，提供的ConfigMap工具可动态更新配置。此外，CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前，CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件，用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。

Service Meshes

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层，用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下，通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性，帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能，在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的，项目具有广泛的生产用途，并吸引了许多探索服务网络的公司的兴趣。目前，Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上，这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化，例如与Kubernetes紧密集成的Istio项目的引入，与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能，这大大降低了Linkerd的受欢迎程度，甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户，Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目，该项目允许DaemonSets使用Istio作为Sidecar代理，重写了dataplane，用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前，Conduit项目被重新命名为Linkerd 2.0，并发布了GA，这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展，像Istio和Linkerd 2这样的项目将是这方面的核心。

服务代理

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目，是具备厂商无关性、高性能、轻量级的应用代理服务，已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下，为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成，它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力，负载均衡failovers的域感知能力，因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目，但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法，对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目，这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群，能够限制可能配置虚拟主机和TLS凭证的命名空间，并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador，这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的，非常轻量级，非常适合在Kubernetes内部以Sidecar模式运行，也非常适合与API驱动的配置更新的风格相协同，成为dataplanes服务网格的理想候选方案。另外，服务网格 Istio宣布Envoy是其dataplane的默认服务代理，Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同，后者提供了每个服务的可见性，并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近，Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在，Envoy在背后没有任何供应商或商业项目的驱动下，创立了一个庞大而活跃的开源社区。如果您想尝试Envoy，也建议试用一下Istio、Ambassador或Contour， 2018年12月10日在西雅图，Kubecon的Envoy社区成功地主办了第1届EnvoyCon，欢迎大家加入到社区。

安全

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具，设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中，使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比，它具备更多的审计功能。

Falco用一组预配置的规则，定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中，基于这些规则，Falco可以检测到任何调用Linux系统的行为，并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步，或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获，然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故，减少此类事件造成的经济损失。 

随着Falco被纳入CNCF的沙箱阶段，我们希望它以后与更多的其他CNCF项目深度集成，例如在Falco内集成官方的Helm Chart。

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题，且随着负载的弹性伸缩和动态调度，这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新，主要是设计用于与Spire紧密配合的项目。

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境，是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构，支持多种平台。目前，围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID，使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处，并确认只使用软件的最新版本，来提供内容信任，改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品，这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上，是基于TUF，确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段，解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具，但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容，以避免漏洞)，和对象之间的信用委托。例如用户之间，不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用，但它们的解决方案集成到各种商业产品或开源项目中，用于可信分发的内容签名或图像签名，这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas，它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验，也可用于容器分析API和GCP的二进制授权。和JFrog，AquaSec的同类功能类似。

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略，允许在一个技术堆栈中分发不同类型的策略，并自动更新，而无需重新编译或重新部署。在应用和平台层，OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。

数据流和消息流

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务，允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性，并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API，支持多种技术用例，包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递，以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是，NATS工作在应用层。

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架，提供在多个平台上，库、客户端和服务器之间进行通信的能力。可以在任何环境中运行，并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持，来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范，CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段，还需要极大地提高应用程序的可移植性和效率。

后续展望

云原生生态正在不断地飞速增长。在不久的将来，还将有更多的项目被纳入到沙箱阶段，让它们有机会获得社区的兴趣和认识。我们希望像Vitess，NATs，Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时，在云原生持续交付的领域还相对空白，我们希望CNCF能够继续关注。