更新内容

container/Container-Orchestration-Wars.md

@@ -49,7 +49,7 @@ Docker 刚开源的时候，Cloud Foundry 的产品经理就在社区做了一
 
 正是 Docker 镜像这个“微不足道的创新”，让 Docker 席卷整个 PaaS 领域。
 
-## 3. Kubernetes 入场
+## 4. Kubernetes 入场
 
 Docker 项目利用自己创新的 Docker Image 瞬间爆红，众多厂商也从中发现商机，开始围绕容器编排做一些思考和布局，这其中就包括云计算概念的最早提出者 Google 公司。
 
@@ -66,7 +66,7 @@ Docker 项目利用自己创新的 Docker Image 瞬间爆红，众多厂商也
 
 云计算市场中失去先机的 IT 界的领导者和创新者王者归来，容器编排的竞赛正式拉开帷幕。
 
-## 4. Docker Swarm 入场
+## 5. Docker Swarm 入场
 
 当然，并不是只有 Google 看到了容器市场的机会。DockerCon 2014 大会上，就有多家公司推出了自己的容器编排系统，而 Google 的进场让竞争变得更加激烈。
 
@@ -83,7 +83,7 @@ Docker Swarm 可以在多个服务器上创建容器集群服务，而且依然
 
 如果说 Docker Compose 和 Kubernetes 还不算正面竞争的话，那么 Docker Swarm 的发布，则是正式向 Kubernetes 宣战。
 
-## 5. 搅局者 Marathon
+## 6. 搅局者 Marathon
 
 当集群规模很大，管理的资源很多时，很多人就不愿意再使用 Docker Swarm，也没有选择 Kubernetes，而是选择了 Marathon 和 Mesos。
 
@@ -113,7 +113,7 @@ Mesos 的标杆客户是 Twitter，2010 年，Twitter 正值基础架构混乱
 
 Mesos 在 Twitter 的成功应用后，也吸引了全世界其他知名公司的采纳，比如 Airbnb、eBay 和 Netflix 等等，甚至 2015 年 Apple 的 Siri 就是运行在 Mesos 上，Mesos 也因此曾经火极一时。至于微软，他不仅投资了 Mesosphere（Benjamin Hindman 离开 Twitter 后成立的 mesos 的商业化公司），还让它的 Azure 平台率先支持了 Mesos。
 
-## 6. Kubernetes 扭转局势
+## 7. Kubernetes 扭转局势
 
 面对 Kubernetes 的出现，一场 Docker 和 Kubernetes 之间的容器之战就此打响。
 
@@ -127,7 +127,7 @@ Mesos 在 Twitter 的成功应用后，也吸引了全世界其他知名公司
 
 依托于开放性接口和优秀的架构设计，基于 Kubernetes 的开源项目和插件比比皆是，到现在，CNCF 已经形成了一个百花齐放的稳定庞大的生态。
 
-## 7. Kubernetes 最终胜出
+## 8. Kubernetes 最终胜出
 
 经过设计理念、架构、标准、生态等多方面的较量之后，Docker 在与 Kubernetes 的竞争中逐渐落败，Mesos 因其侧重在传统的资源管理，导致它在应对多云和集群管理时面临很多挑战，标杆客户 Twitter 最后也放弃了 Mesos 改用 Kubernetes。
 

container/orchestration.md

@@ -8,7 +8,7 @@
 
 那么，容器是本质什么呢？如果吧 Kubernetes 比作云原生时代的操作系统，那么容器就是这个操作系统之内的特殊进程。
 
-特殊之处在于容器利用 namespace 对其视图进行隔离，利用 cgroup（约束能用多少资源，内存/磁盘。cpu等）对其资源使用进行约束。
+特殊之处在于容器利用一些内核技术，如 namespace 对其视图进行隔离，cgroup（约束能用多少资源，内存/磁盘。cpu等）对其资源使用进行约束。
 
 使用 Namespace 其实也非常简单，它其实只是 Linux 创建新进程的一个可选参数。比如，在 Linux 系统中创建线程的系统调用是 clone。
 ```
@@ -25,10 +25,7 @@ int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);
 
 这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。
 
-这些进程就会觉得自己是各自 PID Namespace 里的第 1 号进程，只能看到各自 Mount Namespace 里挂载的目录和文件，只能访问到各自 Network Namespace 里的网络设备，就仿佛运行在一个个“容器”里面，与世隔绝
-
-
-除了刚刚用到的 PID Namespace，Linux 操作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行隔离操作。
+这些进程就会觉得自己是各自 PID Namespace 里的第 1 号进程，只能看到各自 Mount Namespace 里挂载的目录和文件，只能访问到各自 Network Namespace 里的网络设备，就仿佛运行在一个个“容器”里面，与世隔绝。
 
 隔离之后，还有一个关键问题：操作系统如何管理或者限制被隔离进程使用的资源（CPU、内存、网络带宽、磁盘等）？这就是上面提到的第二项技术了： Linux Control Cgroup，即 cgroups。
 

intro.md

@@ -62,7 +62,7 @@
 
 视角转回到工程师个体，不管你是否能接受，软件行业解决问题的技术一直在变化，并且这种变化并不是平缓的升级，而是剧烈的革新替代。例如容器替代虚拟机、服务网格替代 SpringCloud、观测替代监控、Network Policy 替代 iptables 等等。剧烈背景下，如果只专注于手头的工作，不抬头看天，过度关注于某个技术深度和细节，大革命来临的时候，你关注的细节可能再也没有意义。
 
-所以，本书很少详细的描述某个软件如何安装、如何使用，而是尝试从它们解决问题的角度出发，思考问题本质以及不同的解决方式，找到些许核心原理以及悟透点发展规律，例如分布式系统演进方向是 CAP 定理的权衡选择，局限在于时间与空间法则。再如容器、服务网格、Cilium、Calico，也不是什么黑科技，只是把不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
+所以，本书很少详细描述某个软件如何安装、如何使用，而是尝试从它们解决问题的角度出发，思考问题本质以及不同的解决方式，找到些许核心原理以及悟透点发展规律，例如分布式系统演进方向是 CAP 定理的权衡选择，局限在于时间与空间法则。再如容器、服务网格、Cilium、Calico，也不是什么黑科技，只是把不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
 
 本书的宗旨是希望能说清楚这些问题的本质，解释清楚整个服务架构的发展历程，走过了哪些弯路，以至于今天使用了哪些技术的缘由，讨论它们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。