CNCF简介
CNCF(Cloud Native Computing Foundation)于 2015 年 7 月成立,隶属于 Linux 基金会,初衷围绕“云原生”服务云计算, 力于维护和集成开源技术，支持编排容器化微服务架构应用。
CNCF项目的生命周期如下：
Graduated Projects(毕业项目)：通过incubating或者sanbox的状态达到毕业所需要的标准，或者一个新的项目不经过孵化中的状态直接成为毕业阶段的项目，必须达到孵化中阶段所有的标准之上，并且满足如下标准：
至少具在不同组织的两个或者两个以上的技术专家（committer）
获得和维持着Core Infrastructure Initiative Best Practices的徽章
完成独立的三方的安全审核，并将符合要求的结果进行公示
通过CNCF的代码准则（Code of Conduct）
显示地定义项目管控的相关流程并符合标准
对于项目的使用者具有公开的列表并满足标准
能获得TOC绝大多数的投票表决进入毕业阶段。
Incubating Projects(孵化级项目)：进入孵化阶段的项目需要满足所有Sandbox的需求，并且需要满足如下条件：
(1) 必须提供至少三个独立的终端用户成功地使用在生产环境中的资料信息，在质量和范围方面都能够得到证明，这些必须通过TOC的承认。
(2) 技术专家（committer）的数量较为健康，技术专家被定义为可以接受和承认项目其他人的贡献到项目中的人。
(3) 能够展示正在进行的后续的提交和合并的信息等
Sandbox Projects(沙箱级托管项目)：被CNCF接受并成为Sandbox项目需要至少2个TOC的sponsor的支持
Archived Projects(归档项目)：进入退出机制的"失败"项目，目前只有rkt。
以下简述几个CNCF项目。
Kubernetes
集群中管理跨多台主机容器化应用的开源系统。之前已经详细介绍，这里不赘述。
Envoy Proxy
需求背景
在传统模式下，如果微服务之间要进行通信，那么程序需要自己处理各种通信的细节。这些功能通常实现为与某种编程语言相关的库，这也导致了这样的库无法在不同的编程语言之间共享。
如果我们可以将这部分功能抽取出来，形成一个独立的进程，这样的进程称为Sidecar。通常来说，我们会将应用程序和Sidecar部署在一起，那么程序的入口流量和出口流量都会由这个 Sidecar 去代理，这样就可以通过 Sidecar 去实现服务发现、熔断机制、超时重试等功能了。
Envoy Proxy简介
Envoy Proxy可以用来充当上面提到的Sidecar进程。通常把应用程序和Envoy部署在一起，形成一个微服务。另一方面，为了实现高可用，通常一个微服务会部署多份副本，这些副本加在一起，就形成了Service Cluster。下图显示的就是服务与服务之间的通信
CoreDNS
简介
CoreDNS作为CNCF中托管的一个域名发现的项目，原生集成Kubernetes，它的目标是成为云原生的DNS服务器和服务发现的参考解决方案。Kubernetes就在集群中使用 CoreDNS解决服务发现的问题。
架构
整个CoreDNS服务都建立在一个使用Go编写的HTTP/2Web服务器Caddy上
原理
CoreDNS 可以通过四种方式对外直接提供 DNS 服务，分别是 UDP、gRPC、HTTPS 和 TLS：
TUF
简介
The Update Framework (TUF)是一个安全更新框架，帮助开发者维护软件更新系统的安全，防止各类可能传播恶意软件或破坏代码库的高强度攻击。TUF项目的主要设计目标包括：
提供可用于保护新的和现有的软件更新系统框架（框架中包含多种库、文件格式及实用工具）。
降低各类高强度攻击行为的潜在影响。
提供出色的灵活性，满足多种软件更新系统的不同需求。
易于现有软件更新系统集成。
Jaeger
简介
Jaeger是一个开源分布式追踪系统，兼容了open tracing api。
Jaeger可解决以下问题：
分布式事务监控(distributed transaction monitoring)
性能和延迟优化(performance and latency optimization)
根本原因分析(root cause analysis)
服务依赖分析(service dependency analysis)
分布式上下文传播(distributed context propagation)
架构
agent: 接收udp数据，然后通过tcp协议将数据发送给collector。
collector: 接收agent通过TCP协议发送的数据，然后写入存储
query: 接收ui的请求，然后查询Cassandra或者memory存储，然后返回给ui
Vitess
简介
Vitess是一个用于部署、扩展和管理大型MySQL实例集群的数据库解决方案。Vitess集Mysql数据库的很多重要特性和NoSQL数据库的可扩展性于一体。它的架构设计使得您可以像在物理机上一样在公共云或私有云架构中有效运行。它结合并扩展了许多重要的MySQL功能，同时兼具NoSQL数据库的可扩展性。
Vitess可以帮助解决以下问题：
支持对MySQL数据库进行分片来扩展MySQL数据库，应用程序无需做太多更改。
从物理机迁移到私有云或公共云。
部署和管理大量的MySQL实例。
自2011年以来，Vitess一直为YouTube所有的数据库提供服务，现在已被许多企业采用并应用于实际生产。
etcd
简介
etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。
应用场景
etcd比较多的应用场景是用于服务发现，服务发现(Service Discovery)要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。
服务发现就是要了解集群中是否有进程在监听udp或者tcp端口，并且通过名字就可以进行查找和链接。
NATS
简介
nats是一个开源的，云原生的消息系统。Apcera，百度，西门子，VMware，HTC和爱立信等公司都有在使用。
使用场景
高吞吐量的消息分散 —— 少数的生产者需要将数据发送给很多的消费者。
寻址和发现 —— 将数据发送给特定的应用实例，设备或者用户，也可用于发现并连接到基础架构中的实例，设备或用户。
命令和控制（控制面板）—— 向程序或设备发送指令，并从程序/设备中接收状态，如SCADA，卫星遥感，物联网等。
负载均衡 —— 主要应用于程序会生成大量的请求，且可动态伸缩程序实例。
N路可扩展性 —— 通信基础架构能够充分利用go的高效并发/调度机制，以增强水平和垂直的扩展性。
位置透明 —— 程序在各个地理位置上分布者大量实例，且你无法了解到程序之间的端点配置详情，及他们所生产或消费的数据。
容错
CloudEvents
CloudEvents 是一种规范，用于以通用格式描述事件数据，以提供跨服务、平台和系统的交互能力。
Prometheus
简介
Prometheus是一套开源的监控、报警和时间序列数据库的组合，使用go开发，能够监控 Mesos、Docker、OpenStack 等等平台的应用程序。
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发。
监控的目标
Google指出，监控分为白盒监控和黑盒监控之分。
白盒监控： 通过监控内部的运行状态及指标判断可能会发生的问题，从而做出预判或对其进行优化。
黑盒监控： 监控系统或服务，在发生异常时做出相应措施。
通过建立完善的监控体系，达到以下目的：
长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。
告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。
故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。
数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。
与常见监控系统比较
常用的监控系统的不足
常用的监控系统(如Nagios、Zabbix)往往并不能很好的解决上述问题。
例如对于Nagios而言，大部分的监控能力都是围绕系统的一些边缘性的问题，主要针对系统服务和资源的状态以及应用程序的可用性。
对于Nagios这类系统而言，其核心是采用了测试和告警(check&alert)的监控系统模型。 对于基于这类模型的监控系统而言往往存在以下问题：
与业务脱离的监控：监控系统获取到的监控指标与业务本身也是一种分离的关系。好比客户可能关注的是服务的可用性、服务的SLA等级，而监控系统却只能根据系统负载去产生告警；
运维管理难度大：Nagios这一类监控系统本身运维管理难度就比较大，需要有专业的人员进行安装，配置和管理，而且过程并不简单；
可扩展性低： 监控系统自身难以扩展，以适应监控规模的变化；
问题定位难度大：当问题产生之后（比如主机负载异常增加）对于用户而言，他们看到的依然是一个黑盒，他们无法了解主机上服务真正的运行情况，因此当故障发生后，这些告警信息并不能有效的支持用户对于故障根源问题的分析和定位。
Prometheus的优势
- 易于管理
Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。
- 监控服务的内部运行状态
Pometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。
- 强大的数据模型
所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。
- 强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL。 通过PromQL可以实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中。
- 高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单一Prometheus Server实例而言它可以处理：
数以百万的监控指标
每秒处理数十万的数据点。
6. 可扩展
可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus对于联邦集群的支持，可以让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。
- 易于集成
使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。
- 可视化
Prometheus Server中自带的Prometheus UI可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。
gRPC
gRPC简介
概括：A high-performance, open-source universal RPC framework
gRPC 是一个现代化高性能开源远程过程调用（RPC）框架。CoreOS 的分布式键值存储 etcd 就使用了 gRPC 进行点对点通讯
什么是RPC
RPC(remote procedure call 远程过程调用)框架实际是提供了一套机制，使得应用程序之间可以进行通信，而且也遵从server/client模型。使用的时候客户端调用server端提供的接口就像是调用本地的函数一样。
特性
基于HTTP/2
HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP链接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。
IDL使用ProtoBuf
gRPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
多语言支持（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java）
gRPC支持多种语言，并能够基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言，grpc-java已经支持Android开发。
gRPC优势
gRPC已经成为Kubernetes生态的事实标准，而Kubernetes又是容器编排的事实标准。
使用高效的protobuf作为协议payload，节约网络带宽
多语言框架集成，通过Java、Go等语言的静态类型特性，直接避免了拼写错误等问题
方便扩展接入，如果需要对一个第三方组件进行扩展，只要一个.proto文件，就自动得到了一个脚手架
OpenTracing
需求背景
在一个分布式系统中，一个业务操作往往需要协调多个节点来完成。例如最简单的查询用户数据的操作也会涉及到应用服务，数据库服务，缓存服务三个节点。由于每个节点上记录和输出的信息若不具备统一标准，则很难准跟踪现业务操作在各节点上的执行情况。而操作数据跟踪在分布式系统，特别是微服务架构的分布式系统中尤为重要。
在广义上，一个trace代表了一个事务或者流程在（分布式）系统中的执行过程。在OpenTracing标准中，trace是多个span组成的一个有向无环图（DAG），每一个span代表trace中被命名并计时的连续性的执行片段。
下图是一个典型的trace案例：
挑战
在一个分布式系统中，实现完整的会话跟踪是具有相当挑战的，因为跟踪器必须在进程内和进程间传播跟踪上下文，这涉及到应用系统的每个部分。要求所有的开源软件和应用程序使用单一的跟踪服务提供商是不可能的，因此我们需要单一的标准机制来描述系统行为。
OpenTracing简介
OpenTracing为解决上述困境提供了开发商独立的标准，且已有众多开源软件集成支持。
OpenTracing 是源自 Zipkin 的规范，以提供跨平台兼容性。它提供了对厂商中立的 API，用来向应用程序添加追踪功能并将追踪数据发送到分布式的追踪系统。按照 OpenTracing 规范编写的库，可以被任何兼容 OpenTracing 的系统使用。采用这个开放标准的开源工具有 Zipkin、Jaeger 和 Appdash 等。
Fluentd
随着应用程序的数量和公司规模的增长（尤其是越来越多的服务被容器化），在一个地方收集、分析和查询结构化日志是非常重要的。这就是Fluentd的初衷。
Fluentd是一个针对日志的收集、处理、转发系统。通过丰富的插件系统，可以收集来自于各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统之中。
Linkerd
Linkerd 是一个实现了service mesh设计的开源项目。其核心是一个透明代理，可以用它来实现一个专用的基础设施层以提供服务间的通信，进而为软件应用提供服务发现、路由、错误处理以及服务可见性等功能，而无需侵入应用内部本身的实现。
Containerd
简介
Containerd是容器虚拟化技术，从docker中剥离出来，形成开放容器接口（OCI）标准的一部分。
Docker对容器的管理和操作基本都是通过containerd完成的。Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。
详细地说，Containerd 负责干下面这些事情：
管理容器的生命周期(从创建容器到销毁容器)
拉取/推送容器镜像
存储管理(管理镜像及容器数据的存储)
调用 runC 运行容器(与 runC 等容器运行时交互)
管理容器网络接口及网络
Containerd的意义
由于在操作系统内核中，没有容器的实现，因此容器需要结合多个os内核的特性。在构建大型分布式系统平台时，开发者往往需要在他们的代码和系统调用之间构建一个抽象层(个人理解，containerd是为了屏蔽掉不同os的系统api之间的差异，为上层的容器提供统一的调用接口)。
containerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
Containerd和容器编排系统的关系
下图可以看出containerd在容器技术生态中的位置。
RKT
简介
RKT是一个pod原生(pod-native)的容器，是一种类似docker的容器引擎。
rkt 最早是由 CoreOS 公司创建的，而 CoreOS 最早应该也算是 Docker 的用户之一。但是随着 Docker 发展的日趋壮大，CoreOS 就想要脱离 Docker，成立自己的标准。
主要特征
(1)原生支持Pod：Rkt和Kubernetes联系更紧密，基本执行单元是Kubernetes中的Pod，将资源和用户应用连接在一起。
(2)安全：Rkt的开发原则是默认安全，具有一系列安全特征，例如支持SELinux、TPM和在硬件隔离的虚拟机中运行。Rkt包含权限拆分功能，旨在避免不必要的以root权限运行的操作，同时提供默认的签名验证与其它出于安全性考虑的先进功能。
(3)可组合性：采用了无后台守护程序模式，意味着能够轻松与标准init系统相集成，例如systemd与upstart，或者其它集群编排系统，例如Nomad与Kubernetes。
(4)开放标准和兼容性：Rkt实现了AppC规范，支持 Container Networking Interface specification，镜像格式为App Container Image，简称ACI，也可以运行Docker镜像。
TiKV
简介
TiKV 最初于 2016 年在 PingCAP 开发，是一个开源分布式事务键值数据库, 采用 Rust 构建，由 Raft（通过 etcd）驱动，并受到 Google Spanner 设计的激励，提供简化的调度和自动平衡，而不依赖于任何分布式文件系统。TiKV 是一个开源、统一分布式存储层，支持功能强大的数据一致性、分布式事务、水平可扩展性和云原生架构。
Dragonfly
简介
Dragonfly是一个由阿里巴巴开源的云原生镜像/文件分发系统，主要解决云原生领域以 Kubernetes为核心的应用镜像分发问题。
组成
该项目由以下三个主要部分组成：
SuperNode 扮演*调度器角色，控制 peer 之间的所有分发过程；
dfget 是 P2P 客户端，主要负责 peer 之间分块的互传；
dfdaemon 则扮演代理角色，拦截容器引擎的镜像下载请求并重定向到 dfget 中。
主要特性
基于 P2P 的文件分发：使用 P2P 技术进行文件传输，Dragonfly 可以充分利用每个对等端的带宽资源来提高下载效率，节省了大量的 IDC 带宽，尤其是昂贵的跨地区、跨国际带宽；
对各种容器技术的无侵入支持：Dragonfly 可以无缝地支持各种容器来分发镜像，如 Docker、containerd 等；
主机级别速度限制：很多下载工具（wget / curl）仅具有当前下载任务的速率限制，但是 Dragonfly 提供整个主机的速率限制；
被动式 CDN：可以避免重复的远程下载。