云原生景观图指南由 ]CNCF 商业价值小组委员会](https://github.com/cncf/business-value) 和 Cartografos 团队发起。 本指南由 Jason Morgan 和 Catherine Paganini 撰写， 由 Simon Forster 和 Ihor Dvoretskyi 编辑和审查， 并由 Jordi Noguera 使用 Andrea Velázquez 的 UX 咨询构建。
如果你已经研究过云原生应用和技术，那么你可能已经偶遇过 CNCF 云原生景观图相关内容。这并不奇怪，其规模之大可能会让你不知所措。其中有那么多类别和那么多技术，你要如何理清它们呢？
和其他任何技术一样，如果把它分解开来并逐个分析，你会发现它并不那么复杂，而且非常合情合理。事实上，这张地图是按功能整齐地组织起来的，当你理解了每个类别所代表的含义，就很容易用它来”导航”了。
在本指南中，我们会逐步拆解这个巨大的景观，并提供其层次、列和类别的高层次概述。
云原生景观图的目标是将所有云原生开源项目和专有产品分类编写并组织起来，提供当前云原生生态系统的概览。拥有云原生项目或产品的组织可以提交PR来请求将其添加到景观图中。
在本指南中，景观图中每一层和列都有一章讨论其中的每个类别。类别有：它是什么，它解决什么问题，它如何帮助（解决问题）以及 technical 101。前三个部分都假定读者是没有技术背景的情况， technical 101则面向刚开始使用云原生的工程师。我们还包括了一个相关术语和 CNCF 项目列表的部分。
观察这个景象，你会注意到一些区别：
- 大盒子中的项目 是CNCF托管的开源项目。有些仍处于孵化阶段（浅蓝/紫色边框），而其他则是毕业项目（深蓝色边框）。
- 小白盒子中的项目 是开源项目。
- 灰色盒子中的产品 是专利产品。
请注意新项目正在不断成为CNCF的一部分，因此请多多参考实际的景观图 - 事物日新月异！
供应层是云原生景观图中的第一层。它包括用于创建和加固云原生应用程序构建基础的工具。在这里你将找到自动配置、创建和管理基础设施的工具，以及用于扫描、签名和存储容器镜像的工具。该层还扩展到安全领域，具备使策略设置和执行、嵌入式身份验证和授权以及处理密钥分发的工具。这听起来很拗口，所以让我们一个一个类别来讨论。
自动化和配置工具可以加快计算资源（虚拟机、网络、防火墙规则、负载均衡器等）的创建和配置速度。此类工具可以处理供应过程的不同部分，或者尝试控制整个过程。大多数提供与该领域中其他项目和产品集成的能力。
传统上，IT流程依赖于漫长而费力的手动发布周期，通常在三到六个月之间。这些周期伴随着许多人类过程和控制，使得生产环境的变化变得缓慢。这些缓慢的发布周期和静态环境与云原生开发不兼容。为了实现快速的开发周期，基础架构必须动态且没有人为干预地进行配置。
这类工具允许工程师在没有人为干预的情况下构建计算环境。通过对环境设置进行编码，它变得可重现，只需点击一个按钮。虽然手动设置容易出错，但一旦编码，环境创建就可以匹配精确的期望状态-这是一个巨大的优势。
虽然工具可能采取不同的方法，但它们都旨在通过自动化减少所需的资源配置工作。
随着我们从旧的人力驱动的配置向由云驱动的新的按需扩展模型迁移，我们之前使用的模式和工具已不再满足我们的需求。大多数组织无法承担一个大型的 7x24 员工团队来创建、配置和管理服务器。像 Terraform 这样的自动化工具可以减少扩展数十个服务器和拥有数百个防火墙规则的网络所需的工作量。像 Puppet、Chef 和 Ansible 这样的工具可以按编程方式配置这些新服务器和应用程序，在它们启动时允许开发人员使用它们。
一些工具直接与 AWS 或 vSphere 等平台提供的基础设施 API 进行交互，而其他工具则专注于配置单个机器，使它们成为 Kubernetes 集群的一部分。许多工具，如 Chef 和 Terraform，可以互操作以配置和管理环境。还有其他工具，如 OpenStack，旨在于提供其他工具可以使用的基础设施即服务（Infrastructure-as-a-Service IaaS）环境。从根本上说，在铺设计算环境、CPU、内存、存储和网络的基础上，您将需要一个或多个工具来创建和管理Kubernetes集群。您还需要这些工具的子集来创建和管理Kubernetes集群本身。
现在，这个领域已经有5个CNCF项目，如果算上Cluster API这样的项目，这还会更多。还有其他开源和供应商提供的非常强大的工具。
在深入了解容器注册表之前，我们需要定义三个紧密相关的概念：
- 容器是“由计算机操作系统管理的具有资源和能力约束的运行进程”（参见 云原生词汇表）。
- 镜像是一组归档文件，用于运行容器及其进程。您可以将其视为模板，可在其上创建无限数量的容器。
- 仓库或称为 repo ，是存储镜像的空间。
而容器注册表是专门的 Web 应用程序，可分类和存储仓库。
让我们快速回顾一下：镜像包含执行程序所需的信息（在容器中），并存储在仓库中，这些仓库又分为类别和组别，并存储在注册表中。构建、运行和管理容器的工具需要访问这些镜像。访问是通过引用注册表（访问镜像的路径）提供的。
云原生应用程序被打包并作为容器运行。容器注册表存储并提供运行这些应用程序所需的容器镜像
通过集中存储所有容器镜像到一个地方，任何开发此应用程序的开发人员都可以轻松访问。
容器注册表存储和分发镜像或以某种方式增强现有注册表。根本上讲，注册表是允许容器运行时存储和检索镜像的 Web API。许多提供接口，允许容器扫描或签名工具增强其存储的镜像的安全性。有些专门于以特别高效的方式分发或复制镜像。任何使用容器的环境都需要使用一个或多个注册表。
这个领域的工具提供了集成，可以扫描、签名和检查它们存储的镜像。Dragonfly 和 Harbor 是 CNCF 项目，Harbor 最近获得了第一个支持 OCI 的注册表的荣誉。每个主要的云提供商都提供自己的托管注册表，许多其他注册表可以独立部署，或通过像 Helm 这样的工具直接部署到您的 Kubernetes 集群中。
云原生应用程序旨在快速迭代。想想你手机上持续不断的应用更新——它们每天都在发展，假定变得更好了。为了按照一定节奏发布代码，您必须确保代码和操作环境是安全的，并且只能由授权工程师访问。本节中的工具和项目提供了构建和运行现代应用程序所需的一些能力。
安全和合规性工具可帮助加固、监控和执行平台和应用程序的安全性。从容器到 Kubernetes 环境，这些工具允许您设置策略（用于合规性）、获取现有漏洞的洞察力、捕获错误配置并加固容器和集群。
要安全地运行容器，必须扫描容器中已知的漏洞并签名以确保它们没有被篡改。默认情况下，Kubernetes 具有极其宽松的访问控制设置，不适合生产使用。结果：Kubernetes 集群成为任何试图攻击您系统的人的一个有吸引力的目标。这个领域的工具和项目有助于加固集群并检测系统异常行为。
- 审计和合规性
- 生产路径：
- 代码扫描
- 漏洞扫描
- 映像签名
- 策略创建和执行
- 网络层安全 其中一些工具很少直接使用。例如，Trivy、Claire 和 Notary 是由注册表或其他扫描工具利用的。其他则代表现代应用平台的关键加固组件。例如 Falco 或 Open Policy Agent (OPA)。
您会发现许多成熟的供应商提供此领域的解决方案以及专门创立的初创企业，旨在将 Kubernetes 原生框架引入市场。在撰写本文时，Falco、Notary/TUF 和 OPA 是 CNCF 项目中的一部分。
在深入研究密钥管理之前，让我们先定义加密密钥。密钥是用于加密或签名数据的字符字符串。像物理钥匙一样，它给数据上锁（加密），以便只有具有正确密钥的人可以解锁（解密）。
随着应用程序和操作适应新的云原生世界，安全工具正在发展以满足新的安全需求。这个类别中的工具和项目涵盖了从如何安全地存储密码和其他秘密（敏感数据，如API密钥，加密密钥等）到如何安全地从您的微服务环境中消除密码和秘密的所有事情。
云原生环境高度动态，需要按需进行秘密分发。这意味着必须做到完全编程化（没有人在环节中）和完全自动化。
此外，应用程序需要知道给定请求是否来自有效来源（身份验证），以及该请求是否有权执行其正在尝试执行的操作（授权）。 这通常称为 AuthN 和 AuthZ 。
每个工具或项目采取不同的方法，但它们都提供一种方法，无论是安全分发秘密和密钥，还是与身份验证，授权或两者都有关的服务或规范。
该类别的工具可分为两类：（1）密钥生成、存储、管理和轮换，以及 （2）单点登录和身份管理。例如，Vault 是一个相当通用的密钥管理工具，可让您管理不同类型的密钥。另一类的例子，Keycloak 是一个身份代理，可用于管理不同服务的访问密钥。
正如我们所看到的，供应层的重点是使用工具构建云原生平台和应用程序的基础，这些工具处理从基础设施供应到容器注册表再到安全性的所有内容。接下来，我们将讨论包含云本地存储、容器运行时和网络的运行时层。
现在我们已经建立了云原生环境的基础，我们将向上移动一层基础设施，并放大到运行时层。它包含容器在云原生环境中运行所需的一切。这包括用于启动容器的代码，称为容器运行时；使持久存储可用于容器的工具；以及管理容器环境网络的工具。
但请注意，这些资源不应与上面讨论的供应层处理的网络和存储工作混淆。那些专注于使容器平台运行。这个类别中的工具用于启动和停止容器，帮助它们存储数据，并允许它们彼此交流。
存储是应用程序持久数据存储的地方，通常称为持久卷。为了可靠运行，应用程序需要轻松访问存储。通常来说，当我们说持久数据时，我们指的是存储数据库、消息或任何其他要确保在应用程序重新启动时不会消失的信息。
云原生架构非常流动、灵活和弹性，这使得在重启之间持久化数据变得非常具有挑战性。为了进行扩展和自我修复，容器化应用程序不断地被创建和删除，随着时间推移而改变其物理位置。这就是为什么云原生存储必须提供独立于节点的功能。然而，要存储数据，您需要硬件，具体来说是一个磁盘，而磁盘就像任何其他硬件一样，都与基础设施绑定，这是我们面临的第一个重大挑战。
然后，实际的存储接口在数据中心之间可能会有很大的变化（在旧世界中，每个基础设施都有自己的存储解决方案和独特的接口），这使得可移植性非常困难。
最后，手动配置和自动扩展不兼容，因此，为了从云的弹性中受益，必须自动配置存储。
云原生存储是为这种新的云原生现实量身定制的。
这个类别中的工具可以帮助：
- 为容器提供云原生存储选项，
- 标准化容器和存储提供商之间的接口，或者
- 通过备份和恢复操作提供数据保护。
前者意味着使用与云原生兼容的容器存储接口的存储（第二类工具），可以自动配置，通过消除人类瓶颈实现自动扩展和自我修复。
云原生存储主要得益于容器存储接口 (CSI)，该接口为容器提供提供文件和块存储的标准 API。在这一类别中有许多工具，包括开源和供应商提供的工具，它们利用 CSI 为容器提供按需存储。
此外，还有一些技术旨在解决其他云原生存储难题。Minio 是一个流行的项目，它提供了 S3 兼容的对象存储 API 等功能。像 Velero 这样的工具有助于简化备份和恢复 Kubernetes 集群本身以及应用程序使用的持久数据的过程。
如在容器注册表下所讨论的，容器是一组用于执行（或启动）应用程序的计算约束。容器化的应用程序认为它们正在运行在自己专用的计算机上，并且不知道它们正在与其他进程共享资源（类似于虚拟机）。
容器运行时是执行容器化（或“约束”）应用程序的软件。如果没有运行时，您只有容器映像，即静态文件，指定容器化的应用程序应该如何运行。运行时将在容器中启动应用程序并为其提供所需的资源。
容器映像（应用程序规范的文件）必须以标准化、安全和隔离的方式启动。标准化是因为无论在哪里运行，都需要标准化的操作规则。安全，因为您不希望任何未经授权的人访问它。而隔离是因为您不希望应用程序受到其他应用程序的影响（例如如果共存的应用程序崩溃了）。隔离基本上起到保护作用。此外，还需要为应用程序提供资源，例如 CPU、存储和内存。
容器运行时完成所有这些工作。它以标准化的方式在所有环境中启动应用程序，并设置安全边界。后者是一些工具的区别所在。像 CRI-O 或 gVisor 这样的运行时已经加强了其安全边界。运行时还为容器设置资源限制。如果没有它，应用程序可能会根据需要消耗资源，潜在地占用其他应用程序的资源，因此您始终需要设置限制。
这个类别中不是所有的工具都是平等的。Containerd（著名的 Docker 产品的一部分）和 CRI-O 是标准容器运行时实现。然后有一些工具将容器的使用扩展到其他技术，例如 Kata，它允许您将容器作为VM运行。其他项目旨在解决特定的容器相关问题，例如 gVisor 在容器和操作系统之间提供了一个额外的安全层。
Containers talk to each other and to the infrastructure layer through a cloud native network. Distributed applications have multiple components that use the network for different purposes. Tools in this category create a virtual network on top of existing networks specifically for apps to communicate, referred to as an overlay network.
容器通过云原生网络相互通信和与基础架构层通信。 分布式应用程序 包含多个使用网络进行不同用途的组件。此类工具在现有网络的基础上创建一个虚拟网络，专门用于应用程序通信，称为覆盖网络。
虽然人们通常称在容器中运行的代码为应用程序，但事实上，大多数容器仅包含大型应用程序的一小部分特定功能。像 Netflix 或 Gmail 这样的现代应用程序由许多这些较小的组件组成，每个组件都在自己的容器中运行。为了使所有这些独立的部分作为一个协调的应用程序运行，容器需要私下相互通信。这类工具提供了私有通信网络。
在容器之间流动的数据和消息可能具有敏感或私密数据。由于云原生网络使用软件来控制、检查和修改数据流，从而让管理、安全和隔离容器之间的连接更容易。在某些情况下，您可能希望扩展容器网络和网络策略，如防火墙和访问规则，以允许应用程序连接到容器网络之外运行的虚拟机或服务。云原生网络的可编程性和通常声明性使这种扩展成为可能。
该类别中的项目和产品使用容器网络接口（CNI），这是CNCF项目，为容器化应用程序提供网络功能。一些工具，如Flannel，相当简约，仅提供与容器的基本连接。其他工具，如 NSX-T，提供完整的软件定义网络层，为每个Kubernetes名称空间创建一个隔离的虚拟网络。
至少，容器网络需要为Pod（即在Kubernetes中运行容器化应用程序的地方）分配IP地址，以允许其他进程访问它。
这个领域的多样性和创新主要是由CNI（类似于上面提到的存储和容器存储接口）实现的。CNI 规范了网络层向pod提供功能的方式。选择适合你的 Kubernetes 环境的容器网络非常关键，你有许多工具可以选择。Weave Net、Antrea、Calico和 Flannel 都提供了有效的开源网络层。它们的功能差异很大，你的选择应该最终由你的特定需求驱动。
许多供应商使用软件定义网络（SDN）工具支持和扩展 Kubernetes 网络，提供对网络流量的额外见解，执行网络策略，甚至将容器网络和策略延伸到你的更广泛的数据中心。
这是我们对运行时层的概述，它为容器提供了在云原生环境中运行所需的所有工具：
- 云原生存储为应用程序提供了易于快速访问所需数据以实现可靠运行的能力
- 容器运行时创建并启动容器，执行应用程序代码
- 云原生网络为容器化应用程序提供了通信的连接。
现在，我们已经覆盖了供应和运行时层，可以深入研究编排和管理层。在这里，您将找到处理运行和连接云原生应用程序的工具。此部分涵盖了从 Kubernetes 本身到负责应用程序内部和外部通信的基础设施层的所有内容。云原生应用程序具有固有的可扩展性，依赖于这些工具提供的自动化和弹性。
编排和调度是指在集群中运行和管理容器。集群是一组机器，可以是物理的或虚拟的，通过网络相连（参见云原生网络）。
容器编排器（和调度器）有些类似于您笔记本电脑上的操作系统（OS）。操作系统管理您所有的应用程序，如 Microsoft 365、Slack 和 Zoom；执行它们，并安排每个应用程序何时使用您笔记本电脑的硬件资源，如CPU、内存和存储器。
虽然在单个计算机上运行所有内容非常好，但今天的大多数应用程序都比一个计算机能够处理的要大得多。想想 Gmail 或者是 Netflix。这些巨大的应用程序分布在多台机器上，形成分布式应用。大多数现代应用程序都是这样构建的，需要能够管理在这些不同机器上运行的所有组件的软件。简而言之，您需要一个“集群操作系统”。这就是编排工具发挥作用的地方。
您可能已经注意到容器一次又一次地出现。它们在许多不同的环境中运行应用程序的能力是关键。在大多数情况下，容器编排器（Kubernetes）提供管理这些容器的能力。容器和 Kubernetes 都是云原生架构的核心，这就是为什么我们经常听到它们的原因。
如在“云原生网络”部分所述，在云原生体系结构中，应用程序被分解为小组件或服务，每个服务放置在容器中。你可能听说过它们被称为微服务。现在，你不再有一个大型应用程序（通常被称为“巨石系统”），而是有几十甚至数百个（微）服务。每个服务都需要资源、监控和修复，如果出现问题。虽然针对单个服务手动完成所有这些工作可能是可行的，但在处理具有自己容器的多个服务时，你需要自动化的流程。
容器编排工具自动化了容器管理。但这在实践中意味着什么？让我们来回答一下 Kubernetes 的情况，因为它是事实上的容器编排工具。
Kubernetes 做的事情被称为期望状态协调：它将集群中容器的当前状态与期望状态匹配。期望状态由工程师指定（例如，在三个节点（即机器）上运行十个服务 A 实例，并访问数据库 B 等），并不断与实际状态进行比较。如果期望和实际状态不匹配，Kubernetes 通过创建或销毁对象来协调它们。例如，如果一个容器崩溃了，Kubernetes 就会启动一个新的容器。
简而言之，Kubernetes 允许您将集群视为一个计算机。它只关注环境应该看起来像什么，并为您处理实现细节。
Kubernetes 位于编排和调度层，与 Docker Swarm 和 Mesos 等其他容器编排器一起，以声明性方式管理多个不同的计算机资源池。 Kubernetes 中的声明性配置管理是通过控制循环处理的，这是一种模式，其中在 Kubernetes 中运行的进程监视特定对象类型的 Kubernetes 存储，并确保群集中的实际状态与期望状态相匹配。
例如，用户创建了一个 Kubernetes 部署，指定必须有3个Web应用程序副本。部署控制器将确保创建这3个 Web 应用程序容器，然后继续监视群集，以查看容器数量是否正确。如果由于任何原因删除了特定容器，部署控制器将导致创建新实例。如果将部署修改为缩小到1个Web应用程序实例，则会指示 Kubernetes 删除2个正在运行的 Web 应用程序。
此核心控制器模式也可用于由用户或软件开发人员扩展 Kubernetes 。操作员模式允许人们为自定义资源编写自定义控制器，并在Kubernetes本身中构建任意逻辑和自动化。
虽然 Kubernetes 不是 CNCF 托管的唯一编排器（Crossplane 和 Volcano 都是沙盒项目），但它是最常用和活跃维护的编排器。
现代应用程序由多个单独的服务组成，这些服务需要协作才能为最终用户提供价值。为了协作，它们通过网络通信（参见云原生网络），为了通信，它们必须首先找到彼此。服务发现是找出如何做到这一点的过程。
云原生架构是动态和流动的，这意味着它们不断变化。当容器在一个节点上崩溃时，会在另一个节点上旋转一个新的容器以替换它。或者，当应用程序扩展时，副本会分散在整个网络中。没有一个特定服务的位置 - 一切的位置都在不断改变。此类工具跟踪网络内的服务，以便服务在需要时可以找到彼此。
服务发现工具通过提供一个共同的位置来查找和识别个别服务来解决此问题。在此类别中基本上有两种工具:
- 服务发现引擎：类似数据库的工具，存储有关所有服务及其定位方法的信息
- 名称解析工具：接收服务定位请求并返回网络地址信息的工具（例如 CoreDNS）
在 Kubernetes 中，为了使 pod 可达性，引入了一个新的抽象层，称为“服务”。服务为动态更改的一组 pod 提供了单一的稳定地址。
请注意，“服务”在不同的上下文中可能具有不同的含义，这可能非常令人困惑。术语“服务”通常指放置在容器和 pod 中的服务。它是应用程序组件或微服务，具有实际应用程序中特定功能，例如移动电话的面部识别算法。
Kubernetes 服务是指帮助 pod 找到并相互连接的抽象。它是服务（功能）的入口点，作为一组进程或 pod。在 Kubernetes 中，当您创建服务（抽象）时，您创建一组 pod，这些 pod 共同提供具有单一端点（入口点）的服务（一个或多个容器中的功能），该端点是 Kubernetes 服务。
随着分布式系统越来越普及，传统的 DNS 过程和传统的负载均衡器经常无法跟上不断变化的端点信息。为了弥补这些不足，服务发现工具处理单个应用程序实例快速注册和注销自己。一些选项，如 CoreDNS 和 etcd 是 CNCF 项目，并内置于 Kubernetes 中。其他工具则有自定义库或工具，可以使服务有效运作。
远程过程调用（RPC）是一种特定的技术，使应用程序能够相互通信。这是一种应用程序通信结构的方式。
现代应用程序由许多单独的服务组成，这些服务必须进行通信才能协作。RPC是处理应用程序之间通信的一种选择。
RPC 提供一种紧密耦合和高度可选择的处理服务之间通信的方式。它允许带宽高效的通信，并且许多编程语言支持 RPC 接口实现。
使用 RPC 有很多潜在的好处：它使编码连接更容易，允许在网络层上实现极其高效的使用和服务之间的良好结构化通信。但是，RPC 也因为创建脆弱的连接点和迫使用户对多个服务进行协调升级而受到批评。gRPC 是一种特别流行的 RPC 实现，已被 CNCF 采用。
服务代理是一种工具，它拦截到或从给定服务出发的流量，应用一些逻辑，然后将该流量转发到另一个服务。它本质上充当一个“中间人”，可以收集有关网络流量的信息以及对其应用规则。这可以是简单的负载均衡器，将流量转发到单个应用程序，也可以是互联的代理网格，与单个容器化应用程序并行运行，处理所有网络连接。
服务代理本身就很有用，而在在将流量从更广泛的网络驱动特别是到 Kubernetes 集群时，服务代理也是其他系统的构建块。例如 API 网关或服务网格，我们将在下面讨论。
应用程序应以受控方式发送和接收网络流量。为了跟踪流量并可能转换或重定向它，我们需要收集数据。传统上，启用数据收集和网络流量管理的代码嵌入在每个应用程序中。
服务代理“外部化”了此功能。它不再必须存在于应用程序中。相反，它嵌入在平台层（您的应用程序运行的位置）。这非常强大，因为它允许开发人员完全专注于编写生成价值的应用程序代码，从而允许处理流量的通用任务由平台团队管理，这首先应该是他们的责任。从单个公共位置集中分发和管理全球所需的服务功能（例如路由或 TLS 终止）可使服务之间的通信变得更加可靠，安全和高效。
代理作为用户与服务或不同服务之间的门卫。由于其独特的位置，它们提供了对正在发生的通信类型的洞察，并可以确定将特定请求发送到何处，甚至完全拒绝它。
代理收集关键数据，管理路由（在服务之间平均分配流量或在某些服务发生故障时重新路由），加密连接并缓存内容（减少资源消耗）。
服务代理通过拦截服务之间的流量，对其进行逻辑处理，并允许其在允许的情况下继续移动。嵌入到代理中的集中控制功能使管理员能够完成几件事情。他们可以收集有关服务间通信的详细指标，保护服务免受过载，并对服务应用其他常见标准，例如相互 TLS。对于像服务网格这样的工具，服务代理是基础的，因为它们提供了一种将更高级别的策略强制应用于所有网络流量的方式。
请注意，CNCF 将负载均衡器和入口提供程序包括在此类别中。
人类通常通过 GUI（图形用户界面）与计算机程序交互，例如网页或桌面应用程序，而计算机通过 API（应用程序编程接口）相互交互。但 API 不应与 API 网关混淆。
API 网关允许组织将关键功能（如授权或限制应用程序之间的请求数量）移动到集中管理的位置。它还作为（通常是外部的）API 消费者的公共接口。
虽然大多数容器和核心应用程序都有一个 API，但 API 网关不仅仅是一个 API。API 网关简化了组织如何管理和应用规则到所有交互。
API 网关允许开发人员编写和维护更少的自定义代码（系统功能被编码在 API 网关中，还记得吗？）。它们还使团队能够查看和控制应用程序用户与应用程序本身之间的交互。
API网关位于用户和应用程序之间。它充当一个中间代理，接收用户的消息（请求），并将其转发到适当的服务。但在移交请求之前，它会评估用户是否被允许做他们想做的事情，并记录有关谁发出请求以及他们发出了多少请求的详细信息。
简而言之，API网关为应用程序用户提供一个单一的入口点，具有常见的用户界面。它还使您能够将在应用程序中实现的任务移交给网关，从而节省开发人员的时间和金钱。
以亚马逊商店卡为例。为了提供它们，亚马逊与一家银行合作，该银行将发行和管理所有亚马逊商店卡。作为回报，银行将保留每笔交易的1美元。银行将使用API网关来授权零售商请求新卡，跟踪结算的交易数量，甚至可能限制每分钟请求的卡数。所有这些功能都编码到网关中，而不是使用它的服务。服务只关心发卡。
像代理和服务网格（见下文）一样，API 网关将自定义代码从我们的应用程序中取出并引入到中央系统中。API 网关通过拦截对后端服务的调用来工作，执行某种增值活动，例如验证授权、收集度量或转换请求，然后执行它认为合适的任何操作。
API 网关为一组下游应用程序提供一个共同的入口点，同时提供一个团队可以注入业务逻辑来处理授权、速率限制和计费的地方。它们允许应用程序开发人员将对其下游 API 的更改抽象出来，使其客户无需关注，同时将像新客户入门这样的任务卸载到网关。
服务网格管理服务之间的流量（即通信）。它们使平台团队能够在集群内运行的所有服务中统一添加可靠性、可观察性和安全功能，而无需进行任何代码更改。
与 Kubernetes 一起，服务网格已成为云原生堆栈中最重要的基础架构组件之一。
在云原生世界中，我们处理多个服务需要通信。这意味着更多的流量在本质上不可靠且常常缓慢的网络上来回传递。为了解决这个新的一系列挑战，工程师必须实现额外的功能。在服务网格之前，这些功能必须编码到每个应用程序中。这种定制代码经常成为技术债务的源头，并提供了新的失败或漏洞的途径。
服务网格在不触及应用程序代码的情况下，在平台层统一为所有服务添加可靠性、可观察性和安全性功能。它们兼容任何编程语言，使开发团队可以专注于编写业务逻辑。
传统上，这些服务网格功能必须编码到每个服务中，每次发布或更新新服务时，开发人员必须确保这些功能也是可用的，从而提供了很大的人为错误空间。一个不为人知的秘密是，开发人员更喜欢专注于业务逻辑（产生价值的功能），而不是构建可靠性、可观察性和安全性功能。 对于平台所有者来说，这些是核心能力，是他们所做的一切的核心。让开发人员负责添加平台所有者需要的功能本质上是有问题的。顺便说一下，这也适用于上面提到的通用代理和API网关。服务网格和API网关解决了这个问题，因为它们由平台所有者实施，并普遍应用于所有服务。
服务网格通过服务代理将群集中运行的所有服务绑定在一起，从而创建服务网格。这些由服务网格控制平面进行管理和控制。服务网格允许平台所有者执行常见操作或收集有关应用程序的数据，而无需开发人员编写自定义逻辑。
实质上，服务网格是管理服务之间通信的基础结构层，通过向服务代理网络（您的网格）提供命令和控制信号来实现。它的强大之处在于它能够提供关键的系统功能，而无需修改应用程序。
一些服务网格使用通用的服务代理（如上所述）作为其数据平面。其他人使用专用代理；例如，Linkerd 使用 Linkerd2-proxy “微代理”来在性能和资源消耗方面获得优势。这些代理通过所谓的旁路附加到每个服务。边车（Sidedecar）是指代理在自己的容器中运行，但位于同一 pod 中。就像摩托车旁的边车一样，它是一个单独的模块，跟随摩托车走到哪里。
以熔断器为例。在微服务环境中，单个组件经常会失败或开始运行缓慢。如果没有服务网格，则开发人员将不得不编写自定义逻辑来优雅地处理下游故障，并可能设置冷却时间器，以避免上游服务不断请求来自降级或故障下游服务的响应。有了服务网格，该逻辑在平台级别处理。 服务网格提供许多有用的功能，包括显示详细的指标、加密所有流量、限制哪个服务被授权执行哪些操作、为其他工具提供附加插件等等。有关更详细的信息，请查看服务网格接口规范。
正如我们所看到的，这个层面的工具涉及如何作为一个组管理所有这些独立的容器化服务。编排和调度工具可以被视为一个集群操作系统，管理您集群中的容器化应用程序。协调和服务发现、服务代理以及服务网格确保服务可以相互找到并有效地通信，以协同作为一个一体化的应用。API 网关是提供更多控制服务间通信的额外层，特别是在外部应用程序之间。接下来，我们将讨论应用程序定义和开发层—— CNCF 景观的最后一层。它涵盖数据库、流媒体和消息传递、应用程序定义和镜像构建，以及持续集成和交付。
到目前为止，我们讨论的所有内容都与构建可靠、安全的环境和提供所有必需的依赖项有关。现在，我们到达了CNCF云原生景观的顶层。顾名思义，应用程序定义和开发层专注于使工程师能够构建应用程序的工具。
数据库是一种应用程序，通过该应用程序，其他应用程序可以高效地存储和检索数据。数据库允许您存储数据，确保只有经过授权的用户可以访问它，并通过专门的请求使用户可以检索它。虽然有许多不同类型的数据库具有不同的方法，但它们最终都具有相同的总体目标。
大多数应用程序需要一种有效的方法来存储和检索数据，同时保持数据的安全性。数据库使用经过验证的技术以结构化方式完成此操作，尽管这需要相当复杂的技术。
数据库为应用程序提供了一个通用的接口来存储和检索数据。开发人员使用这些标准接口和相对简单的查询语言来存储、查询和检索信息。同时，数据库允许用户持续备份和保存数据，以及加密和管理对其的访问。
数据库是存储和检索数据的应用程序，使用一种通用的语言和接口，与许多不同的语言和框架兼容。
通常，有两种常见类型的数据库：结构化查询语言（SQL）数据库和 no-SQL 数据库（译者注：即关系型数据库和非关系型数据库，可以查阅 Design Data-intensive Application 这本书）。应该根据特定应用程序的需求和限制来确定它使用哪种数据库。
随着 Kubernetes 的兴起及其支持有状态应用程序的能力，我们看到了一批新一代数据库利用容器化的优势。这些新的云本地数据库旨在将 Kubernetes 的扩展性和可用性带到数据库中。像 YugabyteDB 和 Couchbase 这样的工具是云本地数据库的例子，尽管 MySQL 和 Postgres 等更传统的数据库也可以在 Kubernetes 集群中成功有效地运行。
Vitess 和 TiKV 是 CNCF 在这个领域的项目。
如果您查看此类别，您会注意到许多名称以 DB 结尾（例如MongoDB，CockroachDB，FaunaDB），您可能会猜到它代表数据库。您还会看到各种以 SQL 结尾的名称（例如 MySQL 或 memSQL）它们仍然相关。有些是“老派”的数据库已经适应了云本地的现实。还有一些数据库是非 SQL 但兼容 SQL 的，例如 YugabyteDB 和 Vitess。
为了实现共同的目标，服务需要相互通信并保持彼此联系。每当一个服务执行某个操作时，它会发送有关该特定事件的消息。
流和消息工具通过在系统之间传输消息（即事件）来实现服务与服务之间的通信。各个服务连接到消息服务以发布事件、从其他服务读取消息或两者兼而有之。这种动态创造了一种环境，其中各个应用程序要么是发布者，即它们编写事件，要么是订阅者，读取事件，或更可能是两者兼而有之。
随着服务的增加，应用程序环境变得越来越复杂，使得应用程序之间的通信管理变得更具挑战性。流和消息平台提供了一个中心位置，用于发布和读取系统内发生的所有事件，使应用程序能够在不必了解彼此的情况下协同工作。
当服务执行其他服务应该知道的操作时，它会将事件“发布”到流式传输或消息传递工具。需要了解这些类型事件的服务会“订阅”并观察流式传输或消息传递工具。这就是发布-订阅或只是 pub-sub 方法的本质，由这些工具实现。
通过引入一个“中间”层来管理所有通信，我们将服务之间解耦。它们只需观察事件、执行操作并发布新事件。
举例来说。当你第一次注册 Netflix 时，“注册”服务会将“新注册事件”发布到消息平台，其中包括姓名、电子邮件地址、订阅级别等详细信息。订阅注册事件的“账户创建器”服务将看到该事件并创建你的账户。还订阅新注册事件的“客户通讯”服务将把你的电子邮件地址添加到客户邮件列表中并生成欢迎电子邮件等等。
这允许高度解耦的架构，在其中服务可以协作而无需知道彼此。这种解耦使工程师能够添加新功能而无需更新下游应用程序（即消费者）或发送一堆查询。系统解耦程度越高，越灵活、易于变更。这正是工程师在系统中所追求的。
在云原生成为主流之前，消息传递和流媒体工具一直存在。为了集中管理业务关键事件，组织机构建立了大型企业服务总线。但是，当我们谈论云原生上的消息传递和流媒体时，我们通常指的是像NATS、RabbitMQ、Kafka 或云提供的消息队列等工具。
这些系统的共同点在于它们所支持的架构模式。在云原生环境中，应用程序交互要么是被编排的，要么是被协调的。这方面还有很多内容，但我们可以简单地说，编排是指集中管理的系统，而协调是指允许各个组件独立地运行的系统。
消息传递和流媒体系统提供了一个中央位置，让协调的系统之间进行通信。消息总线提供了一个共同的位置，所有应用程序都可以通过发布消息来向其他应用程序告知自己正在做什么，或通过订阅消息来了解发生了什么。
NATS 和 Cloudevents 项目都是CNCF的孵化项目。NATS 提供了一个成熟的消息传递系统，而 Cloudevents 是一种标准化消息格式的努力，旨在实现不同系统之间的互通。Strimzi、Pravega 和Tremor是沙盒项目，每个项目都针对流媒体和消息传递的不同用例进行了优化。
应用程序定义和镜像构建是一个广泛的类别，可分为两个主要子类。首先，面向开发人员的工具，可帮助将应用程序代码构建为容器和/或 Kubernetes。其次，面向运营的工具可以以标准化的方式部署应用程序。无论您是要加快还是简化开发环境，提供标准化的方式来部署第三方应用程序，还是希望简化编写新的 Kubernetes 扩展的过程，这个类别都有很多优化 Kubernetes 开发人员和运营商体验而设计的项目。
Kubernetes，或者更普遍的说容器化环境，具有极大的灵活性和强大的功能。随着这种灵活性的增加，也带来了复杂性，主要体现在多个配置选项以及各种用例的多种需求形式上。开发人员需要在将其代码容器化时创建可重复的图像。运营商需要以标准化的方式将应用程序部署到容器环境中，最后，平台团队需要提供工具，以简化内部和第三方应用程序的图像创建和应用程序部署过程。
该领域中的工具旨在解决一些开发人员或运维人员的挑战。在开发人员方面，有一些工具简化了扩展 Kubernetes 来构建、部署和连接应用程序的过程。许多项目和产品可帮助存储或部署预打包的应用程序。这些允许运营商快速部署像 NATS 或 Kafka 这样的流服务，或者安装像 Linkerd 这样的服务网格。
开发云原生应用程序带来了一整套新的挑战，需要大量不同的工具来简化应用程序构建和部署。当您开始解决环境中的运营和开发人员问题时，请寻找此类工具。
应用定义和构建工具涵盖了大量的功能。从使用 KubeVirt 扩展 Kubernetes 到虚拟机，到通过类似 Telepresence 的工具将开发环境移植到 Kubernetes 以加速应用程序开发。在较高层面上，这个空间中的工具解决了开发人员关心的问题，如如何正确编写、打包、测试或运行自定义应用程序，或者解决了操作人员关心的问题，如部署和管理应用程序。
Helm 是该类别中唯一一个毕业项目，它支持许多应用程序部署模式。Helm 允许 Kubernetes 用户部署和自定义许多流行的第三方应用程序，并已被其他项目如 Artifact Hub（CNCF沙盒项目）采用。像 Bitnami 这样的公司还提供了策划的应用程序目录。最后，Helm 足够灵活，可以让用户自定义自己的应用程序部署，并经常被组织用于其自己的内部发布。
Operator Framework 是一个孵化项目，旨在简化构建和部署运算符的过程。运算符超出了本指南的范围，但让我们在这里注意一下，它们有助于部署和管理应用程序，类似于 Helm（您可以在此处阅读有关运算符的更多信息）。Cloud Native Buildpacks 是另一个孵化项目，旨在简化将应用程序代码构建为容器的过程。
在这个空间中还有很多内容，如果您想让Kubernetes更易于开发人员和操作人员使用，请进一步研究这些工具。您可能会发现符合您需求的工具。
持续集成（CI）和持续交付（CD）工具可以实现嵌入式质量保证的快速高效开发。CI 自动化代码更改，立即构建和测试代码，确保它产生可部署的工件。CD 更进一步，将工件通过部署阶段。
成熟的 CI/CD 系统监视源代码的更改，自动构建和测试代码，然后开始将其从开发移动到生产环境，其中必须通过各种测试或验证来确定流程是否应继续或失败。该类别中的工具使这种方法成为可能。
构建和部署应用程序是一个困难且容易出错的过程，特别是当它涉及大量人工干预和手动步骤时。开发人员在没有将软件集成到代码库中的情况下工作的时间越长，发现错误的时间就越长，修复起来就越困难。通过定期集成代码，可以早期发现错误并更容易进行故障排除。毕竟，在几行代码中找到错误要比在几百行代码中找到错误容易得多。更糟的甚至是，在生产环境中发现错误。
虽然像 Kubernete s这样的工具为运行和管理应用程序提供了极大的灵活性，但它们也为 CI/CD 工具提供了新的挑战和机会。云原生 CI/CD 系统可以利用 Kubernetes 本身来构建、运行和管理 CI/CD 流程，通常称为管道。 Kubernetes 还提供有关应用程序健康状况的信息，使云原生 CI/CD 工具更容易确定给定的更改是否成功或应该回滚。
CI 工具确保开发人员引入的任何代码更改或更新都会自动连续地构建、验证和集成到其他更改中。每当开发人员添加更新时，自动化测试会触发，以确保只有良好的代码进入系统。CD 将 CI 扩展到包括将 CI 过程的结果推入类似于生产和生产环境的环境中。
假设开发人员更改 Web 应用程序的代码。CI 系统看到代码更改，然后构建和测试该 Web 应用程序的新版本。CD 系统将该新版本部署到开发、测试、预生产和最终生产环境中。在此过程的每个步骤中测试部署的应用程序。所有这些系统共同代表了该 Web 应用程序的 CI/CD 流水线。
随着时间的推移，许多工具已被构建来帮助将代码从源代码仓库移动到生产环境中。像计算机的大多数其他领域一样，云原生开发的出现改变了 CI/CD 系统。一些传统工具如 Jenkins，可能是市场上最流行的 CI 工具，已经完全进行了 改革，以更好地适应 Kubernetes 生态系统。其他工具，如 Flux 和 Argo，开创了一种名为 GitOps 的连续交付新方法，OpenGitOps 项目正在努力将其定义为供应商中立的标准。
一般来说，您会发现这个领域的项目和产品要么是（1）CI 系统，（2）CD 系统，（3）帮助 CD 系统决定代码是否准备好被推入生产环境的工具，或者（4）对 Spinnaker 和 Argo 的情况，是全部三者。Flux 和 Argo 是这个领域的 CNCF 毕业项目，Keptn 是 CNCF 孵化项目，以及 CNCF 沙盒项目 OpenFeature、OpenGitOps 和 OpenKruise。您还可以在 Continuous Delivery Foundation 中找到许多更多的选项。寻找此领域的工具，以帮助您的组织自动化通往生产环境的路径。
正如我们所看到的，应用程序定义和开发层中的工具使工程师能够构建云本机应用程序。您将找到用于存储和检索数据的数据库，以及用于解耦和编排架构的流媒体和消息传递工具。应用程序定义和镜像构建工具包括各种技术，可改善开发人员和操作员的体验。最后，CI/CD 帮助工程师及早捕捉任何错误，确保代码准备好进行部署，从而提高质量。
本章总结了CNCF景观的各个”层“。接下来，我们将重点关注”可观察性和分析”这一列。
我们已经浏览了CNCF景观的各层，我们现在将关注可观测性和分析的列。
在深入探讨这些类别之前，让我们先定义可观测性与分析。可观测性是一个系统特征，描述了一个系统可以从其外部输出中被理解的程度。计算机系统可以通过 CPU 时间、内存、磁盘空间、延迟、错误等来衡量其可观测性。分析是一种活动，通过观测到的数据来理解它。
为了确保没有服务中断，您需要观测和分析应用程序的每个方面，以便立即检测和纠正每个异常。这就是这个类别的全部内容。它跨越并观测所有层，这就是为什么它在侧面而不是嵌入到特定层中。
这个类别中的工具被分成了日志记录、监控、追踪和混沌工程。请注意，类别名称有些误导——虽然混沌工程列在这里，但请将其视为可靠性工具，而不是可观测性和分析工具。
监控指的是对应用程序进行仪器化，收集、聚合和分析日志和指标，以改善我们对其行为的理解。虽然日志描述了特定事件，但指标是在给定时间点上对系统的测量-它们是两种不同的东西，但都是必要的，以获得系统健康的完整图片。监控包括从在单个节点上监视磁盘空间、CPU 使用率和内存消耗，到执行详细的合成事务，以查看系统或应用程序是否正确响应且及时。有许多不同的监控系统和应用程序监控方法。
运行应用程序或平台时，您希望它按设计完成特定任务，并确保只有经授权的用户访问它。监控使您能够知道它是否正常运行，安全、经济高效，只被授权用户访问，以及您可能正在跟踪的任何其他特征。
良好的监控使运营商可以在发生事故时迅速甚至自动地做出反应。它提供了有关系统当前健康状况的见解，并监视变化。监控跟踪从应用程序健康状况到用户行为的所有内容，是有效运行应用程序的必要部分。
在云原生环境中的监控通常类似于监控传统应用程序。您需要跟踪指标、日志和事件，以了解应用程序的健康状况。主要区别在于，一些托管对象是短暂的，意味着它们可能不会长期存在，因此将您的监视与自动生成的资源名称等对象相关联可能不是一个好的长期策略。在这个领域有许多 CNCF 项目，主要围绕着 CNCF 毕业项目 Prometheus。
应用程序会不断发出描述其在任何给定时间正在执行的操作的日志消息。这些日志消息捕获系统中发生的各种事件，例如失败或成功的操作、审计信息或健康事件。日志记录工具收集、存储和分析这些消息，以跟踪错误报告和相关数据。除了指标和跟踪，日志记录是可观察性的支柱之一。
收集、存储和分析日志是构建现代平台的关键部分，而日志记录执行其中一项或全部任务。有些工具从收集到分析处理所有方面，而其他工具则专注于单个任务，如收集。所有日志记录工具的目标都是帮助组织控制其日志消息。
当收集、存储和分析应用程序日志消息时，您将了解应用程序在任何给定时间正在传达什么信息。但由于日志仅代表应用程序或平台有意发出的消息，因此它们不一定能准确定位给定问题的根本原因。话虽如此，长时间收集和保留日志消息是一种极其强大的能力，将帮助团队诊断问题并满足监管和合规要求。
收集、存储和处理日志消息绝非一个新问题，但云原生模式和 Kubernetes 已经显著改变了日志处理方式。某些传统的日志记录方法适用于虚拟和物理机器，例如将日志写入本地磁盘上的文件，但对于容器化的应用程序则不适用，因为文件系统不会超过应用程序的生命周期。在云原生环境中，类似 Fluentd 的日志收集工具与应用程序容器并行运行，直接从应用程序中收集消息。然后将消息转发到中央日志存储以进行聚合和分析。
Fluentd 是该领域唯一的 CNCF 项目。
在微服务的世界中，服务通过网络不断地相互通信。Tracing 是日志的专业应用，可以让您跟踪分布式系统中请求的路径。
在任何时间点上理解微服务应用程序的行为是一项极具挑战性的任务。虽然许多工具提供了深入的服务行为洞察，但很难将一个单独服务的操作与整个应用程序的行为联系起来。
Tracing 通过为应用程序发送的消息添加唯一标识符来解决这个问题。该唯一标识符允许您跟踪（或跟踪）个别事务在系统中的移动。您可以使用此信息来查看应用程序的健康状况，以及调试有问题的微服务或活动。
Tracing 是一种非常强大的调试工具，可以帮助您调试和微调分布式应用程序的行为。这种强大的功能有一定的代价。应用程序代码需要进行修改以发出跟踪数据，并且需要在应用程序的数据路径上传播任何跨度（表示分布式系统中完成的单个工作单元的表示）。Jaeger和 Open Tracing 是 CNCF 在此领域的项目。
混沌工程是指有意地向系统引入故障，以测试其弹性并确保应用程序和工程团队能够承受动荡和意外事件的做法。混沌工程工具提供了一种受控的方式来引入故障，并针对特定应用程序实例运行特定的实验。
复杂的系统会出现故障。它们失败的原因很多，在分布式系统中，后果通常难以理解。接受故障将会发生的组织采用混沌工程，而不是试图防止故障，实践从故障中恢复。这被称为优化修复时间均值（mean time to repair）, 或MTTR。
传统的维护应用程序高可用性的方法被称为优化故障间隔时间均值（mean time between failures）, 或 MTBF。您可以在使用“变更评审委员会”和“长变更冻结”等措施限制变更以保持应用程序环境稳定的组织中观察到此做法。《Accelerate》的作者认为，高绩效IT组织通过优化修复时间均值（MTTR）实现高可用性。
在云原生世界中，应用程序必须动态地适应故障，这是一个相对较新的概念。这意味着当某些东西失败时，系统不会完全崩溃，而是会优雅地降级或恢复。混沌工程工具使您能够在生产中对软件系统进行实验，以确保它们在真正的故障发生时能够优雅地运行。
简而言之，您通过实验一个系统，因为您想要确信它可以承受动荡和意外的条件。您不是等待某些事情发生并发现它，而是在受控条件下将其置于压力之下，以确定弱点并在机会揭示它们之前修复它们。
混沌工程工具和实践对于实现应用程序的高可用性至关重要。分布式系统通常太复杂，任何一个工程师都无法完全理解，而且没有任何变更流程可以完全预测变更对环境的影响。通过引入有意的混沌工程实践，团队能够练习和自动化故障恢复。Chaos Mesh 和 Litmus Chaos 是这个领域的两个 CNCF 工具。
正如我们所见，可观测性和分析栏旨在理解系统的健康状况，并确保它即使在艰难的情况下也能保持运行。日志记录工具捕获应用程序发出的事件消息，监视器监视日志和指标，而跟踪则跟随单个请求的路径。当结合在一起时，这些工具理想情况下提供了系统内部情况的360度视图。混沌工程有些不同。它提供了一种安全的方法来验证系统是否能够承受意外事件，确保它保持健康。
接下来，我们将重点关注云原生景观图的平台列。想要在整个环境中配置工具，并使它们良好地协同工作不是一件容易的事情。平台将它们捆绑在一起，从而简化了采用。
截至目前为止，我们已经看到了每个讨论的类别都解决了特定的问题。仅存储并不能提供管理应用所需的所有信息。您需要编排工具、容器运行时、服务发现、网络、API网关等。平台从不同层面捆绑了不同的工具，解决了更大的问题。
这些平台本质上并没有什么新东西。它们所做的一切都可以由这些层的工具或可观察性和分析列中的工具之一完成。您当然可以构建自己的平台，实际上，很多组织都这样做。但是，可靠地配置和微调不同的模块并确保所有技术始终保持最新并修补漏洞并不容易，您需要一个专门的团队来构建和维护它。如果您没有必要的资源或知识，您的团队可能最好使用平台。对于一些组织，尤其是那些拥有小型工程团队的组织，平台是采用云原生方法的唯一途径。
您可能会注意到，所有平台都围绕 Kubernetes 展开。这是因为它是云原生技术栈的核心。
分发或者说 distro，指的是供应商使用核心 Kubernetes（它是未修改的开源代码，尽管有些人对它进行了修改），并将它打包以便重新分发。通常会包括查找和验证 Kubernetes 软件以及提供一种机制来处理集群的安装和升级。许多 Kubernetes 分发包括其他专有或开源应用程序。
开源 Kubernetes 并没有指定特定的安装工具，并且将许多设置配置选择留给用户。此外，通过社区资源如[社区论坛]](https://discuss.kubernetes.io/)，[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 或 [Slack]](https://slack.k8s.io/) 提供的支持有限。
虽然随着时间的推移，使用 Kubernetes 变得越来越容易，但是找到并使用开源安装程序仍然具有挑战性。用户需要了解应该使用哪些版本、从哪里获取它们以及某个组件是否与另一个组件兼容。他们还需要决定哪些软件将部署到他们的集群中以及使用哪些设置来确保他们的平台安全、稳定和高效。所有这些都需要深入的 Kubernetes 专业知识，这种知识可能在内部可能不容易获得。
Kubernetes 发行版提供了一种可信赖和可靠的安装 Kubernetes 的方式，并提供了具有建议性的默认设置，从而创建了更好且更安全的操作环境。 Kubernetes发行版为供应商和项目提供了控制和可预测性，以便为客户在部署、维护和升级Kubernetes集群的生命周期中提供支持。
这种可预测性使得发行版提供商能够在生产问题出现时支持用户。发行版通常还提供经过测试和支持的升级路径，使用户能够使其Kubernetes集群保持最新。此外，发行版通常提供在Kubernetes之上部署软件，以使其更易于使用。
发行版大大简化并加快了Kubernetes的采用。由于平台中编写了配置和微调集群所需的专业知识，因此组织可以使用云本地工具快速启动并运行，而无需再雇用具有专业知识的其他工程师。
如果您已经安装了 Kubernetes，您可能使用了像 kubeadm 这样的工具来启动您的集群。即使在那时，您可能仍需要决定使用哪种 CNI、安装和配置它。然后，您可能会添加一些存储类、处理日志消息的工具，也许还有一个入口控制器，等等。Kubernetes 发行版将自动化部分或全部设置。它还将基于其自己的最佳实践解释或智能默认设置提供配置设置。此外，大多数发行版都将捆绑和测试一些扩展或附加组件，以确保您可以尽快启动新的集群。
此类别中有很多选择。k3s 是此类别中唯一的 CNCF 项目。有许多出色的开源和商业选择可供选择。我们鼓励您在开始评估发行版时仔细考虑您的需求。
托管 Kubernetes 是由基础设施提供商（如 AWS、Digital Ocean、Azure 和 Google）提供的一种服务，允许客户按需启动 Kubernetes 集群。云提供商负责管理 Kubernetes 集群的一部分，通常称为控制平面。它们类似于发行版，但由云提供商在其基础设施上进行管理。
托管 Kubernetes 允许团队在不知道或不做任何事情的情况下开始使用 Kubernetes，只需设置与云供应商的帐户即可解决“五 W 中的四个 W”。（Who）谁（管理它）：您的云提供商；（What）什么：他们的托管 Kubernetes 提供；（When）何时：现在；以及（Where）何地：在云提供商的基础设施上。至于（Why）为什么，取决于您。
由于提供商负责所有管理细节，托管 Kubernetes 是开始使用云原生的最简单方法。所有用户需要做的就是开发其应用程序并将其部署到托管 Kubernetes 服务上 - 非常方便。托管 Kubernetes 允许用户立即启动集群并开始使用（除了 AWS 的 EKS 需要用户采取一些额外步骤来准备其集群），同时对集群的可用性负责。值得注意的是，这些服务的额外便利性也带来了一些降低的灵活性。该提供的服务受云提供商的限制，Kubernetes 用户无法访问控制平面。
托管 Kubernetes 是由供应商提供的按需 Kubernetes 集群，通常是基础架构托管提供商。供应商负责提供群集并管理 Kubernetes 控制平面。再次强调，显著的例外是 EKS，其中单个节点的配置由客户自行处理。
托管 Kubernetes 允许组织快速创建新的群集，并通过外包基础架构组件管理来降低其操作风险。主要的权衡是您可能会被收取控制平面管理费用，并且您的操作会受到限制。托管群集提供比 DIY Kubernetes 群集更严格的限制，以配置您的 Kubernetes 群集。
Kubernetes 安装程序有助于在机器上安装 Kubernetes。它们自动化 Kubernetes 的安装和配置过程，甚至可能有助于升级。Kubernetes 安装程序通常与 Kubernetes 发行版或托管 Kubernetes 提供的服务相结合使用。
与 Kubernetes 发行版类似，Kubernetes 安装程序简化了 Kubernetes 的入门。开源 Kubernetes 依赖于像 kubeadm 这样的安装程序，截至本文撰写时，它是认证 Kubernetes 管理员认证考试的一部分，用于启动 Kubernetes 集群。
Kubernetes 安装程序简化了 Kubernetes 的安装过程。与发行版一样，它们为源代码和版本提供了一个经过验证的源。它们通常也带有具有观点的 Kubernetes 环境配置。像 kind （Docker 中的 Kubernetes）这样的 Kubernetes 安装程序允许你通过单个命令获得 Kubernetes 集群。
无论您是在 Docker 上本地安装 Kubernetes，还是在准备新的虚拟机或物理服务器时，您都需要一个工具来处理各种 Kubernetes 组件的准备工作（除非您想用困难的方式来做）。
Kubernetes 安装程序简化了这个过程。有些程序处理节点的启动和配置，而其他程序仅配置您已经预配的节点。它们都提供各种级别的自动化，并适用于不同的用例。在开始使用安装程序时，首先要了解您的需求，然后选择一个适合您需求的安装程序。在撰写本文时，kubeadm 被认为是 Kubernetes 生态系统中非常基本的，因此它被包括在 CKA 认证 Kubernetes 管理员考试的一部分中。Minikube、kind、kops 和 kubespray 都是 CNCF 拥有的 Kubernetes 安装程序项目。
平台即服务（PaaS）是一种环境，允许用户运行应用程序，而不必关心底层计算资源的细节。此类PaaS和容器服务是为开发人员托管PaaS或托管他们可以使用的服务的机制。
我们已经谈论了很多关于云原生的工具和技术。 PaaS试图以一种将在此景观中找到的许多技术以提供直接价值给开发人员的方式进行连接。它回答了以下问题：我将如何在各种环境中运行应用程序？一旦运行，我的团队和用户将如何与它们交互？
PaaS提供有关如何拼凑运行应用程序所需的各种开源和闭源工具的意见和选择。许多提供包括处理PaaS安装和升级以及将应用程序代码转换为运行应用程序的机制的工具。此外，PaaS处理应用程序实例的运行时需求，包括单个组件的按需扩展以及对单个应用程序的性能和日志消息的可见性。
组织采用云原生技术以实现特定的业务或组织目标。PaaS 提供了比构建定制应用程序平台更快的价值路径。像 Cloud Foundry 应用程序运行时这样的工具可以帮助组织快速启动新应用程序。它们擅长提供运行12 factor 或云本地应用程序所需的工具。
任何 PaaS 都有其自己的一套权衡和限制。大多数仅适用于某些语言或应用程序类型，并且这些平台中内置的观点和决策可能适合或不适合您的需求。无状态应用程序在 PaaS 中表现得非常好，但像数据库这样的有状态应用程序通常不行。目前在此领域中没有 CNCF 项目，但大多数提供的服务都是开源的，Cloud Foundry 由 Cloud Foundry 基金会管理。
正如我们所看到的，有多种工具可以帮助简化 Kubernetes 的采用。从 Kubernetes 发行版和托管Kubernetes到更基本的安装程序或 PaaS ，它们都采用了各种安装和配置负担，并为您预先打包。每种解决方案都有其自己的“风味”。供应商对于什么是重要和适当的观点已经内置到解决方案中。
在采用任何这些解决方案之前，您需要进行一些研究，以确定最适合您特定用例的解决方案。您是否可能会遇到需要控制控制平面的高级 Kubernetes 场景？如果是这样，托管解决方案可能不适合。您是否有一个小团队管理“标准”工作负载，需要尽可能卸载尽可能多的操作任务？有多个方面需要考虑。虽然并不存在适用于所有用例的单一最佳工具，但肯定会有最适合您需求的最佳工具。
现在我们已经将 CNCF 云原生景观分层并逐层、逐类别地进行了讨论，这样理解起来就不那么压抑了。一旦你理解了其逻辑结构，畅游这个景观就会更加容易。
CNCF 景观的层次结构是相互依赖的。首先是配置层，它包含了构建基础设施所需的工具。接下来是运行时层，其中一切都围绕容器展开，以及在云原生环境中运行所需的工具。编排和管理层包含编排和管理容器和应用程序所需的工具，换句话说，是创建应用程序的平台所需的工具。应用程序定义层涉及到存储和发送数据的应用程序所需的工具，以及构建和部署应用程序的方式。
在讲解完两层后，下面是两列。可观测性和分析列包括监视应用程序并在出现问题时标记的工具。由于所有层都必须进行监视，因此此类别跨越所有层。最后，有平台列。平台不提供新功能，而是将不同层中的多个工具捆绑在一起，配置和微调它们，使其准备好使用。这简化了云原生技术的采用，甚至可能是组织能够利用它们的唯一方式。
这就是CNCF景观指南的全部内容。我们希望您阅读愉快，使得景观图看起来更加清晰。
云原生领域发展迅速。如果您发现任何过时的内容，请提交PR以便我们更新。我们希望这是一份活着的文档，感谢您的贡献。