更新最后一章

isno · Jan 1, 2025 · a9a2cc8 · a9a2cc8
1 parent 1a051e7
commit a9a2cc8
Show file tree

Hide file tree

Showing 3 changed files with 13 additions and 15 deletions.
diff --git a/application-centric/Helm.md b/application-centric/Helm.md
@@ -1,8 +1,10 @@
-# 10.3.2 Helm 
+# 10.3.2 Helm
+
+如果说 Kubernetes 是云原生时代的操作系统，那 Helm 就是这个操作系统之上的应用商店和包管理工具。
 
 相信读者朋友们知道 Linux 下的包管理工具和封装格式， 如 Debian 系的 apt-get 命令和 dpkg 格式、RHEL 系的 yum 命令和 rpm 格式。在 Linux 系统中，有了包管理工具，我们只要知道应用的名称，就可以很方便地从应用仓库中下载、安装、升级、回滚等，而且包管理工具掌握着应用的依赖信息和版本变更情况，具备完整的自管理能力，每个应用依赖哪些前置的第三方库，在安装时都会一并处理好。
 
-**如果说 Kubernetes 是云原生时代的操作系统，那 Helm 就是这个操作系统之上的应用商店和包管理工具**。Helm 参考了各大 Linux 发行版管理应用的思路，提出了与 Linux 包管理直接对应的 Chart 格式 和 Repoistory 应用仓库的概念。对于使用者而言，使用 Helm 后，不用需要了解 Kubernetes 的 yaml 语法，也不需要编写应用部署文件。只要一行命令，就可以下载并在 kubernetes 上安装需要的应用。
+Helm 借鉴了各大 Linux 发行版的应用管理方式，引入了与 Linux 包管理对应的 Chart 格式和 Repository 仓库概念。对于用户而言，使用 Helm 无需了解 Kubernetes 的 YAML 语法或编写部署文件，只需一行命令，即可在 Kubernetes 集群内下载、安装所需应用。
 
 
 Chart 是一个包含描述 Kubernetes 相关资源的文件集合，例如 WordPress chart 的目录结构是这样子的：
@@ -25,7 +27,8 @@ WordPress
 └── values.yaml
 ```
 
-其中 Chart.yamlChart 的元数据文件，包含了 Chart 的名称、版本、描述等信息。values.yaml 默认的配置文件，定义了 Chart 中变量的默认值。用户可以通过自定义 values.yaml 或通过命令行参数覆盖这些默认值。templates 目录包含 Kubernetes YAML 配置文件的模板，这些模板通过 Go 的模板引擎进行渲染，生成最终的 Kubernetes 资源定义文件。
+其中 Chart.yaml 是元数据文件，包含了 Chart 的名称、版本、描述等信息。values.yaml 是默认的配置文件，定义了 Chart 中变量的默认值。用户可以通过自定义 values.yaml 或通过命令行参数覆盖这些默认值。templates 目录包含 Kubernetes YAML 配置文件的模板，这些模板通过 Go 的模板引擎进行渲染，生成最终的 Kubernetes 资源定义文件。
+
 
 
 如下图所示，开发者和运维人员将复杂的应用程序及其依赖项打包成一个 Chart。用户使用 helm install 命令快速部署应用，无需再手动编写大量的 YAML 配置文件。
@@ -43,6 +46,8 @@ Artifact Hub 是最大的公共 Helm 仓库之一，大量开源项目提供了
 
 
 
+
+
 如果说 Docker 是奠定的单实例的标准化交付，那么 Helm 则是集群化多实例、多资源的标准化交付。Helm 将复杂的应用部署简化为几个简单的命令。
 
 Helm 仓库是存储 Helm chart（应用程序的定义和配置包）的地方。默认情况下，Helm 配置了一个稳定的仓库（https://charts.helm.sh/stable），但你也可以添加其他仓库。

diff --git a/application-centric/OAM.md b/application-centric/OAM.md
@@ -1,4 +1,5 @@
 # 10.3.4 OAM
+无论是 Kustomize Helm 或者是 Operator ，它们在各自领域承载的是一个“组件”的概念，对于一个完整的“应用”，即面向具体业务场景的定义、部署和运行需求，仍旧缺乏思想指导和有效的解决手段。
 
 2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了开源项目 Open Application Model（OAM）。该项目以“关注点分离”（Separation of Concerns）为核心理念，对云原生应用的整个 DevOps 流程提供了高度抽象和封装。
 
@@ -8,7 +9,7 @@ OAM 项目有两个部分，OAM 规范（spec）和 OAM 规范的 Kubernetes 实
 
 - 应用组件（Component）：具有独立功能、可重用和可替换的模块。无论是前端，还是后端使用组件组成应用的思想屡见不鲜。
 - 运维特征（Trait）：可随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、 设置网关策略、自动设置 DNS 解析等。
-- 
+- Workload：定义组件如何运行，
 
 它强调一个现代应用是多个“组件”（Component）的集合，而非一个简单的工作负载或者 K8s Operator。更进一步的，OAM 把这个应用所需的“运维策略”（Trait）也认为是一个应用的一部分，在 OAM 中，一个应用程序包含三个核心理念：
 - 第一个核心理念是组成应用程序的组件（Component），它可能包含微服务集合、数据库和云负载均衡器；

diff --git a/application-centric/Operator.md b/application-centric/Operator.md
@@ -29,21 +29,13 @@ spec:
             storage: 8Gi
 ```
 
-Operator 的实现上，其实是 Kubernetes 声明式 API 基础上的一种“微创新”。它利用了 CRD 构建“高层抽象”，又通过 Kubernetes 原生的“控制器模式”，将复杂应用的运维逻辑代码化
+Operator 的实现上，其实是 Kubernetes 声明式 API 基础上的一种“微创新”。它利用了 CRD 构建“高层抽象”，又通过 Kubernetes 原生的“控制器模式”，将复杂应用的运维逻辑代码化。这种设计带来的好处远不止操作简单，而是充分遵循 Kubernetes 基于资源和控制器的设计原则，又无需受限于内置资源的表达能力。只要开发者愿意编写代码，特定领域的经验都可以转换为代码，通过 Operator 继承。
 
-使用 CRD 构建“高层抽象”、使用配套的控制器来维护期望状态，带来的好处远不止使用简单。以往的高可用、扩展收缩、以及故障恢复等等运维经验沉淀为代码，通过 Operator 继承。只要几行代码，就可以复用最专业的运维能力。
+Operator 的设计模式使开发者可以根据自身业务自由的定义服务模型和相应的控制逻辑，一经推出就在开源社区引起了巨大的反响。主流的分布式应用纷纷推出了对应的 Operator 开源项目，RedHat 公司收购 CoreOS 之后也持续投入，推出了简化开发者编写 Operator 的 Operator Framework，进一步降低应用开发对 Kubernetes 底层 API 知识的依赖。
 
-
-不过，开发 Operator 的门槛相对较高，需要既了解 Kubernetes、又了解开发、又了解运维，通常又专业的组件公司开发。
-
-
-
-2019 年，Red Hat、AWS、Google Cloud 和 Microsoft 联合推出了 OperatorHub.io，为 Kubernetes 社区提供一个官方的、经过验证的 Operator 集中目录。用户搜索所需的 Operator，查看说明文档和安装指南，通过几行命令即可在目标集群上完成 Operator 的安装。
+2019 年，Red Hat、AWS、Google Cloud 和 Microsoft 联合推出了 OperatorHub.io，为开源社区中的大量 Operator 定义统一的质量标准，并提供一个集中式的公共仓库。用户可以在该平台上搜索与业务应用对应的 Operator，通过向导页完成安装。同时，开发者也可以基于 Operator Framework 开发自己的 Operator，并将其上传分享至仓库。
 
 :::center
   ![](../assets/operatorhub.io.png)<br/>
  图 3-14 operatorhub.io
 :::
-
-
-无论是 Helm、Kustomize 或者是 CRD + Operator ，它们在各自领域承载的是一个“组件”的概念，对于一个完整的“应用”，即面向具体业务场景的定义、部署和运行需求，仍旧缺乏思想指导和有效的解决手段。