CNCF云原生景观初学者指南

这个博客最初是由Ayrat Khayretdinov在CloudOps博客上发布
云原生景观可能会很复杂和混乱。无数的开源项目都得到了一个充满活力和广阔社区的持续贡献的支持。云原生计算基金会（CNCF）有一幅景观图，展示了云原生解决方案的全部范围，其中许多都在他们的保护伞下。
作为CNCF大使，我积极致力于在加拿大各地推广社区活动和云原生教育。在CloudOps里，我领导了Docker和Kubernetes的研讨会，提供了云原生技术的介绍，并帮助DevOps团队操作他们的应用程序。
我还组织了Kubernetes和云原生meetup来介绍来自世界各地的演讲者，代表各种项目。它们每季度在蒙特利尔、渥太华、多伦多、基奇纳 - 滑铁卢和魁北克市运营。通过@archyufaor联系我或电邮到CloudOps，了解更多关于成为云原生的信息。
与此同时，我还编写了一个关于云原生景观的初学者指南。我希望它能帮助你理解风景，让你更好地了解如何驾驭它。
CNCF的历史

2014年，谷歌开源了一个名为Borg的内部项目，他们一直在使用它来编排容器。由于没有地方来进行这个项目，谷歌与Linux基金会合作创建了云原生计算基金会（CNCF），这将鼓励Kubernetes和其他云原生解决方案的开发和协作。Borg实现在Go中被重写，重新命名为Kubernetes，并作为初始化项目捐赠。很早就很清楚，Kubernetes只是一个开始，一群新项目将加入CNCF，扩展Kubernetes的功能。
CNCF任务
CNCF通过为最终用户社区提供构建云原生应用程序的可行选项，促进了开源项目的发展。通过鼓励项目之间的合作，CNCF希望使完全成熟的技术栈仅由CNCF成员项目组成。这是组织在云中拥有自己命运的一种方式。
CNCF流程
共有25个项目跟随Kubernetes并被CNCF采用。为了加入，项目必须由技术监督委员会（TOC）以绝对多数选出并选出。投票过程得到了一个由TOC贡献者组成的健康社区的帮助，他们是CNCF会员公司的代表，包括我自己。成员项目将根据其代码成熟度级别加入沙箱、孵化或毕业阶段。
沙箱项目处于非常早期的阶段，在部署到生产环境之前，需要大量的代码成熟度和社区参与。它们之所以被采用，是因为它们提供了尚未实现的潜力。CNCF的指导方针指出，CNCF有助于鼓励沙盒项目的公共可见性，并促进它们与现有项目的结合。沙盒项目从CNCF获得的资金和营销支持很少，每12个月就要进行审查和可能的移除。
当项目满足所有沙盒标准，并显示出某些增长和成熟度特征时，就进入孵化阶段。它们必须在至少三家公司的产品中使用，维护健康的团队，以批准和接受包含社区新特性和代码的健康的贡献流。
一旦孵化项目在生产使用中达到了一个临界点，TOC可以投票决定它们是否达到了毕业阶段。毕业项目必须证明其使用率高，并符合所有孵化标准。他们还必须有来自至少两个组织的提交者，有文档化的和结构化的治理过程，并且符合Linux Foundation Core Infrastructure Initiative的最佳实践标记。到目前为止，只有Kubernetes和Prometheus毕业。
项目本身
下面我将项目分为12类：编排、应用程序开发、监视、日志记录、跟踪、容器仓库、存储和数据库、运行引擎、服务发现、服务网格、服务代理、安全性、流和消息传递。提供的信息可以帮助公司或个人评估每个项目的工作，项目如何与其他CNCF项目进行整合，了解其发展和现状。
编排

Kubernetes（毕业） - Kubernetes自动化了容器应用程序的部署、扩展和管理，强调了自动化和声明性配置。在古希腊，它的意思是舵手。Kubernetes编排容器，这些容器是可移植和模块化微服务的包。Kubernetes添加了一个抽象层，将容器分组到pod中。Kubernetes帮助工程师安排工作负载，并允许在多云环境上按比例部署容器。毕业后，Kubernetes已经达到了一个关键的采用率。在CNCF最近的一项调查中，来自企业公司的40%以上的受访者在生产中使用Kubernetes。
应用程序开发

Helm（孵化） - Helm是一个应用程序包管理器，允许用户轻松查找、共享、安装和升级Kubernetes应用程序（又名图表charts）。它帮助终端用户使用KubeApps Hub部署现有的应用程序（包括MySQL、Jenkins、Artifactory等），KubeApps Hub显示来自Kubernetes社区维护的stable和incubator存储库的图表。有了Helm，你可以安装运行在Kubernetes之上的所有其他CNCF项目。Helm还可以让组织创建并部署定制应用程序或微服务到Kubernetes。这涉及到使用不适合在不同环境或CI/CD管道中部署的数值创建YAML清单。Helm创建单个图表，这些图表可以基于应用程序或配置更改进行版本化，部署在各种环境中，并在组织间共享。
Helm起源于Deis，试图为Kubernetes用户创造一种“自制”体验。Helm V2由目前Helm项目的客户端组成。服务器端“tiller舵柄”（Helm V2）是Deis与谷歌合作添加的，大约在Kubernetes 1.2同一时间发布的。这就是Helm成为在Kubernetes之上部署应用程序的标准方式。
Helm目前正在进行一系列的修改和更新，为Helm V3的发布做准备，预计该版本将在今年年底发布。依靠Helm进行日常CI/CD开发的公司，包括Reddit、育碧（Ubisoft）和耐克（Nike），都对重新设计进行改进提交建议。

Telepresence（沙箱） - 在Kubernetes上开发容器应用程序是一个挑战。本地开发的流行工具包括Docker Compose和Minikube。不幸的是，当今大多数云原生应用程序都是资源密集型的，涉及到多个数据库、服务和依赖关系。此外，模拟云依赖关系可能很复杂，例如Compose和Minikube中的消息传递系统和数据库。另一种方法是使用完全远程的Kubernetes集群，但这将阻止你使用本地工具（例如IDE、调试器）进行开发，并创建缓慢的开发者“内部循环”，使开发者等待CI测试更改。
由Datawire开发的Telepresence提供了两方面的优点。它允许开发者在本地运行单个微服务以进行开发，同时保持与运行其应用程序其余部分的远程Kubernetes集群的连接，从而实行“活代码”。Telepresence部署在远程Kubernetes集群上包含双向网络代理的pod。这将本地机器连接到代理。远程呈现实现了现实的开发/测试环境，而无需冻结用于编码、调试和编辑的本地工具。
监控

Prometheus（毕业） — 跟随Kubernetes的脚步，Prometheus是第二个加入CNCF的项目，也是第二个（也是到目前为止最后一个）已经毕业的项目。它是一个适合于动态云和容器环境的监视解决方案。它的灵感来自于谷歌的监控系统Borgman。Prometheus是一个基于拉的系统 — 它的配置决定了什么时候刮什么。这与使用基于推的方法的其他监视系统不同，在这种方法中，监视代理在节点上运行。Prometheus在TSDB存储数据。Prometheus允许你在Grafana仪表板里用强大的查询语言（比如PromQL）创建有意义的图形。你还可以使用内置的Alert Manager生成并向各种目的地发送警报，例如slack和email。
非常成功，Prometheus已经成为云原生度量监视的事实上的标准。使用Prometheus可以监测VM、Kubernetes集群和微服务在任何地方运行，尤其是在像Kubernetes这样的动态系统中。Prometheus的度量还通过利用Kubernetes的特性（包括HPA、VPA和集群自动缩放）来自动化缩放决策。Prometheus可以监控其他CNCF项目，如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的exporter与许多其他应用程序和分布式系统集成。使用Prometheus的官方Helm Chart来开始。

OpenMetrics（沙箱） — OpenMetrics为应用程序的度量呈示格式创建中立标准。它的现代度量标准允许用户大规模传输度量。OpenMetrics基于流行的Prometheus exposition格式，该格式现有超过300个出口商，其基础是Borgmon的运营经验。Borgman实现了“白盒监控”和大量数据收集，并降低了开销。在OpenMetrics之前，监视环境主要基于过时的标准和技术（比如SNMP），这些标准和技术使用专有格式，并且很少关注于指标。OpenMetrics构建在Prometheus呈示格式的基础上，但是具有更紧凑、更清晰和更强的语法。虽然OpenMetrics只处于沙箱阶段，但它已经被AppOptics、 Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司所使用。

Cortex（沙箱） - 操作简单一直是Prometheus的主要设计目标。因此，Prometheus本身只能在不集群的情况下运行（作为单个节点或容器），并且只能使用本地存储，而不是设计为持久或长期的存储。集群和分布式存储带来了额外的操作复杂性，Prometheus为了简化而放弃了这种复杂性。Cortex是一个可横向扩展、多租户、长期存储的解决方案，可以与Prometheus互补。它允许大型企业使用Prometheus，同时保持对HA（高可用性）和长期存储的访问。目前在这个领域还有其他一些项目正在获得社区的关注，比如Thanos、Timbala和M3DB。然而，Cortex已经在GrafanaLabs和Weaveworks上作为SaaS产品进行了实战测试，EA和StorageOS也在本地部署了Cortex。
日志和跟踪

Fluentd（孵化） — Fluentd收集、解释和传输应用程序日志数据。它统一了数据收集和消费，因此你可以更好地使用和理解你的数据。Fluentd将数据构造为JSON，并将跨多个源和目的地收集、过滤、缓冲和输出日志集在一起。Fluentd可以从VM和传统应用程序收集日志，但是它在运行微服务的Kubernetes之上的云原生环境中非常出色，在这里应用程序是以动态方式创建的。
Fluentd在Kubernetes中作为daemonset（运行在每个节点上的工作负载）运行。它不仅从作为容器运行的所有应用程序（包括CNCF）中收集日志，并向STDOUT发出日志。Fluentd还解析和缓冲传入的日志条目，并将格式化的日志发送到配置的目的地，例如Elasticsearch、Hadoop和Mongo，以进行进一步的处理。
Fluentd最初是用Ruby编写的，在运行时占用了超过50Mb的内存，因此不适合在sidecar模式的容器旁边运行。Fluentbit是与Fluentd一起开发的一种解决方案。Fluentbit是用C编写的，在运行时只在内存中使用少量Kb。Fluentd在CPU和内存使用方面更高效，但其特性比Fluentd更有限。Fluentd最初是由Treasuredata作为一个开源项目开发的。
Fluentd可以作为Kubernetes插件使用，可以部署为版本0.12，这是一个更老、更稳定的版本，目前在生产中广泛部署。新版本（版本1.X）是最近开发的，有很多改进，包括新的插件API、纳秒分辨率和windows支持。Fluentd正在成为云原生空间中日志收集的标准，并且是CNCF毕业的可靠候选者。

OpenTracing（孵化） — 不要低估分布式跟踪对于大规模构建微服务的重要性。开发者必须能够查看每个事务并理解其微服务的行为。但是，分布式跟踪可能具有挑战性，因为工具必须在整个服务、包和特定于应用程序的代码中传播跟踪上下文。OpenTracing允许应用程序代码、OSS包和OSS服务的开发者在不锁定任何特定的跟踪供应商的情况下测量自己的代码。OpenTracing为应用程序和OSS包提供了分布式跟踪标准，这些包具有独立于供应商的API，库有九种语言。这些实现了分布式跟踪，使OpenTracing成为服务网格和分布式系统的理想工具。OpenTracing本身并不是一个跟踪系统通过在UI中运行跟踪来分析跨度。它是一个与应用程序业务逻辑、框架和现有工具一起工作的API，用于创建、传播和标记范围。它与开源（如Jaeger, Zipkin）和商业（如Instana、Datadog）中的跟踪解决方案，并创建被存储在后端或扩展为UI格式的跟踪。

Jaeger（孵化） — Jaeger是一个分布式跟踪系统解决方案，与OpenTracing兼容，最初由Uber开发并进行实战测试。它的发音是yā′gər，是猎人的意思。它的灵感来自于谷歌的内部跟踪系统Dapper和Zipkin，后者是一种可替代的开源跟踪系统，由Twitter编写，但基于OpenTracing标准构建。Zipkin对opentrace集成的支持是有限的，但是Jaeger确实通过通过HTTP接受Zipkin格式的跨来提供与Zipkin的向后兼容性。Jaeger的用例监视和故障诊断基于微服务的发行版，提供分布式上下文传播、分布式事务监视、根本原因分析、服务依赖分析以及性能和延迟优化。Jaeger的数据模型和仪器库与opentrace兼容。它的现代Web UI是用React/Javascript构建的，后端有多种支持。这包括Cassandra、Elasticsearch和memory。Jaeger与包括Istio和Linkerd在内的服务网格集成，使得跟踪检测更加容易。
Jaeger之所以具有可观察性，是因为它默认公开了Prometheus指标，并与Fluentd集成，用于发送日志。开始使用Helm chart或最近开发的Jaeger Operator部署Jaeger到Kubernetes。Jaeger代码库的大部分贡献来自优步和RedHat，但有数百家公司采用Jaeger来进行云原生的、基于微服务的分布式跟踪。
容器仓库

Harbor（沙盒） - Harbor是一个开源可信的容器仓库，它存储、标识和扫描docker镜像。它提供了免费的、增强的docker仓库特性和功能。其中包括具有基于角色的访问控制（RBAC）和LDAP支持的web接口。它与CoreOS开发的用于漏洞扫描的开源项目Clair和下面描述的CNCF孵化项目Notary集成，用于内容信任。Harbor提供活动审计、Helm chart 管理和从一个Harbor实例复制镜像到另一个实例实现HA和DR。Harbor最初是VMWare作为开源解决方案开发的。它现在被许多公司使用，包括TrendMicro、Rancher、Pivotal和AXA。
存储和数据库

Rook（孵化） — Rook是Kubernetes的一个开源云原生存储编排器。有了Rook，ops团队可以在Kubernetes之上运行软件分布式系统（SDS，如Ceph）。然后，开发者可以使用该存储在Kubernetes中动态创建持久卷（PV）来部署应用程序，例如Jenkins、WordPress和任何其他需要状态的应用程序。Ceph是一个流行的开源SDS，它可以提供许多流行类型的存储系统，比如对象、块和文件系统，并且可以在普通硬件上运行。虽然可以在Kubernetes之外运行Ceph集群并使用CSI插件将其连接到Kubernetes，但是在硬件上部署和操作Ceph集群是一项具有挑战性的任务，从而降低了系统的受欢迎程度。Rook使用自定义资源定义（CRD）将Ceph作为第一等对象部署并集成到Kubernetes中，并使用Operator框架将其转换为自管理、自伸缩和自修复存储服务。Kubernetes Operator的目标是将人类的操作知识编码到软件中，使其更容易打包并与最终用户共享。与Helm侧重于打包和部署Kubernetes应用程序相比，Operator可以部署和管理复杂应用程序的生命周期。在Ceph的情况下，Rook Operator可以自动化存储管理员任务，例如部署、引导、配置、供应、水平缩放、修复、升级、备份、灾难恢复和监视。最初，Rook Operator的实现只支持Ceph。在0.8版本中，Ceph的支持被转移到Beta版本。Rook项目稍后宣布针对存储提供商的Rook框架，它将Rook扩展为通用云原生存储编排器，支持具有可重用规范、逻辑、策略和测试的多个存储解决方案。目前，Rook支持CockroachDB、Minio、NFS，都在alpha，和未来支持Cassandra、Nexenta和Alluxio。使用Rook Operator和Ceph进行生产的公司越来越多，尤其是在本地部署的公司，其中包括CENGN、Gini、RPR和许多处于评估阶段的公司。

Vitess（孵化） - Vitess是数据库的中间件。它使用通用分片在MySQL实例间分发数据。它可以水平伸缩，并且可以无限伸缩，而不会影响你的应用程序。当你的碎片达到满负荷时，Vitess将以零停机时间和良好的观察性重新划分底层数据库。Vitess解决了与事务性数据相关的许多问题，事务性数据还在不断增长。

TiKV（沙箱） - TiKV是一个提供简化调度和自动平衡的事务性键值数据库。它充当一个分布式存储层，支持强数据一致性、分布式事务和水平可伸缩性。TiKV的设计灵感来自于谷歌Spanner和HBase，但它的优点是没有分布式文件系统。TiKV由PingCAP开发，目前有来自三星、腾讯云和UCloud的贡献者。
运行引擎

RKT（孵化） - RKT（读作Rocket）是一个最初在CoreOS开发的应用程序容器运行引擎。当Docker是Kubernetes的默认运行并被整合到kubelet中时，Kubernetes和Docker社区在互相协作方面遇到了挑战。Docker Inc.是开发Docker作为开源软件的公司，它有自己的路线图，并为Docker增加了复杂性。例如，他们正在添加集群模式或将文件系统从AUFS更改为overlay2，而没有提供通知。这些更改通常与Kubernetes社区以及复杂的路线图规划和发布日期没有很好地协调。到最后，Kubernetes用户需要一个简单的运行引擎，它可以启动和停止容器，并为扩展、升级和正常运行时间提供功能。使用RKT，CoreOS打算为Docker创建一个替代运行引擎，该运行引擎是特意构建来与Kubernetes一起运行的。这最终导致了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器运行接口（CRI），它可以连接任何类型的容器并从其核心删除Docker代码。RKT可以同时使用OCI镜像和Docker格式镜像。虽然RKT对Kubernetes生态系统产生了积极的影响，但是这个项目从来没有被最终用户采用过，特别是那些习惯于docker cli并且不想学习打包应用程序的替代方案的开发这。此外，由于Kubernetes的流行，有大量的容器解决方案竞争这个利基。像gvisor和crio（基于OCI）这样的项目最近越来越受欢迎，而RKT则失去了它的地位。这使得RKT成为从CNCF孵化阶段移除的潜在候选对象。

Containerd（孵化） — Containerd是一种强调简单性、健壮性和可移植性的容器运行引擎。与RKT相反，Containerd设计为嵌入到更大的系统中，而不是直接由开发者或最终用户使用。类似于RKT，Containerd可以同时使用OCI和Docker镜像格式。Containerd是Docker项目向CNCF捐赠的。以前，Docker的平台是一个单一的应用程序。然而，随着时间的推移，由于添加了一些特性，如群模式，它成为了一个复杂的系统。不断增加的复杂性使得Docker越来越难以管理，如果你使用Docker与需要简单性的Kubernetes等系统一起使用，那么它的复杂特性就是冗余的。因此，Kubernetes开始寻找替代的运行引擎，例如RKT，以取代docker作为默认的容器运行引擎。Docker项目随后决定将自己拆分为松散耦合的组件，并采用更模块化的体系结构。这以前被称为Moby项目，其中容器被用作核心运行功能。由于Moby项目，Containerd后来通过称为cri-containerd的CRI接口与Kubernetes集成。然而，cri-containerd不再需要了，因为containerd自带内置CRI插件，默认情况下从Kubernetes 1.10开始启用，可以避免任何额外的grpc跳转。尽管containerd在Kubernetes生态系统中占有一席之地，但crio（基于OCI）和gvisor等项目近来越来越受欢迎，containerd正在失去社区兴趣。然而，它仍然是Docker平台不可分割的一部分。
服务发现

CoreDNS（孵化） — CoreDNS是一个DNS服务器，在云原生部署中提供服务发现。CoreDNS是Kubernetes中一个默认的集群DNS，从1.12版本发布开始。在此之前，Kubernetes使用的是SkyDNS，它本身就是Caddy和后来的KubeDNS的一个分支。SkyDNS是一个动态的基于DNS的服务发现解决方案，它具有不灵活的体系结构，使得添加新功能或扩展变得困难。Kubernetes后来使用了KubeDNS，它作为3个容器（kube-dns, dnsmasq, sidecar）运行，容易出现dnsmasq漏洞，并且使用新的功能扩展DNS系统有类似的问题。另一方面，CoreDNS是用Go从头重写的，是一个灵活的基于插件的、可扩展的DNS解决方案。它在Kubernetes内部运行一个容器，对比KubeDNS，后者有三个容器运行。它不存在漏洞，可以使用ConfigMap动态更新配置。此外，CoreDNS修复了由于其严格的设计而引入的许多KubeDNS问题（例如，经过验证的Pod记录）。CoreDNS的架构允许你使用插件添加或删除功能。目前，CoreDNS有超过30个插件和超过20个外部插件。通过链接插件，你可以使用Prometheus进行监视，使用Jaeger进行跟踪，使用Fluentd进行日志记录，使用K8s API或etcd进行配置，以及支持高级dns功能和集成。
服务网格

Linkerd（孵化） - Linkerd是一个开源网络代理，设计为部署为服务网格，这是一个专用层，用于管理、控制和监视应用程序内的服务到服务通信。Linkerd通过可编程配置电路制动、速率限制、超时和重试，在不改变应用程序代码的情况下提高应用程序的容错性，帮助开发者大规模地运行微服务。它还通过Zipkin提供了对微服务的可见性。最后，它还提供了先进的交通控制设备来支持灰度发布、阶段和蓝绿部署。SecOps团队将欣赏Linkerd通过TLS透明地加密Kubernetes集群中所有跨节点通信的能力。Linkerd是建立在Twitter的Finagle项目之上的，它有广泛的生产使用，吸引了许多公司的兴趣，探索服务网格。现在Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。Linkerd服务网格作为DaemonSet部署在Kubernetes上，这意味着它在集群的每个节点上运行一个Linkerd pod。
服务网格生态系统的最近变化（如Istio项目的引入与Kubernetes紧密结合，使用轻量级代理Envoy作为sidecar与每个微服务一起运行）可以提供比Linkerd更多的功能，并且大大降低了它的受欢迎程度。一些人甚至质疑Linkerd的存在。为了重新赢得社区的兴趣并支持现有客户的大量基础，Buoyant（Linkerd背后的公司）宣布了Conduit项目，该项目允许DaemonSet使用Istio采用的sidecar模式，并使用Rust重写dataplane和Go重写Control plane。这使得许多可能的特性可以使用sidecar方法。不久前，Conduit项目还被重新命名为Linkerd 2.0，并在最近发布了GA，标志着它已经准备好投入生产使用。服务网格继续以快速的速度发展，Istio和Linkerd2等项目将是其核心。
服务代理

Envoy（孵化） — Envoy是一个现代的边缘和服务代理设计的云原生应用。它是一个与供应商无关的、高性能的、轻量级的（用C++编写的）产品级别代理，在Lyft里进行了开发和战斗测试。Envoy现在是CNCF孵化项目。Envoy提供了微服务的容错能力（超时、安全、重试、断路），而不需要改变任何现有的应用程序代码行。它通过与Prometheus、Fluentd、Jaeger和Kiali的集成，自动地了解微服务之间发生了什么。Envoy还可以作为一个边缘代理（如Kubernetes的L7 Ingress控制器），因为能够执行交通路由和分割，以及区域感知负载平衡与failovers。
虽然服务代理领域已经有了很多选择，但Envoy这个新成员引起了人们对服务网格和现代负载平衡的兴趣和革命性想法。Heptio发布了Contour项目，这是一个Kubernetes的入口控制器，通过部署Envoy代理作为反向代理和负载平衡器来工作。Contour支持动态配置更新和多团队Kubernetes集群，可以限制可以配置虚拟主机和TLS凭证以及提供高级负载平衡策略的命名空间。另一个核心使用Envoy的项目是Datawires Ambassador — 一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的，所以它是一个超轻量的，在Kubernetes内部运行的sidecar模式是完美的候选，并且与它的API驱动的配置更新风格相结合，已经成为服务网格数据板的完美候选。首先，服务网格Istio宣布Envoy是其dataplane的默认服务代理，Envoy代理在Kubernetes中使用sidecar模式与每个实例一起部署。它创建一个透明的服务网格，由Istio的控制平面控制和配置。这种方法与Linkerd v1中使用的DaemonSet模式相比较，它为每个服务提供可见性，并且能够为Kubernetes甚至混合云场景中的每个服务创建安全的TLS。最近，Hashicorp宣布其开源项目Consul Connect将使用Envoy来建立微服务之间的安全TLS连接。
现在Envoy拥有一个庞大而活跃的开源社区，它背后没有任何供应商或商业项目的驱动。如果你想开始使用Envoy，可以尝试Istio，Ambassador或Contour或加入Envoy社区于2018年12月10日在KubeCon（西雅图，华盛顿州）举行的首届EnvoyCon。
安全

Falco（沙箱） - Falco是Sysdig开发的开源运行安全工具。它的设计目的是检测kubernetes编排系统中的异常活动和入侵。Falco更像是一种审计工具，而不是执行工具（例如SecComp或AppArmor）。它在用户空间中运行，使用Sysdig内核模块检索系统调用。
Falco在Kubernetes内部作为一个DaemonSet运行，它带有一组预先配置的规则，这些规则定义要注意的行为和事件。根据这些规则，Falco可以检测并向任何进行Linux系统调用的行为（例如shell在容器中运行，或者在进行出站网络连接的二进制文件中运行）添加警报。这些事件可以通过Fluentd在STDERR上捕获，然后发送到ElasticSearch寻找过滤或Slack。这可以帮助组织迅速应对安全事件，如容器的攻击和破坏，并减少此类事件造成的经济损失。
随着Falco在CNCF沙箱上的加入，我们希望未来能与其他CNCF项目有更紧密的整合。要开始使用Falco，请找到一个正式的Helm Chart。

SPIFFE（沙箱） - SPIFFE提供了一个安全的生产身份框架。通过验证身份，它支持工作负载之间的通信。它是策略驱动的，API驱动的，可以完全自动化。它是构建工作负载之间信任的复杂问题的云原生解决方案，随着工作负载的弹性伸缩和动态调度，工作负载信任变得困难甚至危险。SPIFFE是一个相对较新的项目，但它的设计与SPIRE紧密结合。

SPIRE（沙箱） - SPIRE是SPIFFE的运行环境。它是一组可以集成到云提供商和中间件层的软件组件。SPIRE有一个模块化的架构，支持多种平台。特别是Spiffe和SPIRE周围的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持SPIFFE IDs，因此它可以用于钥匙和旋转。SPIFFE和SPIRE都在沙箱阶段。

TUF（孵化） - TUF是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。TUF帮助解决内容信任问题，这可能是一个主要的安全问题。它有助于验证软件的出处，并验证它只使用了最新版本。TUF项目在下面描述的Notary项目中扮演了许多非常重要的角色。许多公司也在生产中使用它，包括Docker、DigitalOcean、Flynn、Cloudflare和VMware，以构建其内部工具和产品。

Notary（孵化） - Notary是一种安全的软件发行实现。本质上，Notary是基于TUF的，确保所有拉出的docker镜像在你的CI/CD工作流的任何阶段都是签名的、正确的和未篡改的镜像版本，这是Kubernetes系统中基于Docker的部署的主要安全问题之一。Notary发布和管理可信的内容集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于现代Linux系统中提供的软件存储库管理工具，但用于Docker镜像。Notary的一些目标包括保证镜像的新鲜度（总是有最新的内容以避免漏洞）、用户之间的信任委托或通过不可信的镜像或传输通道的可信分发。虽然TUF和Notary通常不被终端用户使用，但是他们的解决方案集成到各种商业产品或开源项目中，用于内容签名或可信发行版的镜像签名，例如Harbor、Docker企业版仓库、Quay企业版、Aqua。在这领域另一个有趣的开源项目是Grafeas，对元数据提供开源的API，可以用于存储“证明”或镜像签名，然后可以作为允许控制检查的一部分，用于GCP的容器分析API和二进制授权产品，以及JFrog和AquaSec的产品。

Open Policy Agent（沙箱） — 通过强制声明指定策略，开放策略代理（OPA）允许不同类型的策略跨技术堆栈分布，并在不重新编译或重新部署的情况下自动执行更新。OPA位于应用程序和平台层，通过从服务发送查询来为策略决策提供信息来运行。它很好地与Docker、Kubernetes、Istio等集成。
流和消息传递

NATS（孵化） — NATS是一个消息传递服务，关注于中间件，允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术是HA，它的基于日志的流式传输保证了对历史数据的回放和所有消息的接收。NATS有一个相对简单的API，支持多种技术用例，包括云中的消息传递（通用消息传递、微服务传输、控制平面和服务发现）和物联网消息传递。与上面列出的用于日志记录、监视和跟踪的解决方案不同，NATS在应用层工作。

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

CloudEvents（沙箱） — CloudEvents为开发者提供了一种通用的方法来描述发生在多云环境中的事件。通过提供描述事件数据的规范，CloudEvents简化了跨服务和平台的事件声明和交付。还处于沙箱阶段的CloudEvents应该会大大提高应用程序的可移植性和生产率。
接下来是什么？
云原生生态系统继续以较快的速度增长。在不久的将来，将会有更多的项目被投入沙箱，从而有机会获得社区的兴趣和关注。我们希望与基础设施相关的项目，比如Vitess、NATS和Rook将不断从CNCF得到关注和支持，因为他们将是本地云原生部署的重要推动者。我们希望CNCF将继续关注的另一个地方是云原生持续交付，这块目前生态系统是空白。
虽然CNCF接受并完成毕业新项目，但同样重要的是要有一种工作机制，将那些因不再具有价值或被其他更相关的项目取代而失去社区兴趣的项目移除。虽然项目提交过程对任何人都开放，我希望TOC委员会将继续只赞助最好的候选人，使CNCF成为一个多样化的生态系统，项目之间可以很好地合作。
作为CNCF的大使，我希望教人们如何使用这些技术。在CloudOps里，我领导了Docker和Kubernetes的研讨会，提供了云原生技术的介绍，并帮助DevOps团队操作他们的应用程序。我还组织了Kubernetes和云原生meetup来介绍来自世界各地的演讲者，代表各种项目。它们每季度在蒙特利尔、渥太华、多伦多、Kitchener-Waterloo和魁北克市运营。我也会鼓励大家在12月10日加入CloudNativeCon北美2018大使团队。通过@archyufaor联系我或电邮到CloudOps，了解更多关于成为云原生的信息。
本文分享自微信公众号 - CNCF（lf_cncf），作者：CNCF官微
原文出处及转载信息见文内详细说明，如有侵权，请联系shaoair110@gmail,com 删除。
原始发表时间：2018-11-06

CNCF云原生景观地址

CNCF云原生景观地址

CNCF云原生地图（github）

CNCF云原生地图（github）