UPDATE

application-centric/Operator.md

@@ -1,27 +1,23 @@
 # 10.5 Operator
 
-Operator 其实并不算一个工具，而是为了解决一个问题而存在的一个思路。
+Operator 的概念由 CoreOS 公司在 2016 年提出，它其实并不算一个工具或者系统，而是一种封装、部署、管理 Kubernetes 应用的一种方法，特别是那些需要特定领域知识复杂有状态应用，例如数据库、分布式缓存和消息队列等。
 
-由 CoreOS 公司在 2016 年提出。
-
-Operator 属于 Kubernetes 中的高级应用，理解 Operator 所做的工作，需要先弄清楚“有状态服务”和无状态服务的含义。
+理解 Operator 所做的工作，需要先弄清楚“有状态服务”和“无状态服务”的含义。
 
 无状态服务是一种不依赖于之前请求状态来处理新请求的服务。从一个请求到下一个请求，服务不会记住任何信息，每个请求都是独立的，就好像每次服务都是在全新的状态下开始处理一样。Deployment 只适合于编排“无状态应用”，它会假设一个应用的所有 Pod是完全一样的，互相之间也没有顺序依赖，也无所谓运行在哪台宿主机上。正因为每个 Pod 都一样，需要的时候水平扩/缩，增加和删除 Pod。
 
+对于有状态服务，需要考虑的细节就多了。服务运行的实例需要在本地存储持久化数据，比如 MySQL 数据库，你现在运行在节点 A，那么他的数据就存储在节点 A 上面的，如果这个时候你把该服务迁移到节点 B 去的话，那么就没有之前的数据了。针对这类应用使用 Deployment 控制器无法实现正确调度。
 
-对应有状态服务，需要考虑的细节就多了。服务运行的实例需要在本地存储持久化数据，比如 MySQL 数据库，你现在运行在节点 A，那么他的数据就存储在节点 A 上面的，如果这个时候你把该服务迁移到节点 B 去的话，那么就没有之前的数据了。针对这类应用使用 Deployment 控制器无法实现正确调度。
-
-
-StatefulSet，是在 Deployment 的基础上扩展出来的控制器，在 1.9 版本之后才加入 Kubernetes 控制器家族，它把有状态应用需要保持的状态抽象分为了两种情况：
+Kubernetes v1.9 版本引入 StatefulSet，它把有状态应用需要保持的状态抽象分为两种情况：
 
-- **拓扑状态**。这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。
-- **存储状态**。这种情况意味着，应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和 Pod A 被重新创建后再次读取到的数据，应该是同一份。这种情况最典型的例子，就是一个数据库应用的多个存储实例。
+- **拓扑状态**。这种情况意味着，应用的多个实例之间并非完全对等关系。例如，在“主从”（Master-Slave）架构中，主节点 A 必须先于从节点 B 启动。若 A 和 B 两个 Pod 被删除后重新创建，也需严格遵循这一启动顺序。此外，新创建的 Pod 必须保留与原 Pod 相同的网络标识，以确保现有访问者能够通过原有的访问方式连接到新的 Pod。
+- **存储状态**。这种情况意味着，应用的多个实例分别绑定了独立的存储数据。对于这些实例而言，Pod A 无论是首次读取数据还是在被重新创建后再次读取，所获取的数据都必须保持一致。最典型的例子，就是一个数据库应用的多个存储实例。
 
+所以说，StatefulSet 的核心功能就是用某种方式记录这些状态，当有状态应用的 Pod 重建后，仍然满足上一次运行状态的需求。
 
-所以，StatefulSet 的核心功能就是用某种方式记录这些状态，然后在 Pod 重建时能够恢复到原来的状态。
+通过 StatefulSet，有状态应用实现了安装、启动、停止等基础的运维操作。对于其他高级运维操作，例如升级、扩容、备份、恢复、监控和故障转移，StatefulSet 并不能提供有效的帮助。其次，通过 StatefulSet，定义相当多的细节，比如我们要部署一套 etcd 集群，要设置节点通信端口、环境变量配置、持久化存储、网络策略、安全证书、健康检查等大量细节。
 
-
-假设我们要部署一套 etcd 集群，通常要在 StatefulSet 中定义相当多的细节。比如节点通信端口、环境变量配置、持久化存储、网络策略、安全证书、健康检查等等。
+通过下面 etcd 的例子感受。
 
 ```yaml
 apiVersion: apps/v1
@@ -108,30 +104,7 @@ spec:
     app: etcd
 ```
 
-
-将特定应用程序的操作逻辑编码，
-
-
-在 Kubernetes 实现容器编排的核心思想中，会使用控制器（Controller）模式对 etcd 里的 API 模型对象变化保持不断的监听（Watch），并在控制器中对指定事件进行响应处理，针对不同的 API 模型可以在对应的控制器中添加相应的业务逻辑，通过这种方式完成应用编排中各阶段的事件处理。而 Operator 正是基于控制器模式，允许应用开发者通过扩展 Kubernetes API 对象的方式，将复杂的分布式应用集群抽象为一个自定义的 API 对象，通过监听 API 对象，实现。
-
-
-:::center
-  ![](../assets/kubernetes_operator.webp)<br/>
-  图 10-6 使用 Tekton 进行持续集成的流程
-:::
-
-
-
-
-
-
-
-- 稳定的标识符：
-
-通过 StatefulSet，最多只能做到安装、基础的运维操作。对于其他高级运维操作，例如升级、扩容、备份、恢复、监控和故障转移，StatefulSet 并不能提供有效的帮助。
-
-Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力，然后又巧妙的通过 Kubernetes 原生的“控制器模式”，完成了一个面向分布式应用终态的调谐过程。
-
+如果使用 Operator，情况就简单得多。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码就可以实现上面等同的功能，如下面代码所示。
 
 ```yaml
 apiVersion: operator.etcd.database.coreos.com/v1beta2
@@ -152,17 +125,13 @@ spec:
             storage: 8Gi
 ```
 
-有了 Elasticsearch 自定义资源，相当于 Kubernetes 已经知道了
-
-
-如果说 Docker 是奠定的单实例的标准化交付，那么 Helm 则是集群化多实例、多资源的标准化交付。Operator 则在实现自动化的同时实现了智能化，
+Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力，然后又巧妙的通过 Kubernetes 原生的“控制器模式”，完成了一个面向分布式应用终态的调谐过程。
 
-而处于第三方视角的 Operator，则可以解决这个问题。
 
+使用 CRD 构建“高层抽象”，带来的好处远不止使用简单。
 
 就是把运维的经验沉淀为代码，实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩，以及故障恢复等等运维操作，都通过 Operator 进行沉淀下来。
 
-
-现在很多复杂分布式系统都有了官方或者第三方提供的 Operator，从数据库（如 MySQL、PostgreSQL、MongoDB）到消息队列（如 RabbitMQ、Kafka），再到监控系统（如 Prometheus）
+现在很多复杂分布式系统都有了官方或者第三方提供的 Operator，从数据库（如 MySQL、PostgreSQL、MongoDB）到消息队列（如 RabbitMQ、Kafka），再到监控系统（如 Prometheus）。
 
 这些 Operator 提供了 Kubernetes 集群中各种服务和应用程序的生命周期管理，

consensus/summary.md

@@ -7,9 +7,9 @@
 —— Mike Burrows，Google Chubby 作者
 :::
 
-分布式系统中充满了各种潜在的错误场景，网络数据包可能丢失、顺序紊乱、重复发送或者延迟，节点还可能宕机。
+分布式系统中充满了各种潜在的错误场景，网络数据包可能丢失、顺序紊乱、重复发送或者延迟，节点还可能宕机。“在充满不确定性的环境中，就某个决策达成共识”是软件工程领域最具挑战性的问题之一。
 
-“在充满不确定的环境下就某个决策达成共识”是软件工程领域最具挑战性的问题之一。这一章，我们知难而上，从解决问题的角度出发理解什么是共识，沿着 Paxos 算法讨论如何达成共识，以工程实践为目的学习 Raft 算法的设计思想。最后，理解了问题以及如何解题，自然能体会到 Apache Kafka、 Zookeeper、etcd、Consul 等分布式应用的设计原理、领悟构建大规模分布式系统的关键要素。
+这一章，我们迎难而上，从解决问题的角度出发理解什么是共识，沿着 Paxos 算法的思路讨论如何达成共识，以工程实践为目的学习 Raft 算法的设计思想。最后，理解了问题以及如何解题，自然能体会到 Apache Kafka、 Zookeeper、etcd、Consul 等分布式系统核心组件的设计原理，掌握构建大规模分布式系统的关键要素。
 
 :::center
   ![](../assets/consensus-summary.png) <br/>

distributed-transaction/summary.md

@@ -11,7 +11,7 @@
 
 事务（transaction）最早指本地事务，即对数据库的多个读写操作捆绑为一个操作单元，该操作单元作为一个执行整体要么全部成功、要么全部中止，从而保证某些极端情况下（进程崩溃、网络中断、节点宕机）数据一致性。随着分布式系统的广泛应用，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性处理等等，都需要用到事务的机制进行处理。
 
-当事务操作局限在本地时，如何实现事务仅仅是个编码问题。但若事务操作跨越了多个节点，保证多个节点间的数据一致性便成了架构设计问题。2000 年以前，人们曾经希望基于两阶段提交（2PC, Two-Phase Commit Protocol）[^2]的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，掌握各个分布式事务模型原理。
+当事务操作局限在本地时，如何实现事务仅仅是个编码问题。但若事务操作跨越了多个节点，保证多个节点间的数据一致性便成了架构设计问题。2000 年以前，人们曾经希望基于“两阶段提交”（2PC, Two-Phase Commit Protocol）[^2]的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，掌握各个分布式事务模型原理。
 
 :::center
   ![](../assets/distributed-transaction.png)

network/kernel-bypass.md

@@ -1,5 +1,5 @@
 # 3.4 内核旁路技术
 
-通过前文对“Linux 系统收包流程”和内核网络框架的介绍，相信读者已经感受到 Linux 内核网络系统的复杂性。**对于网络密集型应用，内核态与用户态的频繁切换，以及复杂的网络协议栈处理，往往使 Linux 内核成为性能瓶颈**。
+通过前文对“Linux 系统收包流程”和内核网络框架的介绍，相信读者已经感受到 Linux 内核网络系统的复杂性。对于网络密集型应用，内核态与用户态的频繁切换，以及复杂的网络协议栈处理，常常导致 Linux 内核成为性能瓶颈。
 
-在人们想办法提升 Linux 内核处理性能的同时，另外一批人抱着它不行就绕开它的思路，提出了一种“内核旁路（Kernel bypass）”思想的技术方案。其中，DPDK 和 XDP 是主机内“内核旁路”思想的代表技术，RDMA 是主机之间“内核旁路”思想的代表技术。
+在人们想办法提升 Linux 内核性能的同时，另外一批人抱着它不行就绕开它想法，提出了一种“内核旁路“（Kernel bypass）思想的技术方案。其中，DPDK 和 XDP 是主机内“内核旁路”思想的代表技术，RDMA 是主机之间“内核旁路”思想的代表技术。