以下是我对Cloud Native Computing Foundation（CNCF）在2017年12月时托管的项目进行的简要总结。在我参加2016年KubeCon @Seattle时，共有4个项目，但在一年左右的时间里，项目数量增加到了14个。

中国云原生计算基金会（CNCF）是什么？

云原生计算基金会（以下简称 CNCF）是一个致力于推动云原生开源技术，如 Kubernetes和 Prometheus的组织。它于2015年成立，在Linux Foundation的管理下，第一个项目 Kubernetes 是由 Google 捐赠的。CNCF的合作伙伴包括 AWS，Google Cloud，Microsoft 等大型云服务提供商，以及与云技术相关的主要企业，如Red Hat，Docker，CoreOS（成员企业列表）。

CNCF 除了还进行 Kubernetes 集群的合规认证和 Kubernetes 管理员的认证考试（Certified Kubernetes 和 Certified Kubernetes Administrator (CKA)），还主办了 KubeCon + CloudNativeCon 这样的活动，并且 KubeCon + CloudNativeCon 2017 有参加者超过4000人（其中 Z Lab 也有4名参加）。

以下是2017年12月時的項目清單。

截至2017年12月，CNCF托管了以下14个项目。根据CNCF的技术监督委员会的提案，项目如果被接受，就会被托管。通过查看Pull Request中提出的提案，可以了解其他候选项目有哪些。

各个项目

Kubernetes-容器编排平台

Kubernetes是一个容器编排工具。通过Kubernetes，可以将几台到几千台服务器以一个集群的形式进行管理，并通过简单的界面高效地部署和管理容器。这样，即使是需要数百台服务器的应用程序部署也可以通过一个命令轻松完成。采用容器技术使得Kubernetes具有比PaaS更高的灵活性，并且能够抽象化IaaS层实现多云环境。

最初是基于Google在其内部协调工具Borg上获得的十多年经验而开始开发的项目，也是最早捐赠给CNCF的项目之一。在CNCF项目中，它是非常庞大的，并且以KubeCon + CloudNativeCon这个活动名称将Kubernetes的名字置于前沿，可以说是CNCF的核心产品。

普罗米修斯

Prometheus是一种基于拉取模式的度量监控系统。它以多样的服务发现为特点，适用于监视目标在动态变化的环境中，类似于Kubernetes的系统。通过独特的查询语言PromQL，可以灵活地进行可视化和警报规则的设置。从2015年开始，每年都会举办名为PromCon的活动。

在 Z Lab 中，我们将 Prometheus 作为 Kubernetes 的度量监控工具，使用 Grafana 进行可视化和警报处理。

OpenTracing 开放追踪

OpenTracing提供了分布式追踪的开放规范和各种语言的库（Tracer）。在微服务架构中，分析每个服务所花费的时间对于性能分析非常重要，因此需要使用这种分布式追踪技术。分布式追踪系统在Google内部分布式追踪系统Dapper的论文于2010年发表后，开始实现了Zipkin、Jaeger、LightStep等各种系统。由于追踪系统之间缺乏API的兼容性，所以很难将其集成到许多软件中，因此OpenTracing的目标是提供一个不依赖于供应商的标准API。

这篇文章 “Towards Turnkey Distributed Tracing” 由项目委员 Ben Sigelman 解释了该项目的目标。Ben Sigelman 曾在 Google 任职时是 Dapper 的开发者和论文作者之一，目前是一家名为 LightStep 的监控技术公司的 CEO。

流畅的日志采集工具

Fluentd是Treasure Data开发的日志收集器。它还拥有丰富的插件，可以适应各种输入和输出。它在2011年发布，似乎是当前CNCF项目中具有历史的产品。

Z实验室还在Kubernetes的容器日志和系统日志收集方面使用了Fluentd。此外，还利用了fluent-plugin-prometheus，将nghttpx ingress controller的日志转换为Prometheus的度量指标，以实现对HTTP流量的请求次数和响应时间进行可视化展示。

链接尔德

Linkerd是一个作为HTTP代理的系统，用于实现服务网格。作为服务网格，它承担以下功能。

• 負荷分散

• サーキットブレーカー

• サービスディスカバリ

• リクエストルーティング

• リトライ

メトリクス

您可以通过将上述功能设置为linkerd的HTTP代理来在应用程序端使用。在使用Kubernetes时，提供了两种方式来配置：一种是在每个节点上使用DaemonSet进行配置，另一种是作为每个Pod的Sidecar进行配置。

另外，linkerd 的作者正在开发一款名为 Conduit 的全新服务网格。linkerd 是使用 JVM 语言 Scala 编写的，而 Conduit 则经过了 Rust 的重写，以实现轻量化。

gRPC

gRPC 是基于 HTTP/2 的 RPC 框架，由 Google 开发。它基于在 Google 内部使用了 15 年以上的 RPC 框架 Stubby 的经验而构建。gRPC 具有以下特点：

• Protocol Buffers (v3) をベースとしている

バイナリ形式のためデータ量が少なく、高速にパースを行える
IDL(Interface Definition Language) を定義することで、各種言語のライブラリを生成できる
proto3 という最新バージョンで、serviceというRPCの定義や、JSONへの相互変換ができるようになった

通信プロトコルは HTTP/2

コネクションの多重化とバイナリプロトコルで効率よく通信可能
双方向でのストリーム通信が可能

多言語に対応

C, C++, Java, Go, Node.js, Python, Ruby, Objective-C, PHP, C#

Kubernetes中也使用了etcd (v3)进行通信，并作为微服务之间的RPC而受到了广泛关注。

CoreDNS is a DNS server software implementation that can be used as a drop-in replacement for the traditional BIND (Berkeley Internet Name Domain) software.

CoreDNS 是一款轻量级的 DNS 服务器，其特点是具有插件机制。它是 Kubernetes（~v1.8）中广泛使用的 SkyDNS 的继任者，并且核心开发者也是同一位 Miek Gieben 先生。在 Kubernetes v1.9 中，似乎将取代 KubeDNS。KubeDNS 使用了复杂的结构，组合了 SkyDNS、dnsmasq 等技术，而 CoreDNS 则通过插件机制进行简化实现。

containerd

容器运行时

containerd是Docker捐赠的容器运行时。containerd是一个带有gRPC接口的守护进程，用于管理容器的生命周期。最初，containerd是Docker Engine的一部分，但现在Docker Engine使用containerd作为其容器运行时。Docker Engine正在开发中，除了容器运行时，还整合了许多其他功能，但通过将其作为containerd分离，使得只能简单地使用容器运行时部分。有关Docker、containerd和runC之间的关系，containerd的官方网页上有详细介绍。

在Kubernetes中，也有一个名为cri-containerd的项目正在使用containerd作为其运行时。CRI代表Container Runtime Interface，它将Kubernetes和容器运行时的接口定义为Protocol Buffers的API。

岩石运载火箭

rkt是由CoreOS开发的容器运行时。在rkt发布时(2014年12月)，CoreOS的博客文章批评了Docker的安全模型，并宣布了rkt的开发，引起了广泛关注。rkt具有能够原生处理Pod以及不需要管理守护进程等特点，非常适合容器编排的架构。

中国国家天文台

CNI（Container Network Interface）是抽象化容器网络接口的规范。多种容器网络如Project Calico和Weave Net都支持CNI插件，可以轻松地在支持CNI的Kubernetes和rkt上使用。CNI插件以可执行二进制形式实现，并且环境变量等启动参数在CNI规范中进行定义。

使者

Envoy 是 Lyft 开发的服务网格，具有以下特点。

• C++ で書かれており高パフォーマンス

• サービスディスカバリ

• 負荷分散

• リトライ

• サーキットブレーカー

メトリクス

在为微服务提供安全服务网格的Istio中，我们使用了扩展Envoy的组件作为数据平面的一部分。

Jaeger (猎人)

Jaeger 是由 Uber 开发的分布式跟踪系统。它支持 CNCF 的项目 OpenTracing。

公证人

Notary 是一个用于验证任意内容真实性的服务器和客户端实现。The Update Framework (TUF) 已被捐赠给 CNCF。TUF 是用于软件更新的安全规范，而Notary 则是实现了TUF规范。作为Docker Content Trust的组件，Notary 用于验证Docker镜像是否由可信的提供者创建。

TUF：坚不可摧

The Update Framework (TUF) 是一种用于分发安全软件更新的规范。该规范于2009年由纽约大学的Justin Cappos教授等编写。除了通过文件签名验证其合法性外，TUF还具有每个角色的密钥、时间戳和有效期等元数据，以防止使用合法但易受攻击的旧文件进行重放攻击，并提供安全地分发最新更新的机制。其中实施了TUF的Notary也已被捐赠给CNCF。