关于云计算:必看史上最全云原生全景图解读攻略来啦

起源 | 尔达 Erda 公众号

如果你钻研过云原生应用程序和相干技术，大概率你遇到过 CNCF 的云原生全景图。这张全景图技术之多、规模之大无疑会让人感到震惊，那么咱们该如何去了解这张图呢？

如果把它拆开来，一次只剖析一小块内容，你会发现整个全景图没有那么简单。事实上，该全景图依照性能有序地组织在一起，一旦你理解了每个类别代表的内容，你就能够轻松游走于全景图中。

本文咱们首先把整个全景图拆解开来，并对整个全景图进行综述，接着聚焦在每一层（or 每一列），对每个类别解决的问题和原理进行了更为具体的解读。

首先，咱们剥离掉所有单个的技术，仅查看类别（如下图）。图中有不同的“行”，像修建的不同层，每层都有本人的子类别。最底层提供了构建云原生基础设施的工具。往上，你能够开始增加运行和管理应用程序所需的工具，比方运行时和调度层。在最上层，有定义和开发应用程序的工具，比方数据库、镜像构建和 CI/CD 工具（咱们将在后文探讨）。

好了，当初你应该记住了云原生全景图始于基础设施，往上的每一层都更靠近理论的应用程序。这就是每层代表的意思（前面咱们会探讨上图左边的两“列”）。上面咱们就从最底层开始，逐层进行解析。

供给指的是为云原生利用筹备规范根底环境所波及的工具。它蕴含了基础设施的创立、治理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供给层通过提供设置和施行策略，在应用程序和平台中构建身份验证和受权，以及解决密钥散发等等的工具，也拓展到了平安畛域。

供给层包含：

自动化和部署工具：帮忙工程师在无需人工干预状况下即可构建计算环境；
容器注册表：存储应用程序的可执行文件；
不同平安畛域的平安和合规框架；密钥治理解决方案：通过加密确保只有受权的用户能力拜访特定的应用程序。
这些工具使工程师能够编写基础设施参数，使零碎能够按需搭建新环境，确保了一致性和安全性。

接下来是运行时层。这个词可能会让你感到蛊惑。像很多 IT 术语一样，运行时没有严格的定义，且能够依据语境有不同的用法。广义上讲，运行时是特定机器上筹备运行应用程序的沙盒——也就是保障应用程序失常运行所需的最低配置。狭义上讲，运行时是运行一个应用程序所需的所有工具。

在 CNCF 云原生全景图中，运行时保障了容器化应用程序组件的运行和通信，包含：

云原生存储：为容器化利用提供虚构磁盘或长久化存储；
容器运行时：为容器提供隔离、资源和平安；
云网络：分布式系统的节点（机器或过程）通过其连贯和通信。

一旦依照平安和合规性规范（供给层）自动化基础设施供给，并装置了利用程序运行所需的工具（运行时层），工程师就须要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务（应用程序组件）作为一个群组治理。这些容器化服务须要互相辨认和通信，并须要进行协调。这一层可为云原生利用提供自动化和弹性能力，使云原生利用人造具备可扩展性。

这一层蕴含：

编排和调度：部署和治理容器集群，确保它们具备弹性伸缩能力，相互之间低耦合，并且可扩大。事实上，编排工具（绝大多数状况下就是 Kubernetes）通过治理容器和操作环境形成了集群；
协调和服务发现：使得服务（应用程序组件）之间能够互相定位和通信；
近程过程调用（RPC）：使跨节点服务间通信的技术；
服务代理：服务间通信的中介。服务代理的惟一目标就是对服务之间的通信进行更多管制，而不会对通信自身增加任何内容。服务代理对上面将提到的服务网格（Service Mesh）至关重要。
API 网关：一个形象层，内部利用可通过 API 网关进行通信；
Service Mesh：某种程度上相似于 API 网关，它是应用程序进行通信的专用基础架构层，提供基于策略的外部服务间通信。此外，它还可能蕴含流量加密、服务发现、应用程序监控等内容。

当初，咱们来到了最顶层。利用定义和开发层，顾名思义，汇集了让工程师构建和运行应用程序的工具。上述所有内容都是对于构建牢靠、平安的环境，以及提供全副所需的应用程序依赖。

这一层包含：

数据库：使应用程序能以有序的形式收集数据；
流和消息传递：使应用程序能发送和接管音讯（事件和流）。它不是网络层，而是让音讯成为队列并解决音讯的工具；
利用程序定义和镜像构建：用于配置、保护和运行容器镜像（应用程序的可执行文件）的服务；
继续集成和继续交付（CI/CD）：使开发者可主动测试代码是否与代码库（应用程序的其余部分）兼容。如果团队足够成熟，甚至能够主动部署代码到生产环境。

接下来咱们将进入到云原生全景图右侧贯通所有层的两列。可察看性和剖析（Observability&analysis）是监控各层的工具，平台则将各层中不同的技术捆绑为一个解决方案。

为了限度服务中断并升高解决问题的均匀工夫（MRRT），你须要监控和剖析应用层序的方方面面，以便在出现异常时可立刻发现并纠正。简单环境中容易呈现故障，这些工具可疾速辨认并解决故障，从而升高故障带来的影响。因为这一类别贯通并监控各层，因而它在侧面，而不是嵌入到某一层中。

这一类别你将发现：

日志工具：收集事件日志（无关过程的信息）；
监控计划：收集指标（以数字示意的零碎参数，例如 RAM 可用性）；
追踪工具：追踪比监控更进了一步，它们监控用户申请的流传，与服务网格相干。
混沌工程（Chaos Engineering）：在生产环境中测试软件的工具，可辨认缺点并进行修复，缩小其对服务交付的影响。

能够看到，图中每一个模块解决一个特定的问题。但咱们晓得，仅有存储并不能提供应用程序所需的全副性能。你还须要编排工具、容器运行时、服务发现、网络和 API 网关等等。平台笼罩多层，将不同的工具组合在一起，以解决更大的问题。

配置和微调不同的模块使其安全可靠，并确保它利用的技术都能及时更新、所有破绽都打了补丁，这并不是一件容易的事件。应用平台时，用户不必额定放心这些细节问题。

你可能会留神到，所有的类别都围绕着 Kubernetes 开展。这是因为 Kubernetes 尽管只是云原生景观图这张拼图中的一块，但它却是云原生技术栈的外围。顺便说一下，CNCF 刚创立时，Kubernetes 就是其中的第一个种子我的项目，起初才有了其余我的项目。

平台可分为四类：

K8s 发行版：采纳未经批改的凋谢源代码（只管有人对其进行了批改），并依据市场须要减少了其余性能。
托管的 K8s：相似于 Kubernetes 发行版，然而由提供商托管。
K8s 安装程序：主动执行 Kubernetes 的装置和配置过程。
PaaS / 容器服务：相似于托管的 Kubernetes，然而蕴含了一套更宽泛的利用部署工具（通常是来自云原生景观图）。

在每个类别中，针对雷同或类似的问题，都有不同的工具可抉择。有一些是实用于新事实的预云原生技术，还有一些则是全新的。区别在于它们的实现和设计办法。没有完满的技术合乎你的所有需要。大多数状况下，技术受设计和架构抉择的限度——始终须要衡量取舍。

在抉择技术栈时，工程师必须认真思考每种能力和须要衡量取舍的中央，以确定最合适的选项。尽管这样会让状况变得更简单，但在抉择应用程序所需的最适宜的数据存储、基础设施治理、音讯零碎等计划时，这样做是最可行的方法。当初，构建一个零碎比云原生之前的时代容易多了。如果构建失当，云原生技术将提供更弱小的灵活性。在现如今疾速变动的技术生态中，这可能是最重要的能力之一。

上面咱们来具体介绍云原生全景图的每一层。

云原生全景图的最底层是供给层（provisioning）。这一层蕴含构建云原生基础设施的工具，如基础设施的创立、治理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供给层也跟平安相干，该层中的一些工具可用于设置和施行策略，将身份验证和受权内置到应用程序和平台中，以及解决 secret 散发等。

接下来让咱们看一下供给层的每个类别，它所表演的角色以及这些技术如何帮忙应用程序适应新的云原生环境。

自动化和配置工具可放慢计算资源（虚拟机、网络、防火墙规定、负载均衡器等）的创立和配置过程。这些工具能够解决基础设施构建过程中不同局部的内容，大多数工具都可与该空间中其余我的项目和产品集成。

传统上，IT 流程依赖高强度的手动公布过程，周期简短，通常可达 3-6 个月。这些周期随同着许多人工流程和管控，让生产环境的变更十分迟缓。这种迟缓的公布周期和动态的环境与云原生开发不匹配。为了缩短开发周期，必须动静配置基础设施且无需人工干预。

供给层的这些工具使工程师无需人工干预即可构建计算环境。通过代码化环境设置，只需点击按钮即可实现环境配置。手动设置容易出错，然而一旦进行了编码，环境创立就会与所需的确切状态相匹配，这是一个微小的劣势。

只管不同工具实现的办法不同，但它们都是通过自动化来简化配置资源过程中的人工操作。

当咱们从老式的人工驱动构建形式过渡到云环境所需的按需扩大模式时，会发现以前的模式和工具曾经无奈满足需要，组织也无奈维持一个须要创立、配置和治理服务器的 7×24 员工队伍。Terraform 之类的自动化工具缩小了扩大数服务器和相干网络以及防火墙规定所需的工作量。Puppet、Chef 和 Ansible 之类的工具能够在服务器和应用程序启动时以编程形式配置它们，并容许开发人员应用它们。

一些工具间接与 AWS 或 vSphere 等平台提供的基础设施 API 进行交互，还有一些工具则侧重于配置单个计算机以使其成为 Kubernetes 集群的一部分。Chef 和 Terraform 这类的工具能够进行互操作以配置环境。OpenStack 这类工具可提供 IaaS 环境让其余工具应用。

从根本上讲，在这一层，你须要一个或多个工具来为 Kubernetes 集群搭建计算环境、CPU、内存、存储和网络。此外，你还须要其中的一些工具来创立和治理 Kubernetes 集群自身。

在撰写本文时，该畛域中有三个 CNCF 我的项目：KubeEdge（一个沙盒我的项目）以及 Kubespray 和 Kops（后两个是 Kubernetes 子项目，尽管未在全景图中列出，但它们也属于 CNCF）。此类别中的大多数工具都提供开源和付费版本。

[外链图片转存失败, 源站可能有防盗链机制, 倡议将图片保留下来直

在定义 Container Registry 之前，咱们首先探讨三个严密相干的概念：

容器是执行流程的一组技术束缚。容器内启动的过程会置信它们正在本人的专用计算机上运行，而不是在与其余过程（相似于虚拟机）共享的计算机上运行。简而言之，容器能够使你在任何环境中都能管制本人的代码运行。
镜像是运行容器及其过程所需的一组存档文件。你能够将其视为模板的一种模式，能够在其上创立有限数量的容器。
仓库是存储镜像的空间。

回到 Container Registry，这是分类和存储仓库的专用 Web 应用程序。

镜像蕴含执行程序（在容器内）所需的信息，并存储在仓库中，仓库被分类和分组。构建、运行和治理容器的工具须要拜访（通过援用仓库）这些镜像。

云原生应用程序被打包后以容器的形式运行。Container Registry 负责存储和提供这些容器镜像。

通过在一个中央集中存储所有容器镜像，这些容器镜像能够很容易地被应用程序的开发者拜访。

Container Registry 要么存储和散发镜像，要么以某种形式加强现有仓库。实质上，它是一种 Web API，容许容器引擎存储和检索镜像。许多 Container Registry 提供接口，使容器扫描 / 签名工具来加强所存储镜像的安全性。有些 Container Registry 能以特地无效的形式散发或复制图像。任何应用容器的环境都须要应用一个或多个仓库。

该空间中的工具能够提供集成性能，以扫描、签名和查看它们存储的镜像。在撰写本文时，Dragonfly 和 Harbor 是该畛域中的 CNCF 我的项目，而 Harbor 最近成为了第一个遵循 OCI 的仓库。次要的云提供商都提供本人的托管仓库，其余仓库能够独立部署，也能够通过 Helm 之类的工具间接部署到 Kubernetes 集群中。

云原生应用程序的指标是疾速迭代。为了定期公布代码，必须确保代码和操作环境是平安的，并且只能由取得受权的工程师拜访。这一部分的工具和我的项目能够用平安的形式创立和运行古代应用程序。

这些工具和我的项目可为平台和应用程序增强、监控和施行安全性。它们使你能在容器和 Kubernetes 环境中设置策略（用于合规性），深刻理解存在的破绽，捕捉谬误配置，并加固容器和集群。

为了平安地运行容器，必须对其进行扫描以查找已知破绽，并对其进行签名以确保它们未被篡改。Kubernetes 默认的访问控制比拟宽松，对于想攻打零碎的人来说，Kubernetes 集群很容易成为指标。该空间中的工具和我的项目有助于加强群集，并在零碎运行异样时提供工具来检测。

为了在动静、疾速倒退的环境中平安运行，咱们必须将安全性视为平台和利用程序开发生命周期的一部分。这部分的工具品种繁多，可解决平安畛域不同方面的问题。大多数工具属于以下类别：

审计和合规
生产环境强化工具的门路
- 代码扫描
- 破绽扫描
- 镜像签名
策略制订和执行
网络层平安

其中的一些工具和我的项目很少会被间接应用。例如 Trivy、Claire 和 Notary，它们会被 Registry 或其余扫描工具所利用。还有一些工具是古代应用程序平台的要害强化组件，例如 Falco 或 Open Policy Agent（OPA）。

该畛域有许多成熟的供应商提供解决方案，也有很多守业公司的业务是把 Kubernetes 原生框架推向市场。在撰写本文时，Falco、Notary/TUF 和 OPA 是该畛域中仅有的 CNCF 我的项目。

在进入到密钥治理之前，咱们首先定义一下密钥。密钥是用于加密或签名数据的字符串。和事实中的钥匙一样，密钥锁定（加密）数据，只有领有正确密钥的人才能解锁（解密）数据。

随着应用程序和操作开始适应新的云原生环境，平安工具也在一直倒退以满足新的需要。此类别中的工具和我的项目可用于平安地存储明码和其余 secrets（例如 API 密钥，加密密钥等敏感数据）、从微服务环境中平安删除明码和 secret 等。

云原生环境是高度动静的，须要齐全编程（无人参加）和自动化的按需 secret 散发。应用程序还必须晓得给定的申请是否来自无效起源（身份验证），以及该申请是否有权执行操作（受权）。通常将其称为 AuthN 和 AuthZ。

每个工具或我的项目施行的办法不同，但他们都提供：

平安散发 secret 或密钥的办法。
身份认证或（和）受权的服务或标准。

此类别中的工具能够分为两组：

一些工具专一于密钥生成、存储、治理和轮转。
另一些专一于单点登录和身份治理。

拿 Vault 来说，它是一个通用的密钥管理工具，可治理不同类型的密钥。而 Keycloak 则是一个身份代理工具，可用于治理不同服务的拜访密钥。

在撰写本文时，SPIFFE/SPIRE 是该畛域中惟一的 CNCF 我的项目。

供给层专一于构建云原生平台和应用程序的根底，其中的工具波及基础设施供给、容器注册表以及安全性。本章节具体介绍了云原生全景图的最底层。

本章节咱们将一起理解运行时层（runtime），这一层蕴含了容器在云原生环境中运行所需的所有。即：启动容器的代码，也叫运行时引擎；使容器取得长久化存储的工具；以及治理容器环境网络的工具。

然而留神，不要将这一层的资源与基础设施和供给层的网络和存储弄混同，后者的工作是让容器平台运行起来。容器间接应用运行时层的工具来启动或进行，存储数据，以及互相通信。

存储是寄存一个应用程序持久数据的中央，也叫做长久卷（persistent volume)。轻松拜访长久卷对于应用程序牢靠运行至关重要。通常，当咱们说持久数据的时候，咱们是指数据库、音讯之类的，或其余任何在利用重新启动时不会失落的信息。

云原生架构具备高度的灵活性和弹性，这使得重启利用时存储持久数据变得很有挑战性。容器化应用程序在扩容、缩容或主动复原时，会一直地创立或删除实例，并随着工夫扭转物理地位。因而，必须以与节点无关的形式提供云原生存储。然而，要存储数据，就须要硬件（具体来说是磁盘）。磁盘和其余硬件一样，受到基础设施的限度。这是第一个大的挑战。

第二个挑战是存储接口。该接口在数据中心之间可能会产生很大的变动（在以前，不同的基础设施都有本人的存储解决方案，并带有本人的接口），这使得可移植性变得十分艰难。

最初，因为云的弹性，存储必须以自动化形式进行配置，因为手动配置和主动扩大不兼容。面临以上这些问题，云原生存储就是为新的云原生环境量身定制的。

该类别的工具能够：

为容器提供云原生存储选项；
标准化容器与存储提供者之间的接口；
通过备份和还原操作提供数据保护。

云原生存储意味着应用兼容云原生环境的容器存储接口（也就是下一个类别中的工具），并且能够主动配置，通过打消人力瓶颈从而实现了主动扩大和自我复原。

容器存储接口（CSI）在很大水平上使云原生存储变成了可能。CSI 容许应用规范 API 向容器提供文件和块存储。该畛域中有很多工具，既有开源的也有供应商提供的，都可利用 CSI 为容器提供按需存储。

除了这一及其重要的性能，还有一些其余的工具和技术旨在解决云原生空间中的存储问题。Minio 是一个受欢迎的我的项目，它提供了兼容 S3 的 API 用于对象存储。Velero 之类的工具可帮忙简化 Kubernetes 集群自身以及应用程序应用的长久化数据的备份和还原过程。

后面咱们提到过，容器是一组用于执行应用程序的技术束缚。容器化的应用程序置信本人正在专用计算机上运行，而疏忽了它们其实是与其余过程（相似于虚拟机）共享资源。

容器运行时是执行容器化（或“隔离”）利用的软件。如果没有运行时，将只有容器镜像——指定容器化应用程序外观的文件。运行时将在容器中启动应用程序，并为其提供所需的资源。

容器镜像（带有应用程序标准的文件）必须以标准化、平安和隔离的形式启动：

标准化：无论它们在何处运行，都须要规范操作规定；
平安：拜访权限应该要留神设置；
隔离：该应用程序不应影响其余应用程序或受到其余应用程序的影响（例如，位于同一地位的应用程序解体）。隔离基本上起到爱护作用。

此外，必须为应用程序提供 CPU、存储、内存等资源。

容器运行时能够实现所有这些工作。它以标准化形式在所有环境中启动应用程序，并设置平安边界。平安边界是运行时和其余工具不同的中央，CRI-O 或 gVisor 等运行时强化了它们的安全性边界。运行时还为容器设置资源限度。没有资源限度，应用程序可能会依据须要耗费资源，这样就有可能占用其余应用程序的资源。因而设置资源限度是很必要的。

不是所有此类别中的工具都一样。Containerd（Docker 产品的一部分）和 CRI-O 是规范的容器运行时实现。有一些工具能够将容器的应用扩大到其余技术，例如 Kata，它容许将容器作为 VM 运行。其余工具旨在解决与容器相干的特定问题，例如 gVisor，它在容器和 OS 之间提供了额定的平安层。

容器通过云原生网络实现相互之间及和基础设施层之间的通信。分布式应用程序具备多个组件，这些组件将网络用于不同目标。此类别中的工具将虚构网络覆盖在现有网络之上，专门用于应用程序进行通信，称为笼罩网络（overlay network)。

通常咱们将在容器中运行的代码称为应用程序，但实际上，大多数容器中仅蕴含大型应用程序的一小部分特定性能。诸如 Netflix 或 Gmail 之类的古代应用程序实际上由许多较小的组件组成，每个组件都在本人的容器中运行。为了使所有这些独立的局部失常运行组成一个残缺的利用，容器之间须要互相通信。此类别的工具就提供该专用通信网络。

此外，这些容器之间替换的音讯可能是私密的、敏感的或者十分重要的。这导致了其余要求：例如为各种组件提供隔离，查看流量以辨认网络问题的能力。在某些状况下，可能还须要拓展这些网络及网络策略（如防火墙和拜访规定），以便应用程序能够连贯到容器网络内部运行的 VM 或服务。

此类别中的我的项目和产品应用 CNCF 中的我的项目——容器网络接口（Container Network Interface, CNI）为容器化利用提供网络性能。某些工具（例如 Flannel）仅为容器提供根本连贯。其余工具（如 NSX-T）提供了残缺的软件定义网络层，可为每个 Kubernetes 名称空间创立一个隔离的虚构网络。

容器网络至多应该能为 Pod（Kubernetes 中运行容器化利用的中央）调配 IP 地址，以容许其余过程拜访。

CNI 标准化了网络层为 Pod 提供性能的形式，这在很大水平上实现了该畛域的多样性和创新性。为 Kubernetes 环境选择网络十分要害，有许多工具可选。Weave Net，Antrea，Calico 和 Flannel 均提供无效的开源网络层，它们的性能各不相同，应依据特定需要进行抉择。

此外，许多供应商已筹备好应用软件定义网络（SDN）工具来反对和扩大 Kubernetes 网络，这些工具可使你深刻理解网络流量，执行网络策略，甚至将容器网络和策略扩大到更宽泛的数据中心。

本文是对运行时层的概述，该层提供了容器在云原生环境中运行所需的工具，包含：

存储：使应用程序轻松快速访问运行所需的数据；
容器运行时：执行利用程序代码；
网络：确保容器化应用程序之间的通信。

在下一章节中，咱们将摸索编排和管理层，该层解决的是如何将所有容器化应用程序作为一个组进行治理。

编排和管理层是 CNCF 云原生全景图的第三层。在应用这一层的工具之前，工程师大略曾经依照平安合规规范主动配置了基础设施，并为应用程序设置了运行时（运行时层）。当初，他们必须弄清楚如何将所有应用程序组件作为整体来编排和治理。这些组件必须互相辨认以进行通信，并通过协调实现独特的指标。编排和管理层的工具可实现自动化和弹性伸缩，基于此云原生应用程序人造具备可扩展性。

编排和调度是指在集群中运行和治理容器（一种打包和运送利用的新形式）。集群是通过网络连接的一组机器（物理机或虚拟机均可）。

容器编排器（和调度器）与电脑上治理所有应用程序（如微软 360、Zoom、Slack 等）的操作系统相似。操作系统执行你想应用的应用程序，并布局哪个应用程序该在何时应用电脑的 CPU 和其余硬件资源。

尽管在一台机器上运行所有货色很棒，但现在大多数应用程序的大小远非一台机器所能解决，大多数古代的应用程序都是分布式的，这就须要一种软件可能治理在不同机器上运行的组件。简略来说，你须要一个“集群操作系统”。这就是编排工具。

你可能曾经留神到了，在本系列的前几篇文章中，容器频繁呈现。容器能够让利用程序运行在不同的环境中，这种能力是要害。容器编排器（大多数状况下是指 Kubernetes）也是如此。容器和 Kubernetes 是云原生架构的外围，所以咱们总是听到他人提起它们。

在云原生架构中，应用程序被分解成很多小的组件或服务，每个组件或服务都放在一个容器里。你可能曾经据说过微服务，指的就是这种状况。当初，你领有的不再是一个大型的应用程序，而是多个小型的服务，每个服务都须要资源、要被监控，在呈现问题的时候也须要修复。对单个服务来说手动执行这些操作是可行的，但当你有上百个容器时，你就须要自动化的流程。

容器编排器自动化了容器治理的过程。这在实际操作中意味着什么？让咱们以 Kubernetes 来答复这个问题，因为 Kubernetes 是事实上的容器编排器。

Kubernetes 做的事件是“冀望状态协调”：将集群中容器的以后状态与冀望状态匹配。工程师在文件中指定所需状态，例如：服务 A 的 10 个实例在三个节点（即：机器）上运行，可拜访 B 数据库，等等。该状态需继续与理论状态进行比拟。如果预期状态与理论状态不匹配，Kubernetes 会通过创立或销毁对象来进行协调（例如：如果某个容器解体了，Kubernetes 会启动一个新的容器）。

简而言之，Kubernetes 容许你将集群视为一台计算机。它仅关注环境并为你解决实现细节。

Kubernetes 与其余容器编排器（Docker Swarm，Mesos 等）都是编排调度工具，其根本目标是容许将多个不同的计算机作为一个资源池进行治理，并以申明式的形式治理它们，即不用通知 Kubernetes 如何做，而是提供要实现的工作的定义。这样能够在一个或多个 YAML 文件中保护所需的状态，并将其利用于其余 Kubernetes 集群。而后，编排器自身会创立缺失的内容或删除无需存在的货色。

尽管 Kubernetes 不是 CNCF 托管的惟一编排器（Crossplane 和 Volcano 是另外两个孵化我的项目），但它是最罕用的，我的项目也有大量踊跃的维护者。

古代应用程序由多个独自的服务组成，这些服务之间须要相互协作能力为最终用户提供价值。要进行合作，这些服务通过网络进行通信（咱们在运行时层曾经探讨过）。要通信，服务须要能互相定位。服务发现就是解决这个问题的。

云原生架构是动静的，总是在一直变动。当一个节点上的某个容器解体时，一个新的容器会在另一个节点上启动来代替它。或者，当一个应用程序扩大时，它的正本会分布在整个网络中。没有一个中央能够提供特定服务，所有的地位在一直变动。此类别的工具跟踪网络中的服务，以便服务在须要时能够互相查找。

服务发现工具可提供一个公共的地位来查找和辨认单个的服务。该类别中有两种工具：

服务发现引擎：相似数据库的工具，存储的信息包含：存在什么哪些服务以及如何定位它们；
名称解析工具（如 CoreDNS）：接管服务地位申请并返回网络地址信息。

注：在 Kubernetes 中，为了使 Pod 可达，引入了一个称为“Service”的新形象层。Service 为动态变化的 Pod 组提供了繁多稳固的地址。

请留神，“Service”在不同的语境中有不同的含意，可能会造成混同。“services”通常指位于容器 /Pod 中的服务，是理论应用程序中具备特定性能的利用组件或微服务（例如：iPhone 的面部辨认算法）。

而 Kubernetes 的 Service 是一种形象，可帮忙 Pod 互相查找和定位。它是服务（性能上的）作为过程或 Pod 的入口点。在 Kubernetes 中，当你创立了一个 Service（形象），你就创立了一组 Pod，这些 Pod 一起通过繁多 endpoint（入口）提供一个服务（性能）。

随着分布式系统变得越来越广泛，传统的 DNS 流程和负载均衡器曾经无奈跟上一直变动的 Endpoint 信息，因而有了服务发现工具。它们可用来解决疾速对本身进行注册和登记的各个应用程序实例。一些服务发现工具（例如 etcd 和 CoreDNS）是 Kubernetes 原生的，其余一些工具有自定义的库或工具让服务无效运行。CoreDNS 和 etcd 是 CNCF 我的项目，并且内置在 Kubernetes 中。

近程过程调用（RPC，Remote Procedure Call）是一种使应用程序互相通信的非凡技术。它代表了应用程序相互之间构建通信的一种办法。

古代应用程序由泛滥独自的服务组成，这些服务必须通过通信能力进行合作。RPC 是应用程序之间进行通信的一种办法。

RPC 能够一种紧耦合且高度盲目的形式解决服务之间的通信。它容许带宽高效的通信，并且许多语言反对 RPC 接口实现。RPC 不是解决此问题的惟一办法，也不是最常见的办法。

RPC 为服务之间的通信提供了高度结构化且严密耦合的接口。gRPC 是十分风行的 RPC 实现，已被 CNCF 采纳。

服务代理工具用于拦挡进出某个服务的流量，对其利用一些逻辑，而后转发该流量到另一个服务。服务代理的实质是一种“中间人”，收集网络流量的信息并对其利用规定。简略如充当负载均衡器将流量转发到单个应用程序，也可简单如并排运行的代理网格，由单个的容器化利用程序处理所有网络连接。

服务代理自身很有用，尤其是在将流量从更宽泛的网络引到 Kubernetes 集群时。服务代理同时也为其余零碎（如 API 网关或服务网格）搭建了根底，咱们将在下文探讨。

应用程序应以受控形式发送和接管网络流量。为了跟踪流量并对其进行转换或重定向，咱们须要收集数据。传统上，开启数据收集和网络流量治理的代码嵌入在每个应用程序中。服务代理能够使咱们“内部化”该性能，使其无需再存在于应用程序中，而是嵌入到平台层（利用程序运行的中央）。

这是十分弱小的性能，因为它使开发人员能够齐全专一于编写利用程序逻辑，而解决流量的通用工作由平台团队治理（这是平台团队的首要职责）。通过从单个公共地位集中调配和治理全局所需的服务性能（例如路由或 TLS 终止），服务之间的通信将更加牢靠，平安和高效。

代理充当用户和服务之间或不同服务之间的守门员。通过这种独特的定位，他们能够洞悉正在产生的通信类型。依据洞察，他们能够确定将特定申请发送到哪里，甚至齐全回绝该申请。

代理收集要害数据，治理路由（在服务之间平均分配流量或在某些服务产生故障时从新路由），加密连贯和缓存内容（缩小资源耗费）。

服务代理的工作原理是拦挡服务之间的流量，对它们执行一些逻辑，而后可能会容许流量继续前进。通过将一组集中控制的性能放入此代理，管理员能够实现几件事。他们能够收集无关服务间通信的具体指标，避免服务过载，并将其余通用规范利用于服务。服务代理是服务网格等其余工具的根底，因为它们提供了对所有网络流量施行更高级别策略的办法。

请留神，CNCF 将负载均衡器和 ingress provider 包含在此类别中。Envoy，Contour 和 BFE 都是 CNCF 我的项目。

人们通常通过网页或（桌面）应用程序之类的 GUI（图形用户界面）与计算机程序进行交互，计算机则通过 API（应用程序编程接口）互相进行交互。然而，请勿将 API 与 API 网关混同。

API 网关容许组织将要害性能（例如受权或限度应用程序之间的申请数量）挪动到集中管理的地位。它还用作（通常是内部的）API 使用者的通用接口。

通过 API 网关，组织能够集中控制（限度或启用）应用程序之间的交互并跟踪它们，从而实现拒绝请求、身份验证之类的性能，并避免服务被适度应用（也称为速率限度）。

只管大多数容器和外围应用程序都具备 API，但 API 网关不仅仅是 API。API 网关简化了组织治理规定和将规定利用于所有交互的形式。

API 网关容许开发人员编写和保护较少的自定义代码。他们还使团队可能查看和管制用户与应用程序自身之间的交互。

API 网关位于用户和应用程序之间。它充当中介，将来自用户的音讯（申请）转发给适当的服务。然而在交出申请之前，它会评估用户的申请是否被容许，并具体记录发出请求的人以及收回的申请数量。

简而言之，API 网关为应用程序用户提供了具备通用用户界面的单入口点。它还能够将本来在应用程序中实现的工作移交给网关，从而为开发人员节省时间和金钱。

像该层中的许多类别一样，API 网关从应用程序中删除自定义代码，并将其带入地方零碎。API 网关的工作原理是拦挡对后端服务的调用，执行某种增值流动，例如验证受权、收集指标或转换申请，而后执行它认为适当的操作。API 网关是一组上游应用程序的通用入口点，同时为团队提供了能够注入业务逻辑以解决受权，速率限度和拒绝请求的中央。它们使利用开发者能够从客户那里提取对上游 API 的更改，并将增加新客户之类的工作交给网关。

如果你曾经理解了一些云原生相干的常识，则“服务网格”这个术语可能曾经据说过。最近服务网格引起了很多关注。TNS 的长期贡献者 Janakiram MSV 示意，“在 Kubernetes 之后，服务网格技术已成为云原生技术栈中最要害的局部。”服务网格治理服务之间的流量（即通信）。它们使平台团队可能无需更改任何代码即可在集群内运行的所有服务之间对立增加可靠性，可察看性和安全性性能。

在云原生环境中，咱们要解决很多服务，这些服务都须要通信。这意味着在原本不牢靠且通常很慢的网络上须要来回传输更多流量。为了应答这些新挑战，工程师必须施行额定的性能。在服务网格之前，必须将该性能编码到每个独自的应用程序中。这些代码通常会成为技术债，并导致失败或破绽。

服务网格在平台层的所有服务之间对立减少了可靠性，可察看性和安全性，而无需涉及利用程序代码。它们与任何编程语言兼容，使开发团队能够专一于编写业务逻辑。

注：传统上必须将这些服务网格性能编码到每个服务中，因而每次公布或更新新服务时，开发人员都必须确保这些性能也能应用，会导致很多人为谬误。事实上，开发人员更喜爱专一于业务逻辑（产生价值的性能），而不是建设可靠性，可察看性和安全性性能。但对于平台所有者来说，可靠性、可察看性和平安是外围性能，对于他们所做的所有至关重要。让开发人员负责增加平台所有者须要的性能自身很难。服务网格和 API 网关解决了这个问题，因为它们是由平台所有者实现并广泛利用于所有服务的。

服务网格通过服务代理将集群上运行的所有服务绑定在一起，从而创立了服务的网格。这些是通过服务网格管制立体进行治理和管制的。服务网格容许平台所有者在不要求开发人员编写自定义逻辑的状况下执行常见操作或在应用程序上收集数据。实质上，服务网格是通过向服务代理的网络或网格提供命令和管制信号来治理服务间通信的根底结构层。它的能力在于无需批改应用程序即可提供要害零碎性能。

某些服务网格将通用服务代理（请参见上文）用于其数据立体。另外一些则应用专用代理。例如，Linkerd 应用 Linkerd2-proxy“微型代理”来取得性能和资源耗费方面的劣势。这些代理通过边车（sidecar) 对立地附加到每个服务上。Sidecar 是指代理在本人的容器中运行但存在于同一个 Pod 中，就像摩托车边车一样，它是一个独自的模块，附着在摩托车上。

服务网格提供了许多有用的性能，包含显示具体指标，加密所有流量，限度服务可受权的操作，为其余工具提供额定插件等等。

更多详细信息，请查看服务网格接口标准：https://smi-spec.io/。

编排和管理层的工具旨在将独立的容器化利用作为一个组进行治理。编排和调度工具能够看作是集群操作系统，用于治理整个集群中的容器化应用程序。协调和服务发现，服务代理和服务网格确保服务能够找到彼此并进行无效通信，彼此合作以成为一个晦涩的应用程序。API 网关是一个附加层，可对服务通信加以更多管制，尤其是对外部应用程序之间的通信。在下一章节中，咱们将探讨利用程序定义和开发层——CNCF 全景图的最初一层。它涵盖数据库、数据流和消息传递、利用程序定义和镜像构建，以及继续集成和交付。

当初咱们来到了云原生全景图的最上层。利用程序定义和开发层，顾名思义，聚焦在帮忙工程师构建应用程序并使其运行的工具上。本文后面的内容都是对于构建牢靠平安的环境以及提供所有必须的应用程序依赖，利用程序定义和开发层则是对于构建软件。

数据库管理系统是一个应用程序，可帮忙其余应用程序高效地存储和检索数据。

数据库能保障数据存储，仅受权的用户能拜访数据，并且容许用户通过专门的申请来检索数据。只管数据库类型繁多，但它们的总体目标都是雷同的。

大多数应用程序都须要无效的形式来存储和检索数据，并且保障数据安全。数据库应用成熟的技术以结构化的形式进行此操作。

数据库提供存储和检索应用程序数据的通用接口。开发人员应用这些标准接口，并用一种简略的查询语言来存储、查问和检索信息。同时，数据库容许用户间断备份和保留数据以及加密和治理数据拜访权限。

咱们曾经理解了数据库管理系统是一种用于存储和检索数据的应用程序。它应用一种通用的语言和界面，并且能够被多种语言和框架轻松应用。

常见的两种数据库类型为：结构化查询语言（SQL）数据库和 NoSQL 数据库。应用程序该应用哪种数据库应该由其需要来驱动。

Kubernetes 反对有状态的应用程序，近年来应用 Kubernetes 的应用越来越宽泛，咱们曾经看到了利用容器化技术的新一代数据库。这些新的云原生数据库旨在将 Kubernetes 的扩展性和可用性劣势引入数据库。YugaByte 和 Couchbase 之类的工具是典型的云原生数据库，Vitess 和 TiKV 是该畛域的 CNCF 我的项目。

留神：查看此类别时会发现以 DB 结尾的多个名称（例如 MongoDB、CockroachDB、FaunaDB），你可能会猜想它们代表数据库。还有以 SQL 结尾的各种名称（例如 MySQL 或 MemSQL）。一些是曾经适应了云原生环境的“老派”数据库，还有一些是兼容 SQL 的 NoSQL 数据库，例如 YugaByte 和 Vitess。

数据流和消息传递工具通过在零碎之间传输音讯（即事件）来实现服务到服务的通信。单个服务连贯到消息传递服务以公布事件和（或）从其余服务读取音讯。这种动态变化发明了一个环境，在这个环境中单个利用要么是发布者，即可编写事件；要么是订阅事件的订阅者，或者更可能是两者兼而有之。

随着服务激增，应用程序环境变得越来越简单，应用程序之间的通信编排也更具挑战性。数据流或音讯平台提供了一个核心地位来公布和读取零碎中产生的所有事件，从而使应用程序能够一起工作，而不用相互了解。

当一个服务执行其余服务应该晓得的事件时，它会将事件“公布”到数据流或消息传递工具。须要理解这些事件类型的服务将订阅并监督数据流或消息传递工具。这就是“公布 - 订阅”的实质。

通过引入治理通信的“中间层”能够使服务彼此解耦。服务只是监督事件、采取行动并公布新事件，这样能建设高度拆散的体系结构。在此体系结构中，服务能够合作而无需彼此理解。这种解耦使工程师可能增加新性能，而无需更新上游应用程序（消费者）或发送大量查问。零碎的解耦水平越高，更改的灵活性和适应性就越高，而这正是工程师在零碎中所谋求的。

数据流和消息传递工具早在云原生技术成为事实之前就曾经存在了。为了集中管理要害业务事件，组织建设了大型的企业级服务总线。然而，当咱们在云原生环境中议论数据流和消息传递时，通常是指 NATS、RabbitMQ、Kafka 或云提供的音讯队列之类的工具。

消息传递和数据流传输零碎为编排零碎进行通信提供了一个核心地位。音讯总线提供了所有应用程序都能够拜访的公共地位，应用程序都能够通过公布音讯来通知其服务它们在做什么，或者通过订阅音讯来查看正在产生的事件。

NATS 和 Cloudevents 我的项目都是这个畛域的孵化我的项目，NATS 提供了一个成熟的消息传递零碎，而 Cloudevents 则致力于标准化零碎之间的音讯格局。Strimzi，Pravega 和 Tremor 是沙盒我的项目，每个我的项目都针对数据流和消息传递的独特用例进行了量身定制。

利用程序定义和镜像构建是一个宽泛的类别，能够分为两个次要的子类别：

聚焦于开发的工具：可帮忙将利用程序代码构建到容器和 Kubernetes 中。
聚焦于运维的工具：以标准化的形式部署利用。

无论是放慢或简化开发环境，提供标准化的形式来部署第三方应用程序，还是简化编写新的 Kubernetes 扩大的过程，此类别的工具都能够优化 Kubernetes 开发和运维人员的体验。

Kubernetes（或者容器化环境）非常灵活且功能强大。这种灵活性也带来了复杂性，次要体现在对于各种新用例有泛滥配置选项。开发人员必须将代码容器化，并在类生产环境中进行开发。在疾速的公布打算周期下，运维人员须要以一种标准化的办法来将应用程序部署到容器环境中。

该畛域的工具旨在解决开发或运维人员面临的一些挑战。对于开发者，有一些工具能够简化扩大 Kubernetes 的过程以构建、部署和连贯应用程序。许多我的项目和产品能够存储或部署预打包的应用程序，使运维人员能够疾速部署 Kafka 之类的流服务或装置 Linkerd 之类的服务网格。

开发云原生应用程序带来了一系列全新的挑战，因而须要大量多样化的工具来简化应用程序的构建和部署。当你须要解决环境中的开发和运维问题时，能够看看此类别中的工具。

利用程序定义和构建工具涵盖了宽泛的性能，比方应用 KubeVirt 将 Kubernetes 扩大到虚拟机，或应用 Telepresence 之类的工具将开发环境移植到 Kubernetes 中来减速利用程序开发等。从整体上讲，该畛域中的工具能够解决开发人员面临的正确编写、打包、测试或运行自定义应用程序的问题，也能够解决运维人员面临的部署和管理应用程序的问题。

Helm 是该类别中惟一一个毕业的我的项目，为许多应用程序部署模式奠定了根底。Helm 容许 Kubernetes 用户部署和自定义一些风行的第三方应用程序，Artifact Hub（CNCF 沙箱我的项目）和 Bitnami 等我的项目已采纳 Helm 来提供精选的应用程序目录。Helm 也足够灵便，容许用户自定义本人的应用程序部署。

Operator Framework 是一个孵化我的项目，旨在简化构建和部署 Operator 的过程。Operator 不在本文探讨范畴之内，但请留神，它相似于 Helm，有助于部署和管理应用程序。Cloud Native Buildpacks 是另一个孵化我的项目，旨在简化将利用程序代码构建到容器中的过程。

继续集成（CI）和继续交付（CD）工具可通过嵌入式质量保证实现疾速高效的开发过程。CI 通过立刻构建和测试代码来自动化代码变更，确保生成可部署的制品。CD 则更进一步，推动该制品进入部署阶段。

成熟的 CI/CD 零碎会监督源代码中的变更，主动构建和测试代码，而后将其从开发阶段转移到生产阶段。在此过程中，CI/CD 零碎必须通过各种测试或验证来决定该过程是持续还是失败。

构建和部署应用程序是一个困难重重且容易出错的过程，特地是当过程中波及很多人为干涉和手动步骤时。如果不将代码集成到代码库中，开发人员在软件上花的工夫越长，辨认谬误所破费的工夫就越长，问题修复也就越艰难。通过定期集成代码，能够及早发现错误并更轻松地排除故障。毕竟，在几行代码中查找谬误比在几百行代码中查找谬误要容易得多。

只管 Kubernetes 之类的工具为运行和管理应用程序提供了极大的灵活性，它们也为 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 的继续交付的新办法。

通常，该畛域的我的项目和产品是：

CI 零碎；
CD 零碎；
帮忙 CD 零碎确定代码是否筹备好投入生产的工具；
前三者的合集（Spinnaker 和 Argo 就是如此）。

Argo 和 Brigade 是该畛域中仅有的 CNCF 我的项目，然而你能够找到由继续交付基金会（Continuous Delivery Foundation）托管的更多我的项目。在此空间中寻找工具，能够帮忙组织自动化生产门路。

利用程序定义和开发层中的工具使工程师可能构建云原生应用程序。该层的工具包含：

数据库：存储和检索数据。
数据流和消息传递工具：实现互相拆散、精心设计的架构。
利用程序定义和镜像构建工具：蕴含可改善开发人员和操作员体验的多种技术。
CI/CD 工具：确保代码处于可部署状态，并帮忙工程师及早发现错误，从而确保代码品质。

在下面的内容中，咱们探讨了 CNCF 云原生全景图的各层：供给层、运行时层、编排管理层以及利用定义和开发层。本章节咱们将聚焦在平台层。

正如咱们在本文中看到的那样，每个类别都解决了特定的问题。仅仅存储并不能提供管理应用程序所需的全副性能，你还须要编排治理、容器运行时、服务发现、网络、API 网关等工具。平台将来自不同层的工具捆绑在一起，以解决更大的问题。

平台里其实没有新的工具。你当然能够构建本人的平台，事实上，许多组织都这样做。然而，牢靠、平安地配置和微调不同的模块，同时确保始终更新所有技术并修补破绽，这不是一件容易的事。你须要一支专门的团队来构建和保护它。如果没有所需的专业知识，那么应用平台可能会更好。对于某些组织，尤其是工程团队规模较小的组织，平台是采纳云原生技术的惟一办法。

你可能曾经留神到了，所有的平台都是围绕 Kubernetes 来演变的，因为 Kubernetes 是云原生技术栈的外围。

发行版是指供应商以 Kubernetes 为外围（采纳未经批改的开源代码，只管有些人对其进行了批改），并将其打包以进行从新发行。通常这个过程须要查找和验证 Kubernetes 软件，并提供集群装置和降级的机制。许多 Kubernetes 发行版都蕴含其余闭源或开源的应用程序。

开源 Kubernetes 并未指定特定的装置工具，而是将许多设置配置选项提供给用户。此外，无限的社区资源（包含社区论坛、StackOverflow、Slack 或 Discord 等）曾经不能解决所有的问题。

随着 Kubernetes 的遍及，Kubernetes 的应用变得越来越容易，然而查找和应用开源安装程序可能会面临挑战。用户须要理解应用哪个版本，在何处获取，以及特定组件是否能兼容。此外，还须要决定集群上部署什么软件，要应用哪些设置来确保平台的安全性、稳定性和高性能。所有这些都须要丰盛的 Kubernetes 专业知识，而这些常识可能并不容易取得。

Kubernetes 发行版提供了一种装置 Kubernetes 的牢靠形式，并提供了正当的默认值以创立更好、更平安的操作环境。

Kubernetes 发行版为供应商和我的项目提供了所需的掌控度和可预测性，以帮忙他们反对客户部署、保护和降级 Kubernetes 集群。

这种可预测性使发行版提供商在客户遇到生产问题时可为其提供反对。发行版经常提供通过测试和受反对的降级门路，使用户的 Kubernetes 集群放弃最新的版本。此外，发行版通常提供可在 Kubernetes 上部署的软件，从而使其更易于应用。

如果你曾经装置了 Kubernetes，那你可能曾经应用了 kubeadm 之类的工具来启动和运行集群。即便如此，你可能还须要 CNI（容器网络接口）来装置和配置它。而后，你可能曾经增加了一些存储类，一个解决日志音讯的工具，可能还须要个 ingress controller，以及更多其余的工具。Kubernetes 发行版将主动执行局部或全副设置。它还将依据本人对最佳实际或智能默认值的了解提供配置设置。此外，大多数发行版都将捆绑一些通过测试的扩大或附件，以确保用户能够尽快应用新集群。

咱们以 Kublr 为例。它以 Kubernetes 为外围，次要捆绑了来自供给层、运行时层、编排管理层的工具。所有模块都事后配置了一些选项并且开箱即用。不同的平台聚焦不同的性能。就 Kublr 而言，重点是在运维方面，而其余平台则可能聚焦在开发工具上。

此类别中有很多工具选项。如下图所示，企业能够抉择和供应商达成技术单干，比方国外的 Canonical、VMware、Mirantis、SUSE，国内的网易、火山引擎和京东，它们都能够提供杰出的开源和商业工具，倡议在评估发行版时认真思考本人的需要。

托管 Kubernetes 是由 Amazon Web Services（AWS）、DigitalOcean、Azure 或 Google 等基础设施提供商（云厂商）提供的服务，容许客户按需启动 Kubernetes 集群。云厂商负责管理 Kubernetes 集群的一部分，通常称为管制立体。托管 Kubernetes 服务与发行版类似，但由云厂商在其基础架构上进行治理。

托管 Kubernetes 使团队只需在云厂商开设一个账户即可开始应用 Kubernetes。它解决了 Kubernetes 入门五个过程中的“五 W”问题：

Who：云厂商
What：他们托管的 Kubernetes 产品
When：当初
Where：云厂商的基础架构上
Why：由你决定

因为 Kuberentes 托管服务提供商负责管理所有细节，因而托管的 Kubernetes 服务是开始云原生之路的最简略办法。用户所须要做的就是开发本人的应用程序并将其部署在托管的 Kubernetes 服务上，这十分不便。托管产品容许用户启动 Kubernetes 集群并立刻开始 *，同时对集群可用性承当一些责任。值得注意的是，这些服务的额定便利性会造成灵活性的升高：托管的 Kubernetes 服务和云厂商绑定，且用户无法访问 Kubernetes 管制立体，因而某些配置选项会受到限制。

注：AWS 的 EKS 略有例外，因为它还要求用户采取一些其余步骤来筹备集群。

托管 Kubernetes 是由供应商（通常是基础架构托管提供商）提供的按需应用的 Kubernetes 集群，供应商负责配置群集和治理 Kubernetes 管制立体。再次阐明，值得注意的例外是 EKS，其上的单个节点配置由客户端决定。

托管 Kubernetes 服务使组织能够将基础架构组件治理外包进来，这样能够疾速配置新集群并升高经营危险。次要的衡量取舍在于可能须要为管制立体治理付费，并且用户的管理权限无限。与本人搭建 Kubernetes 群集相比，托管服务在配置 Kubernetes 群集方面有更严格的限度。

在这个畛域中有许多供应商和我的项目，在撰写本文时，尚无 CNCF 我的项目。

Kubernetes 安装程序可帮忙你在机器上装置 Kubernetes，它们可自动化 Kubernetes 的装置和配置过程，甚至能够帮忙降级。Kubernetes 安装程序通常与 Kubernetes 发行版或托管 Kubernetes 产品联合应用或由它们应用。

与 Kubernetes 发行版类似，Kubernetes 安装程序可简化 Kubernetes 的上手过程。开源的 Kubernetes 依赖于 kubeadm 之类的安装程序。截至本文撰写之时，kubeadm 可用于启动和运行 Kubernetes 集群，是 CKA（Kubernetes 管理员认证）测试的一部分。

Kubernetes 安装程序简化了 Kubernetes 的装置过程。像发行版一样，它们为源代码和版本提供通过审核的源。它们还常常自带 Kubernetes 环境配置。像 kind（Docker 中的 Kubernetes）这样的 Kubernetes 安装程序容许通过单个命令取得 Kubernetes 集群。

无论是在 Docker 上本地装置 Kubernetes，启动和配置新的虚拟机，还是筹备新的物理服务器，都须要一个工具来解决各种 Kubernetes 组件的筹备工作。

Kubernetes 安装程序可简化该过程。有些解决节点启动，还有一些仅配置已供给的节点。它们都提供不同水平的自动化，并且适宜不同的用例。开始应用 Kubernetes 安装程序时，应先理解本人的需要，而后抉择能够满足这些需要的安装程序。在撰写本文时，kubeadm 是 Kubernetes 生态系统中至关重要的工具，已蕴含在 CKA 测试中。Minikube、kind、kops 和 kubespray 都是 CNCF 中的 Kubernetes 安装程序我的项目。

PaaS（平台即服务）是一种环境，容许用户运行应用程序而不用理解底层计算资源。此类别中的 PaaS 和容器服务是一种机制，可为开发人员托管 PaaS 或托管他们能够应用的服务。

在本篇文章中，咱们探讨了无关“云原生”的工具和技术。PaaS 连贯了此畛域中的许多技术，可为开发人员提供间接价值。它答复了以下问题：

我如何在各种环境中运行应用程序？
一旦利用程序运行起来，我的团队和用户将如何与它们交互？

PaaS 为组合运行应用程序所需的开源和闭源工具提供了抉择。许多 PaaS 产品蕴含解决 PaaS 装置和降级的工具，以及将利用程序代码转换为正在运行的应用程序的机制。此外，PaaS 能够解决应用程序实例的运行时需要，包含按需扩大单个组件以及可视化单个应用程序的性能和日志音讯。

组织正在采纳云原生技术来实现特定的业务或指标。与构建自定义应用程序平台相比，PaaS 可疾速让组织实现价值。Heroku 或 Cloud Foundry Application Runtime 之类的工具可帮忙组织疾速启动并运行新的应用程序，它们可提供运行云原生应用程序所需的工具。任何 PaaS 都有本身的限度。大多数只反对一种语言或一部分应用程序类型，其自带的一些工具选项可能并不适宜你的需要。无状态应用程序通常在 PaaS 中表现出色，而数据库等有状态应用程序通常不太适宜 PaaS。目前在这个畛域没有 CNCF 我的项目，然而大多数产品都是开源的。

如文中所介绍，有多种工具可帮忙简化 Kubernetes 的采纳。Kubernetes 发行版、托管 Kubernetes 服务、Kubernetes 安装程序以及 PaaS 都承当了一些装置和配置的工作，可进行预打包。每个解决方案都有其本人的特点。

在采纳上述任何一种办法之前，须要进行一些钻研，以确定适宜本人需要的最佳解决方案。你可能须要思考：

我会遇到一些须要掌控管制立体的场景吗？如果有，托管解决方案可能不是一个很好的抉择。
我有没有一个小型团队来治理“规范”工作负载，并须要分流尽可能多的操作工作？如果有，托管解决方案可能十分适合你。
便携性对我来说重要吗？
生产就绪状况如何？

还有更多问题须要思考。没有一个“最佳工具”，然而对于你的特定需要，必定能够抉择一个无效工具。心愿本文能帮忙你将搜寻范畴放大到正确的区域。

终于咱们来到了云原生全景图详解的最初一章节。本章节将向大家介绍云原生全景图中的可察看性和剖析这一“列”。

首先咱们定义一下可察看性和剖析（Observability & analysis)。可察看性是一种零碎个性，形容了通过内部输入能够了解零碎的水平。通过掂量 CPU 工夫、内存、磁盘空间、提早、error 等指标，能够或多或少地察看到计算机系统的状态。剖析则是尝试了解这些可用于察看的数据。

为了确保服务不会中断，咱们须要察看和剖析应用程序的各个方面，以便立刻发现并修复异常情况。这就是可察看性和剖析这个类别要做的事件。它贯通并察看所有层，因而在整个全景图的侧面而不是嵌在某一层。

此类别中的工具包含日志记录 (logging)、监控 (monitoring)、追踪（tracing) 和混沌工程（chaos engineering)。尽管混沌工程在这里列出，但它更多的是一种可靠性工具，而不是可察看性或剖析工具。

应用程序会输入稳固的日志音讯流，以形容本身在何时做了什么。这些日志音讯会捕捉零碎中产生的各种事件，例如失败或胜利的操作、审计信息或运行状况。日志记录工具将收集、存储和剖析这些音讯，以追溯错误报告和相干数据。日志记录（loging）、度量（metrics)、追踪（tracing) 是可察看性的三大支柱。

收集、存储和剖析日志是构建古代平台的要害局部，日志记录可帮忙执行这其中的某一项或全副工作。一些工具可解决从收集到剖析全方位的工作，还有一些工具则专一于单个工作（例如收集）。所有日志记录工具都旨在帮忙组织更好地管制日志音讯。

在收集、存储和剖析应用程序的日志音讯时，咱们将理解应用程序在任何给定工夫的通信内容。但请留神，日志代表应用程序无意输入的音讯，它们不肯定能查明给定问题的根本原因。尽管如此，随时收集和保留日志音讯是一项十分弱小的性能，它将帮忙团队诊断问题并满足合规性要求。

只管收集、存储和解决日志音讯不是什么新鲜事，但云原生模式和 Kubernetes 的呈现极大地扭转了咱们解决日志的形式。实用于虚拟机和物理机的传统日志记录办法（例如将日志写入文件）不适用于容器化的应用程序，因为在这些容器化应用程序中，文件系统的生命周期可能并不会比应用程序长久。在云原生环境中，诸如 Fluentd 之类的日志收集工具与应用程序容器一起运行，并间接从应用程序收集音讯，而后将音讯转发到地方日志存储以进行汇总和剖析。

CNCF 中的日志记录工具只有 Fluentd。

监控是指对应用程序进行检测，收集、聚合和剖析日志和指标，以增进咱们对应用程序行为的了解。日志形容了特定的事件，而指标则是在给定工夫点对系统的度量。日志和 metrics 是两种不同的事物，然而要全面理解零碎的运行状况，二者都是必须的。监控的内容包含察看磁盘空间、CPU 使用率、单个节点上的内存耗费，以及执行具体的综合事务以查看零碎或应用程序是否正确且及时地进行了响应等。有许多不同的办法可用来监控零碎和应用程序。

在运行应用程序或平台时，咱们心愿它实现既定的工作，并确保只有被受权的用户能力拜访。通过监控，咱们能够晓得应用程序 / 平台是否在失常、平安且高效地运行，是否仅有被受权的用户能够拜访。

良好的监控办法使运维人员可能在产生事变时迅速做出响应，甚至能够主动响应。监控能够让咱们洞察零碎以后运行的情况，监测到问题进行修复。它能跟踪应用程序运行状况、用户行为等内容，是无效运行应用程序的重要组成部分。

云原生环境中的监控和传统应用程序的监控相似。咱们须要跟踪指标、日志和事件以理解应用程序的运行状况。次要区别在于云原生环境中的某些托管对象是长期的，它们可能不会长久，因而将监控零碎与主动生成的资源名称分割在一起并不是一个好策略。CNCF 中有许多监控工具，最次要的是 Prometheus（曾经从 CNCF 毕业）。

在微服务架构中，服务之间一直通过网络互相通信。追踪是日志记录的一种专门用法，能够跟踪申请在分布式系统中挪动的门路。

理解微服务应用程序在某个工夫点的行为是一项极具挑战的工作。只管有许多工具能够提供服务行为相干的洞察，但咱们可能难以通过单个服务的行为来了解整个应用程序的运行状况。

追踪对应用程序发送的音讯增加惟一标识符，可解决上述问题。该惟一标识符能够追随 / 追踪各个事务在零碎中挪动的门路，能够通过追踪的信息理解应用程序的运行状况，以及调试有问题的微服务或行为。

追踪是一种功能强大的调试工具，能够对分布式应用程序的行为进行故障排除和 fine-tune。要实现追踪也须要一些老本，比方须要批改利用程序代码以收回跟踪数据，并且所有 Span 都须要由应用程序数据门路中的基础架构组件流传。CNCF 中的追踪工具有 Jaeger 和 Open Tracing。

混沌工程（chaos engineering）是指无意将故障引入零碎以创立更具弹性的应用程序和工程团队的实际。凌乱工程工具以一种可控的形式在零碎中引入故障，并针对应用程序的特定实例运行特定的试验。

简单的零碎会呈现故障。故障的起因有多种，给分布式系统带来的结果也很难预测。一些组织曾经承受了这一点，他们违心采纳混沌工程技术，不去试图避免故障的产生，而是设法练习从故障中复原。这被称为优化均匀修复工夫（MTTR）。

在云原生环境中，应用程序必须动静适应故障——这是一个绝对较新的概念。这意味着当呈现故障时，零碎不会齐全解体，而是能够优雅地降级或复原。混沌工程工具能够在生产环境的零碎上进行试验，以确保在产生真正的故障时零碎也能应答。

简言之，对一个零碎进行混沌工程试验，是为了确保该零碎能够接受意外状况。应用混沌工程工具，不用期待故障产生后再进行应答，而是能够在可控条件下为零碎注入故障，以发现破绽并在变更笼罩这些破绽之前加以修复。

混沌工程工具和实际对于应用程序的高可用至关重要。分布式系统通常过于简单，而且任何变更过程都无奈齐全确定其对环境的影响。通过无意引入混沌工程实际，团队能够练习从故障中复原，并将这个过程自动化。CNCF 中的混沌工程工具有 Chaos Mesh 和 Litmus Chaos。还有一些其余的开源和闭源的混沌工程工具。

可察看性和剖析这一列的工具可用于理解零碎的运行状况，并确保零碎即便在顽劣的条件下也能失常运行。日志记录工具可捕捉应用程序收回的事件音讯，监控工具可监测日志和指标，追踪工具可跟踪单个申请的门路。联合应用这些工具，现实状况下能够 360 度全方位查看零碎中正在产生的事件。混沌工程提供了一种平安的办法来保证系统能够接受意外事件，基本上能够确保零碎的衰弱运行。

文章起源：K8sMeetup 社区，点击查看原文。

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云治理以及快数据治理等平台级能力。点击下方链接即可参加开源 ，和泛滥开发者一起探讨、交换，共建开源社区。 欢送大家关注、奉献代码和 Star！

Erda Github 地址：https://github.com/erda-project/erda
Erda Cloud 官网：https://www.erda.cloud/

带你理解云原生技术图谱

1. 云原生全景图的 4 层

1）供给层（Provisioning）

2）运行时层（Runtime）

3）编排和管理层（Orchestration and Management）

4）利用定义和开发层（Application Definition and Developement)

2. 贯通所有层的工具

1）可察看性和剖析（Observability and Analysis）

2）平台类（Platform）

3. 小结

供给层

1. 自动化和配置

1）是什么

2）解决的问题

3）如何解决问题

4）对应工具

2. Container Registry

1）是什么

2）解决的问题

3）如何解决

4）对应工具

3. 平安和合规

1）是什么

2）解决什么问题

3）如何解决

4）对应工具

4. 密钥和身份治理

1）是什么

2）解决的问题

3）如何解决

4）对应的工具

运行时层

1. 云原生存储

1）是什么

2）解决的问题

3）如何解决

4）对应工具

2. 容器运行时

1）是什么

2）解决的问题

3）如何解决

4）对应的工具

3. 云原生网络

1）是什么

2）解决什么问题

3）如何解决

4）对应工具

编排和管理层

1. 编排和调度

1）是什么

2）解决的问题

3）如何解决

4）对应工具

2. 协调和服务发现

1）是什么

2）解决的问题

3）如何解决

4）对应工具

3. 近程过程调用

1）是什么

2）解决的问题

3）如何解决

4）对应工具

4. 服务代理

1）是什么

2）解决的问题

3）如何解决

4）对应工具

5. API 网关

1）是什么

2）解决的问题

3）如何解决

4）对应工具

6. 服务网格

1）是什么

2）解决什么问题

3）如何解决

4）对应工具

7. 小结

利用程序定义和开发层