云原生技术概览

定义

云原生是一条最佳路径或者最佳实践。云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

因此，云原生其实是一套指导进行软件架构设计的思想。按照这样的思想而设计出来的软件：

首先，天然就“生在云上，长在云上”
其次，能够最大化地发挥云的能力，使得我们开发的软件和“云”能够天然地集成在一起，发挥出“云”的最大价值

所以，云原生的最大价值和愿景，就是认为未来的软件，会从诞生起就生长在云上，并且遵循一种新的软件开发、发布和运维模式，从而使得软件能够最大化地发挥云的能力。

技术范畴

云原生的技术范畴包括了以下几个方面：

第一部分：云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
第二部分：云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分，包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。
第三部分：监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。
第四部分：云原生的底层技术。比如容器运行时、云原生存储技术、云原生网络技术等。
第五部分：云原生工具集。在前面的这些核心技术点之上，还有很多配套的生态或者周边的工具需要使用，比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
第六部分：Serverless。这是一种 PaaS 的特殊形态，它定义了一种更为“极端抽象”的应用编写方式，包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按实际使用计费（Pay as you go），因此 Serverless 计费也是重要的知识和概念。

云原生思想的两个理论

云原生的技术范畴所包含的技术内容很多，但是这些内容的技术本质却是类似的。云原生技术的本质是两个理论基础。

第一个：不可变基础设施。这一点目前是通过容器镜像来实现的，其含义就是应用的基础设施应该是不可变的，是一个自包含、自描述可以完全在不同环境中迁移的东西
第二个：云应用编排理论。当前的实现方式就是 Google 所提出来的“容器设计模式”，这也是 Kubernetes 部分的内容

基础设施向云演进的意义

基础设施向“不可变”演进的过程，为我们提供了两个非常重要的优点。

基础设施的一致性和可靠性。同样一个镜像，其中的 OS 环境对于应用而言都是一致的。而对于应用而言，它不需要关心容器跑在哪里，这就是基础设施一致性非常重要的一个特征。
这样的镜像本身就是自包含的，其包含了应用运行所需要的所有依赖，因此也可以漂移到云上的任何一个位置。

此外，云原生的基础设施还提供了简单、可预测的部署和运维能力。由于现在有了镜像，应用还是自描述的，通过镜像运行起来的整个容器其实可以像 Kubernetes 的 Operator 技术一样将其做成自运维的，所以整个应用本身都是自包含的行为，使得其能够迁移到云上任何一个位置。这也使得整个流程的自动化变得非常容易。

应用本身也可以更好地扩容，从 1 个实例变成 100 个实例，进而变成 1 万个实例，这个过程对于容器化后的应用没有任何特殊的。最后，也能够通过不可变的基础设施来地快速部署周围的管控系统和支撑组件。因为，这些组件本身也是容器化的，是符合不可变基础设施这样一套理论的组件。

以上就是不可变基础设施为用户带来的最大的优点。

云原生技术的关键点

云原生关键技术点或者说所依赖的技术理论主要有这样的四个方向：

如何构建自包含、可定制的应用镜像；
能不能实现应用快速部署与隔离能力；
应用基础设施创建和销毁的自动化管理；
可复制的管控系统和支撑组件。

这四个云原生关键技术点是落地实现云原生技术的四个主要途径。

技术概览

最全概览肯定是CNCF官方的LandScape啦。

这张图会不断更新的，一定要去官网上看，总共分为四个层次，从下往上依次是：

Provisioning(配置云原生基础架构的工具)
Runtime(运行时工具)
Orchestration & Management（管理应用程序所需的工具）
Application Definition & Development(定义和开发应用程序的工具)

蓝色外框底部有CNCF标签的是托管在云原生基金会的项目，并注明了毕业项目还是孵化项目。

白底的是开源项目，灰底的是专有项目。

抽象一下就是这样子，在最右侧还有两列横跨这四层：

可观察性与分析（Observability &Analysis）
平台类（Platforms）

在每一层的每个领域中都有旨在解决相同或相似问题的不同工具。区别在于它们的实现和设计方法。
在选择时，必须仔细考虑每种功能并进行权衡，以确定适合其用例的最佳选择。尽管这带来了额外的复杂性，但选择最适合应用程序需求的数据存储，基础架构管理，消息系统等，都是至关重要的。

供应层（Privisioning）

创建和强化云本机应用程序基础所涉及的工具。它涵盖了：

自动化基础结构的创建
管理和配置镜像扫描
镜像签名和存储镜像
在应用程序和平台中构建身份验证授权以及处理密钥分发的工具
资源调配和安全领域的工具

划分为四个子领域：

自动化和配置工具（Automation & configuration ）：可帮助工程师无需人工干预即可构建基础环境。
容器仓库（Container Registry）: 存储应用程序的镜像。
安全与合规（Security & compliance）：涉及不同的安全领域。
密钥管理（Key management）：有助于加密，以确保只有授权的用户才能访问该应用程序。

自动化和配置工具（Automation & configuration ）

加快计算资源（虚拟机，网络，防火墙规则，负载均衡器等）的创建和配置。

解决了，传统上，IT流程依赖冗长且复杂的手动发布周期，甚至需要三到六个月。这些周期伴随着许多人工流程和控制，从而减缓了生产环境的变更。这些缓慢的发布周期和静态环境与云原生开发不兼容。为了实现快速的开发周期，必须动态配置基础架构，并且无需人工干预。

此类工具使工程师无需人工干预即可构建计算环境。环境设置，只需单击一个按钮，它就可以实现。手动设置很容易出错，但是一旦进行了编码，环境创建就会与所需的确切状态相匹配，这是巨大的优势。

尽管这些工具可能采用不同的方法，但它们都旨在通过自动化配置资源减少所需的手工操作。

容器仓库（Container Registry）

容器是用于执行软件流程的一组计算约束。容器使你无论身在何处都可以以受控方式运行代码。
镜像是运行容器及其过程所需的一组存档文件。可将其视为模板的一种形式，可以在其上创建无限数量的容器。
存储库是用于分类和存储镜像的专用Web应用程序。

解决了，云原生应用程序打包并作为容器运行。镜像仓库存储并提供这些容器镜像。

安全与合规（Security & compliance）

云原生应用程序旨在快速迭代，为了定期发布代码，必须确保代码和操作环境是安全的，并且只能由授权的工程师访问。

为了安全地运行容器，必须对容器进行扫描以查找已知漏洞并签名，以确保它们未被篡改。Kubernetes本身默认的访问控制设置比较宽松。因此，对于希望攻击系统的任何人来说，Kubernetes集群都是一个有吸引力的目标。该空间中的工具和项目有助于增强群集，并提供工具来检测系统何时出现异常。

解决了，加强、监视和实施平台和应用程序的安全性。从容器到Kubernetes环境，它们使你能够设置策略（用于合规性），深入了解现有漏洞，捕获错误配置以及增强容器和集群的安全性。

具体的安全性工具分类：

审计与合规(Audit and compliance)
生产环境中强化的途径
- 代码扫描
- 漏洞扫描
- 镜像签名
政策制定与执行
网络层安全

密钥管理（Key management）

密钥是用于加密或签名数据的字符串，它加密数据，以便只拥有正确密钥的才能解密数据。

随着应用程序适应新的云原生世界，安全工具也在不断发展以满足新的安全需求。此类别中的工具和项目涵盖了从如何安全地存储密码和其他机密信息（敏感数据，例如API密钥，密钥等）到如何从微服务环境中安全删除密码和机密信息等。

解决了，云原生环境高度动态，按需完全编程（无人参与）和自动化的密钥分发。应用程序还必须知道给定的请求是否来自有效来源（身份验证），以及该请求是否有权执行其尝试执行的任何操作。通常将其称为AuthN和AuthZ。

此类别中的工具可以分为两组：

专注于密钥生成，存储，管理和轮换（Vault是一种相当通用的密钥管理工具）
专注于单点登录和身份管理（Keycloak是一种身份代理，可用于管理不同服务的访问密钥）

运行时层（Runtime）

从狭义上讲，运行时是运行应用程序的特定沙箱环境（应用程序运行所需的最低限度）
从广义上讲，运行时是应用程序运行所需要的任何工具

在CNCF云原生环境中，运行时重点放在对容器化应用特别重要的组件上，划分为三个子领域：

云原生存储（Cloud native storage）：为容器化的应用程序提供了虚拟化磁盘或持久性。
容器运行时（Container runtime）：为容器提供了约束，资源和安全性等。
云原生网络（Cloud native networking）：分布式系统的节点通过其进行连接和通信的网络。

注意：运行时层的资源不应与与基础结构和供应层的网络和存储混淆。容器会直接使用运行时层的工具来启动/停止，存储数据以及通信。

云原生存储

存储，即存放应用程序持久数据的位置，通常称为持久卷。轻松访问持久卷，对于应用程序可靠运行至关重要。通常，当我们说持久数据时，是指想要确保在应用重新启动时不会消失的任何数据。

云原生架构具有不固定性，灵活性和弹性，这使得应用重启后的持久数据面临挑战。容器化的应用程序在扩缩容或自我修复时，将会连续创建和删除实例，并随时间更改物理位置。因此，必须以与节点无关的方式提供云原生存储。

第一个挑战：要存储数据，就要需要硬件（磁盘）。磁盘与其他任何硬件一样，都受基础结构约束。
第二个挑战：存储接口。以前，每个基础架构都有自己的存储解决方案和自己的接口，这使可移植性变得非常困难。
第三个挑战：由于云的弹性，必须以自动化方式配置存储。

云原生存储，是针对此云原生量身定制。云原生存储工具，提供如下功能：

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

因此，使用云原生存储能够兼容多数三方存储，并且可以自动配置，从而消除了人为瓶颈，实现了自动扩展和自我修复。

相应的解决工具

容器存储接口（CSI）在很大程度上使云原生存储成为可能，该接口允许使用标准API向容器提供文件和块存储。在这个领域中，有许多工具，包括开源的和供应商提供的，都可以利用CSI为容器提供按需存储。

除了这一极其重要的功能之外，我们还有许多其他工具和技术，旨在解决云原生中的存储问题。

Minio是一个受欢迎的项目，除其他外，它提供了兼容S3的API用于对象存储。
Velero之类的工具可帮助简化Kubernetes集群本身以及应用程序使用的持久数据的备份和还原过程。

容器运行时

容器运行时，是执行集装箱化（或“约束”）的应用程序。如果没有运行时，则只有容器镜像，该文件指定了容器化应用的外观。运行时将在容器中启动应用程序，并为其提供所需的资源。

容器运行时解决了容器镜像（带有应用程序规范的文件）必须以标准化，安全和隔离的方式启动的问题。

标准化：无论在何处运行，都需要标准的操作规则。
安全：不希望任何不应该访问它的人，对它操作。
隔离：不希望应用程序影响其他应用，或受其他应用程序的影响（例如，在同一节点的其他应用程序崩溃）。隔离基本上起保护作用。此外，必须为应用程序提供从CPU到存储再到内存的资源隔离。

容器运行时可以完成所有这些工作。

它以标准化方式在所有环境中启动应用程序，并设置安全边界。像CRI-O或gVisor这样的运行时，强化了它们的安全性边界。运行时还设置了容器的资源限制。没有它，该应用程序可能会根据需要消耗资源，从而有可能占用其他应用程序的资源，因此你始终需要设置限制。

相应的解决工具

并非此类别中的所有工具都是一样的。Containerd （Docker产品的一部分）和CRI-O是标准的容器运行时实现。

然后，有一些工具可以将容器的使用扩展到其他技术，例如Kata，它允许你将容器作为VM运行。其他目标旨在解决与容器相关的特定问题，例如gVisor，它在容器和OS之间提供了额外的安全层。

云原生网络

容器通过云原生网络相互通信，并与基础结构层通信。分布式应用程序具有多个组件，这些组件将网络用于不同目的。云原生网络类别中的工具将虚拟网络覆盖在现有网络之上，专门用于应用程序进行通信，称为覆盖网络( overlay network )。

通常，将在容器中运行的代码称为应用程序，但事实是，大多数容器仅包含较大应用程序的一小部分特定功能。诸如Netflix或Gmail之类的现代应用程序实际上由许多这些较小的组件组成，每个组件都在其自己的容器中运行。为了使所有这些独立的部分充当一个有凝聚力的应用程序，容器需要彼此私下通信。此类工具提供该专用通信网络。

此外，在这些容器之间交换的消息可能是私有的，敏感的或非常重要的。这导致了其他要求，例如为各种组件提供隔离以及检查流量以识别网络问题的能力。在某些用例中，可能需要扩展这些网络和网络策略（例如防火墙和访问规则），以便应用程序可以连接到在容器网络外部运行的虚拟机或服务。

容器网络接口（CNI）为容器化应用程序提供联网功能。某些工具（例如Flannel）相当简单，可提供与容器的基本连接。其他诸如NSX-T等提供了完整的软件定义网络层，可为每个Kubernetes命名空间创建一个隔离的虚拟网络。

容器网络至少需要为Pod（在Kubernetes中运行容器化的应用程序）分配IP地址，以允许其他进程访问它。

相应的解决工具

与存储类似，CNI（容器网络接口）在很大程度上实现了该领域的多样性和创新，该项目标准化了网络层如何为Pod提供功能。

为Kubernetes环境选择正确的容器网络至关重要，并且有许多工具可供选择。Weave Net，Antrea，Calico和Flannel均提供有效的开源网络层。它们的功能千差万别，选择应最终由特定需求决定。

此外，许多供应商已准备好使用软件定义网络（ Software Defined Networking ，SDN）工具来支持和扩展Kubernetes网络，这些工具使你可以深入了解网络流量，执行网络策略，甚至将容器网络和策略扩展到更广泛的数据中心。

编排和管理层（Orchestration & Management）

按照安全性标准自动搭建了基础结构（供应层），并设置了应用程序需要运行的工具（运行时层），就需要知道如何编排和管理其应用程序。

编排和管理层，把所有容器化应用程序作为一个组进行管理。还要确定是否需要和其他服务相互通信并进行协调。同时，云原生应用程序具有良好的可扩展性。

划分为六个子领域:

编排和调度（Orchestration & scheduling）：部署和管理容器集群，以确保它们具有弹性，松耦合和可伸缩性。具有代表性的容器编排工具就是Kubernetes。
服务发现（Coordination and service discovery）：服务可以相互通信的工具。
远程过程调用（RPC）：跨节点上的服务进行通信的技术。
服务代理（Service proxy）：代理的唯一目的是对服务通信施加更多控制，它不会对通信本身添加任何内容。这些代理对于下面提到的服务网格至关重要。
API网关：一个抽象层，外部应用程序可以通过它进行通信。
服务网格（Service mesh）：在某种程度上类似于API网关，它是应用程序通过其进行通信的专用基础结构层，但是它提供了策略驱动的服务的通信。此外，它可能包括从加密、服务发现、到应用程序可观察性的所有内容。