CNCF项目全景图介绍

本文首发在个人博客上，欢迎来踩！

云原生计算基金会（CNCF）介绍

CNCF(Cloud Native Computing Foundation)官网链接：https://www.cncf.io/

官方的介绍如下：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

简单来说，CNCF主要致力于推动开源的云原生技术的可持续发展。

CNCF项目全景图

到2024年6月为止，CNCF已经有26个毕业项目，37个孵化项目，116个沙盒项目。毕业和孵化项目被认为是稳定的，并已在生产环境中成功使用。沙盒项目是新项目，还需要进行开发演进，不适合在生产环境中使用。

其目前的全景图可以从此链接中查看：https://landscape.cncf.io/，如下图所示：

CNCF全景图

下面简单介绍一下CNCF各个层次的项目，主要参考来源于CNCF的官方介绍：https://landscape.cncf.io/guide

配置

配置是云原生环境中的第一层。它包含用于创建和强化构建云原生应用的基础的工具。它包括找到用于自动配置、创建和管理基础架构的工具，以及用于扫描、签名和存储容器映像的工具。该层还扩展到安全性，其中包含支持策略设置和实施、嵌入式身份验证和授权以及机密分发处理的工具。

自动化和配置

解决什么问题：
传统的 IT 流程依赖于漫长且劳动密集的手动发布周期，通常为三到六个月，导致生产环境变更速度缓慢。这与需要快速开发周期的云原生开发不兼容。
如何解决问题：
自动化和配置工具通过编码环境设置，使工程师无需人工干预即可创建和管理计算资源，只需单击按钮即可重现所需状态。这些工具减少了手动配置的错误，提高了工作效率，并允许通过编程方式配置新服务器和应用程序，支持快速、动态的基础设施管理。
代表性项目：
- Cloud Custodian （孵化中）
- KubeEdge （孵化中）

容器注册表

解决什么问题：
容器注册表解决了云原生应用运行所需的容器镜像存储和分发问题，确保开发人员可以方便地访问和管理这些镜像。
如何解决问题：
容器注册表通过集中存储容器镜像，使开发人员能够轻松访问所需的镜像。它们提供 Web API 接口以存储和检索镜像，并集成功能如扫描、签名和分发，以增强安全性和效率。
代表性项目：
- Harbor(已毕业)
- Dragonfly （孵化中）

安全与合规

解决什么问题：
默认情况下，Kubernetes 具有极其宽松的访问控制设置，不适合生产使用。结果：对于任何想要攻击您的系统的人来说，Kubernetes 集群都是一个有吸引力的目标。
安全和合规性工具解决了云原生应用程序在快速迭代过程中需要确保代码和操作环境安全的需求，防止未经授权的访问和潜在的安全漏洞。
如何解决问题：
这些工具通过设置安全策略、扫描容器漏洞、签名镜像以防篡改，以及强化和监控 Kubernetes 集群来确保安全性。它们帮助发现错误配置并在系统出现异常行为时进行检测和响应。
代表性项目：
- Falco (已毕业)
- Open Policy Agent （已毕业）

密钥管理

解决什么问题：
密钥管理工具解决了在云原生环境中安全存储和分发密码、API 密钥等敏感数据的需求，同时确保身份验证和授权过程的安全性和自动化。
如何解决问题：
这些工具提供安全的密钥生成、存储、管理和轮换功能，支持自动化的密钥分发，并提供身份验证和授权服务。它们确保应用程序能安全地验证和授权请求，无需人工干预，提升整体安全性和效率。
代表性项目：
- SPIFFE （已毕业）
- SPIRE （已毕业）

运行时

现在我们已经建立了云原生环境的基础，我们将上移一个基础设施层并放大到运行时层。它涵盖了容器在云原生环境中运行所需的一切。其中包括用于启动容器的代码（称为容器运行时）、使持久存储可用于容器的工具以及管理容器环境网络的工具。

但请注意，这些资源不应与上面讨论的配置层处理的网络和存储工作相混淆。这些资源专注于让容器平台运行。此类别中的工具用于启动和停止容器，帮助它们存储数据，并允许它们相互通信。

云原生存储

解决什么问题：
云原生架构的流动性和弹性使得持久保存数据非常具有挑战性，尤其是在容器不断创建、删除和改变位置的情况下。传统存储解决方案难以满足云原生环境中自动扩展和自我修复的需求。
如何解决问题：
云原生存储工具通过提供云原生兼容的存储选项、标准化存储接口、以及数据保护功能（如备份和恢复），使存储自动化配置，消除人为瓶颈，实现自动扩展和自我修复。例如，容器存储接口 (CSI) 提供标准 API 以向容器提供文件和块存储，工具如 Minio 和 Velero 提供对象存储和数据保护功能。
代表性项目：
- Rook （已毕业）
- CubeFS （孵化中）

容器运行时

解决什么问题：
容器运行时解决了启动容器镜像（包含应用程序规范的文件）的需求，确保应用程序以标准化、安全和隔离的方式运行，同时为其提供必要的资源如 CPU、存储和内存。
如何解决问题：
容器运行时软件在所有环境中标准化地启动应用程序，设置安全边界并隔离资源。工具如 CRI-O 和 gVisor 提供强化的安全边界，防止未经授权的访问和相互干扰，同时为应用程序设定资源限制，确保各应用程序稳定运行而不抢占资源。
代表性项目：
- containerd （已毕业）
- CRI-O （已毕业）

云原生网络

解决什么问题：
云原生网络解决了分布式应用程序中各个容器之间的通信问题，使这些容器能够私下、安全地相互通信。它还解决了数据流管理和网络策略扩展的挑战，尤其在需要连接虚拟机或外部服务时。
如何解决问题：
此类工具使用容器网络接口 (CNI) 创建覆盖网络，分配 IP 地址，提供基本连接或完整的软件定义网络层。工具如 Flannel 提供基本连接，而 NSX-T 等工具创建独立的虚拟网络，支持网络流量管理和策略执行，确保容器化应用程序的安全高效通信。
代表性项目：
- Cilium （已毕业）
- CNI （孵化中）

编排与管理

调度与编排

解决什么问题：
在云原生架构中，应用程序被分解为许多微服务，每个服务运行在一个容器中。管理这些大量分散的容器需要自动化的编排和调度工具，以确保资源分配、监控和故障恢复。
如何解决问题：
容器编排工具如 Kubernetes自动管理容器，执行期望状态协调，确保集群实际状态与工程师设定的期望状态匹配。它通过创建、销毁和监控容器，自动处理应用程序的启动、扩展和恢复，使用户能够将整个集群视为单一资源池，简化了复杂的分布式应用程序管理。
代表性项目：
- Kubernetes （已毕业）
- Keda （已毕业）

协调与服务发现

解决什么问题：
在动态且流动的云原生架构中，服务的位置不断变化，服务之间需要协作但没有固定的位置。服务发现工具解决了识别和定位服务位置的问题，确保各服务能够找到并通信。
如何解决问题：
服务发现工具通过提供一个公共位置来存储和检索服务信息，分为服务发现引擎和名称解析工具。服务发现引擎（如 etcd）存储所有服务及其位置信息，而名称解析工具（如 CoreDNS）处理服务位置请求并返回网络地址信息。这些工具有效管理服务的注册和注销，确保服务间通信的可靠性和动态适应性。
代表性项目：
- Etcd （已毕业）
- CoreDNS （已毕业）

远程过程调用

解决什么问题：
现代应用程序由众多单独的服务组成，这些服务必须进行通信才能协作。RPC 是处理应用程序之间通信的一种选择。
如何解决问题：
RPC 提供了一种紧耦合且高度规范的通信方式，允许高效的带宽利用和多种编程语言的支持，例如流行的 gRPC 实现。
代表性项目：
- gRPC （孵化中）

服务代理

更关注于外部用户访问和 API 管理

解决什么问题：
服务代理解决了应用程序内部和应用程序之间的网络流量管理问题，使得流量可以受控地发送和接收，并允许对流量进行转换、重定向或拒绝请求等操作。
如何解决问题：
通过将流量管理功能从应用程序中外部化到服务代理，开发人员可以更专注于编写核心业务逻辑，而平台团队则可以管理通用任务，如路由、TLS 终止和流量均衡，从而提高通信的可靠性、安全性和效率。
代表性项目：
- Envoy （已毕业）
- CONTOUR（孵化中）

API 网关

解决什么问题：
API 网关解决了组织管理多个 API、实施规则并提供通用接口的问题，同时简化了用户与应用程序之间的交互。
如何解决问题：
通过充当中间人，接收并评估用户请求，记录请求详细信息，并将请求转发到适当的服务，API 网关提供了统一的入口点和管理功能，使得开发人员可以更专注于核心业务逻辑。
代表性项目：
- Emissary-Ingress （孵化中）

服务网格

关注于服务内部通信和交互

解决什么问题：
服务网格解决了在云原生环境中管理服务之间通信和添加功能的问题，同时降低了技术债务和复杂性。
如何解决问题：
通过统一管理集群中所有服务的可靠性、可观察性和安全性功能，服务网格使开发团队可以专注于编写业务逻辑，而无需触及底层代码。
代表性项目：
- Istio （已毕业）
- Linkerd （已毕业）

应用程序定义和开发

到目前为止，我们讨论的所有内容都与构建可靠、安全的环境和提供所有必要的依赖项有关。现在，我们已到达 CNCF 云原生环境的顶层。顾名思义，应用程序定义和开发层专注于使工程师能够构建应用程序的工具。

数据库

解决什么问题：
数据库解决了应用程序需要有效存储和检索数据的需求，同时确保数据安全和合规性。
如何解决问题：
数据库通过提供通用接口和查询语言，使开发人员能够存储、查询和检索信息，并管理数据的备份、加密和访问控制。同时还加强数据库的容器化。
代表性项目：
- TiKV （已毕业）
- Vitess （已毕业）

流媒体和消息传递

解决什么问题：
流媒体和消息传递解决了随着服务数量增加，应用程序通信管理变得更复杂的问题，提供了一个集中管理事件发布和读取的中心位置，使得应用程序能够协同工作。

如何解决问题：
通过发布-订阅的方法，服务可以将事件发布到消息传递工具或流式传输，其他需要了解这些事件的服务则可以订阅并观察这些工具，从而实现了解耦的架构。这种解耦使得工程师能够添加新功能，而无需更新下游应用程序或发送大量查询。

代表性项目：
- CloudEvents （已毕业）
- NATS （孵化中）

应用程序定义和映像构建

解决什么问题：
应用程序定义和镜像构建是一个广泛的类别，可以分为两个主要子类。首先，以开发人员为中心的工具，可帮助将应用程序代码构建到容器和/或 Kubernetes 中。其次，以运营为中心的工具，以标准化方式部署应用程序。无论您是打算加速或简化开发环境，提供标准化的方式来部署第三方应用程序，还是希望简化编写新 Kubernetes 扩展的过程，此类别都可以涵盖许多优化 Kubernetes 开发人员和操作员体验的项目和产品。
应用程序定义和映像构建工具致力于解决开发人员和运营商在 Kubernetes 和容器化环境中面临的挑战，包括构建可重现映像、标准化应用程序部署和简化环境配置等问题。

如何解决问题：
这些工具帮助开发人员简化扩展 Kubernetes、构建、部署和连接应用程序的过程，同时为运营商提供标准化的方式部署预打包的应用程序，快速部署服务网格等服务，以及简化映像创建和应用程序部署的过程。通过引入这些工具，可以加速应用程序开发、提高部署效率，并降低操作复杂性。

代表性项目：
- Helm(已毕业)
- Artifact Hub （孵化中）
- KubeVirt （孵化中）

持续集成和交付

解决什么问题：
持续集成 (CI) 和持续交付 (CD) 工具旨在解决开发人员和运营商在构建和部署应用程序时面临的挑战，包括确保代码质量、自动化构建和部署流程、提高交付速度和减少错误的问题。

如何解决问题：
这些工具通过自动化代码更改的构建、测试和部署过程，确保代码集成的连续性和质量。CI 系统可帮助开发人员快速发现并修复代码错误，而 CD 系统则将 CI 流程的结果推送到不同环境，从开发到生产，以确保交付的可靠性和一致性。这些工具与 Kubernetes 等技术结合使用，使得云原生环境下的持续集成和交付更加高效和可靠。

代表性项目：
- Argo（已毕业）
- Flux （已毕业）

可观察性和分析

现在我们已经了解了 CNCF 格局的各个层面，我们将重点关注从可观察性和分析性开始的列。

在深入探讨这些类别之前，我们先来定义一下可观察性和分析性。可观察性是一种系统特性，它描述了系统从外部输出中可理解的程度。通过 CPU 时间、内存、磁盘空间、延迟、错误等来衡量，计算机系统的可观察性或多或少。分析是一种查看这些可观察数据并理解其意义的活动。

为了确保服务不会中断，您需要观察和分析应用程序的各个方面，以便立即检测并纠正每个异常。这就是此类别的全部内容。它运行并观察所有层，这就是为什么它位于侧面而不是嵌入特定层的原因。

此类别中的工具分为可观察性和混沌工程。请注意，类别名称有些误导 — 虽然此处列出了混沌工程，但请将其视为可靠性工具，而不是可观察性或分析工具。

可观察性

解决什么问题：
可观察性解决了复杂系统中出现故障或性能下降时难以定位问题的挑战。它通过提供有关系统运行状况、关键统计数据和问题调试信息的高质量遥测数据，帮助用户理解系统的内部运行情况。

如何解决问题：
可观察性框架收集并分析来自应用程序代码、底层基础设施以及编排系统等的日志、指标和跟踪数据。这些数据可以帮助运维人员更快地响应事件，开发人员在生产中调试应用程序，并帮助组织了解用户行为与系统性能之间的关系。在云原生环境下，可观察性对于快速定位和解决问题至关重要。

代表性项目：
- Prometheus（已毕业）
- Fluentd （已毕业）

混沌工程

解决什么问题：
混沌工程旨在解决复杂系统中故障带来的挑战，通过故意引入故障来测试系统的弹性，以确保系统和工程团队能够应对动荡和意外事件。

如何解决问题：
混沌工程工具提供了一种受控的方式来引入故障并针对应用程序的特定实例运行实验。通过这种方式，团队可以在生产环境中实验，以确保系统在面对实际故障时能够优雅地运行和恢复。这种做法有助于优化平均修复时间(MTTR)，使团队更具应变能力和可靠性。

代表性项目：
- Chaos Mesh （孵化中）
- Litmus（孵化中）

平台

正如我们目前所见，讨论的每个类别都解决了一个特定的问题。单靠存储并不能提供管理应用所需的一切。您需要一个编排工具、一个容器运行时、服务发现、网络、API 网关等。平台将不同层的不同工具捆绑在一起，解决更大的问题。

这些平台本身并没有什么新意。它们所做的一切都可以通过这些层或可观察性和分析列中的工具之一完成。您当然可以构建自己的平台，事实上，许多组织都这样做了。但是，可靠、安全地配置和微调不同的模块，同时确保所有技术始终保持最新状态并修补漏洞并非易事——您需要一个专门的团队来构建和维护它。如果您没有必要的资源或专业知识，您的团队可能最好使用平台。对于一些组织，尤其是那些工程团队较小的组织，平台是采用云原生方法的唯一途径。

你可能会注意到，所有平台都围绕 Kubernetes展开。这是因为它是云原生堆栈的核心。

认证 Kubernetes - 分发

解决什么问题：
发行版（或发行版）解决了 Kubernetes 部署和管理的复杂性，为用户提供了可靠的 Kubernetes 安装方式，并提供了默认设置，以创建更好、更安全的操作环境。

如何解决问题：
通过将核心 Kubernetes 打包并提供处理集群安装和升级的机制，发行版简化了 Kubernetes 的采用和管理过程。它提供了可预测的配置和设置，为用户提供了支持和升级路径，并附带经过测试的软件扩展，使得在 Kubernetes 上部署其他应用程序更加容易。

代表性项目：
- K3s （沙盒）

经过认证的 Kubernetes - 托管

解决什么问题：
托管 Kubernetes 是基础设施提供商（如AWS、Digital Ocean、Azure和Google）提供的服务，简化了 Kubernetes 的部署和管理，允许用户无需深入了解即可启动和管理 Kubernetes 集群。

如何解决问题：
用户可以通过在云提供商处设置帐户，并通过简单的界面或命令行工具启动 Kubernetes 集群，而无需自己进行配置或管理。托管 Kubernetes 将管理细节外包给供应商，使用户能够专注于应用程序开发和部署。

代表性项目：
- 无，主要是由云服务商提供

认证 Kubernetes - 安装程序

解决什么问题：
认证 Kubernetes - 安装程序解决了在机器上安装和配置 Kubernetes 的复杂性问题，特别是对于初学者和没有专业知识的用户而言。
如何解决问题：
它通过自动执行安装和配置过程，提供经过审查的源代码和环境配置，简化了 Kubernetes 的部署过程，让用户可以快速轻松地搭建起符合标准的 Kubernetes 环境。
代表性项目：
- Kubean （沙盒）
- Kind （沙盒）

PaaS/容器服务

解决什么问题：
PaaS/容器服务解决了用户在运行应用程序时不必关心底层计算资源细节的问题，为开发人员提供了托管应用程序的环境。
如何解决问题：
通过将各种开源和闭源工具组合在一起，并提供处理安装、升级和运行时需求的机制，PaaS/容器服务简化了应用程序部署和管理过程，加快了价值实现途径。
代表性项目：
- 目前该领域没有 CNCF 项目，但大多数产品都是开源的，Cloud Foundry 由 Cloud Foundry 基金会管理。

总结

现在我们已经分解了 CNCF 云原生全景图，并逐层、逐类进行了讨论，可能感觉没那么难了。它有一个逻辑结构，一旦你理解了它，浏览全景图就会变得容易得多。

CNCF Landscape 的各个层级相互依存。首先是配置层，其中包含奠定基础设施基础所需的工具。接下来是运行时层，其中的所有内容都围绕容器以及容器在云原生环境中运行所需的内容。编排和管理层包含用于编排和管理容器和应用程序的工具 - 换句话说，就是创建应用程序构建平台所需的工具。应用程序和定义与开发层涉及使应用程序能够存储和发送数据所需的工具，以及我们构建和部署应用程序的方式。

层旁边有两列。可观察性和分析列包括监控应用程序并在出现问题时发出警报的工具。由于所有层都必须受到监控，因此此类别涵盖所有层。最后是平台。平台不提供新功能，而是将不同层的多种工具捆绑在一起，对其进行配置和微调，以便随时可用。这简化了云原生技术的采用，甚至可能是组织能够利用这些技术的唯一方式。