update

isno · Dec 24, 2024 · 761227b · 761227b
1 parent a97df7d
commit 761227b
Show file tree

Hide file tree

Showing 4 changed files with 26 additions and 29 deletions.
diff --git a/.vuepress/config.js b/.vuepress/config.js
@@ -25,11 +25,11 @@ export default defineUserConfig({
             })(); 
      `
  ]
-    ]/*,
-    bundler: webpackBundler({
+    ],
+    /**bundler: webpackBundler({
         postcss: {},
         vue: {},
-      })*/,
+      }),*/
     plugins: [
         mdEnhancePlugin({
           // 启用脚注
@@ -73,6 +73,7 @@ export default defineUserConfig({
             }
         ],
         sidebar: [
+
             '/intro.md',
             '/noun.md',
             {
@@ -305,29 +306,24 @@ export default defineUserConfig({
                 ]
             },
             {
-                text: '第十章：GitOps 理念与实现设计',
-                link: '/GitOps/summary.md',
+                text: '第十章：应用的封装与交付',
+                link: '/application-centric/summary.md',
                 collapsable: false,
                 sidebarDepth: 1,
                 children: [
-                    '/GitOps/background.md',
-                    '/GitOps/what-is-GitOps.md',
-                    '/GitOps/IaC.md',
-                    '/GitOps/secrets-management.md',
-                     {
-                        text: "10.4 使用 Tekton 进行持续集成",
-                        link: '/GitOps/Tekton.md',
+                    '/application-centric/Controller.md',
+                    '/application-centric/IaD.md',
+                    {
+                        text: "10.3 从“构建抽象”到“应用模型”",
+                        link: '/application-centric/app-model.md',
                         children: [
-                            '/GitOps/Tekton-CRD.md',
-                            '/GitOps/Tekton-install.md',
-                            '/GitOps/Tekton-test.md',
-                            '/GitOps/Tekton-build-image.md',
-                            '/GitOps/Tekton-trigger.md',
-
+                            '/application-centric/Kustomize.md',
+                            '/application-centric/Helm.md',
+                            '/application-centric/Operator.md',
                         ]
                     },
-                    '/GitOps/ArgoCD.md',
-                    '/GitOps/conclusion.md',
+                    '/application-centric/GitOps.md',
+                    '/application-centric/conclusion.md',
                 ]
             }
         ]

diff --git a/application-centric/Operator.md b/application-centric/Operator.md
@@ -6,16 +6,17 @@ Operator 其实并不算一个工具，而是为了解决一个问题而存在
 
 Operator 属于 Kubernetes 中的高级应用，理解 Operator 所做的工作，需要先弄清楚“有状态服务”和无状态服务的含义。
 
-无状态服务是一种不依赖于之前请求状态来处理新请求的服务。从一个请求到下一个请求，服务不会记住任何信息，每个请求都是独立的，就好像每次服务都是在全新的状态下开始处理一样。它们互相之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Deployment 就可以通过 Pod 模板创建新的 Pod；不需要的时候，Deployment 就可以“杀掉”任意一个 Pod。
+无状态服务是一种不依赖于之前请求状态来处理新请求的服务。从一个请求到下一个请求，服务不会记住任何信息，每个请求都是独立的，就好像每次服务都是在全新的状态下开始处理一样。Deployment 只适合于编排“无状态应用”，它会假设一个应用的所有 Pod是完全一样的，互相之间也没有顺序依赖，也无所谓运行在哪台宿主机上。正因为每个 Pod 都一样，需要的时候水平扩/缩，增加和删除 Pod。
 
-对应有状态服务，需要考虑的细节就多了。服务运行的实例需要在本地存储持久化数据，比如上面的MySQL数据库，你现在运行在节点A，那么他的数据就存储在节点A上面的，如果这个时候你把该服务迁移到节点B去的话，那么就没有之前的数据了。
 
-容器化应用程序最困难的任务之一，就是设计有状态分布式组件的部署体系结构。
+对应有状态服务，需要考虑的细节就多了。服务运行的实例需要在本地存储持久化数据，比如 MySQL 数据库，你现在运行在节点 A，那么他的数据就存储在节点 A 上面的，如果这个时候你把该服务迁移到节点 B 去的话，那么就没有之前的数据了。针对这类应用使用 Deployment 控制器无法实现正确调度。
 
 
-- **有序部署和删除**：StatefulSet 中的 Pod 会按照顺序创建和删除。每个 Pod 都有一个唯一的、持久的网络标识符（通常是 Pod 的名称），这使得它们可以被用作长期服务。
-- **稳定的持久化存储**：StatefulSet 确保每个 Pod 都能够挂载一个持久化存储卷，这个存储卷的生命周期独立于 Pod，即使 Pod 被删除或重新创建，存储卷也会保持不变。
-- **唯一性和顺序性**：StatefulSet 中的每个 Pod 都有一个唯一的标识（通常是 Pod 名称），并且它们会按照顺序启动和停止。这对于需要严格顺序或唯一性的场景（如分布式数据库的复制集群）非常重要。
+StatefulSet，是在 Deployment 的基础上扩展出来的控制器，在 1.9 版本之后才加入 Kubernetes 控制器家族，它把有状态应用需要保持的状态抽象分为了两种情况：
+
+- **拓扑状态**。这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。
+- **存储状态**。这种情况意味着，应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和 Pod A 被重新创建后再次读取到的数据，应该是同一份。这种情况最典型的例子，就是一个数据库应用的多个存储实例。
+
 
 所以，StatefulSet 的核心功能就是用某种方式记录这些状态，然后在 Pod 重建时能够恢复到原来的状态。
 

diff --git a/architecture/arc.md b/architecture/arc.md
@@ -14,6 +14,6 @@
  图 1-33 传统架构与云原生架构对比
 :::
 
-从单个微服务应用的角度看，自身的复杂度降低了。在“强大底层系统”支撑的情况下，应用监控、通信治理、编排调度相关的逻辑从应用中剥离，并下沉到底层系统，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本（人力成本、资源成本、技术试错成本）是非常昂贵的。为了降低成本，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计。
+从研发应用的角度看，研发的复杂度降低了。在“强大底层系统”支撑的情况下，应用监控、通信治理、编排调度相关的逻辑从应用中剥离，并下沉到底层系统，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本（人力成本、资源成本、技术试错成本）是非常昂贵的。为了降低成本，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计。
 
-最后，通过 yaml 声明式代码、编排底层的基础设施以及各类中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。
+最后，通过 YAML 声明式描述、编排底层的基础设施以及各类中间件资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。
diff --git a/architecture/define-cloud-native.md b/architecture/define-cloud-native.md
@@ -15,7 +15,7 @@
   图 1-8 Pivotal 对云原生定义
 :::
 
-随着时间的推移，详细解释这些早期的特征已经没有什么必要，只要知道这些内容研究的是“用更恰当的姿势上云”即可。由此可见，云原生并不是简单地使用云平台运行现有的应用程序，而是能充分利用云计算优势对应用程序进行设计、实现、部署、交付的理念方法。
+随着时间的推移，详细解释这些早期的特征已经没有什么必要，只要知道这些内容研究的是“用更恰当的姿势上云”即可。由此可见，云原生并不是简单地使用云平台运行现有的应用程序，而是能充分利用云计算优势对应用程序进行设计、实现、部署、交付的理念。
 
 2017 年 10 月，还是 Matt Stine，接受 InfoQ 采访时，他对云原生的定义做了小幅调整，云原生程序具有图 1-9 所示的 6 个特质。