修改容器

container/orchestration.md

@@ -4,9 +4,9 @@
 
 “上云” 最终还是要深入理解容器的本质是什么。
 
-## 思考容器的本质
+## 容器的本质是隔离的进程
 
-那么，容器是本质什么呢？是个特殊的进程！把 Kubernetes 比作云原生时代的操作系统，那么容器就是这个操作系统之内的特殊进程。
+那么，容器是本质什么呢？如果吧 Kubernetes 比作云原生时代的操作系统，那么容器就是这个操作系统之内的特殊进程。
 
 操作系统视角下的进程访问资源并没有边界，可以使用计算机中所有的资源。
 
@@ -36,7 +36,7 @@ cgroup 则控制 CPU、内存、设备和网络等资源。实施对应用的资
 
 容器技术是动态的容器、静态的镜像、远程的仓库这三者的组合。
 
-## 进程组
+## 容器编排的第一个扩展是进程组
 
 在一个真正的 OS 内，进程并非“孤苦伶仃” 独自运行，而是以进程组，有原则的组织在一起。登录到一台 Linux 机器，展示当前系统中正在运行的进程述状结构，执行如下命令：
 
@@ -56,29 +56,12 @@ systemd(1)─┬─abrt-dbus(540)─┬─{abrt-dbus}(540)
 
 对os，这样的进程组更方便管理。Linux操作系统只需将信号，如SIGKILL信号，发给一个进程组，该进程组中的所有进程就都会收到这个信号而终止运行。而 Kubernetes 所做的，其实就是将“进程组”的概念映射到容器技术，并使其成为云原生操作系统“os”内的“一等公民”。
 
-
-容器的本质是对 cgroups 和 namespaces 所提供的隔离能力的一种封装，在 Docker 提倡的单进程封装的理念影响下，容器蕴含的隔离性也多了仅针对于单个进程的额外局限，然而 Linux 的 cgroups 和 namespaces 原本都是针对进程组而不仅仅是单个进程来设计的，同一个进程组中的多个进程天然就可以共享着相同的访问权限与资源配额。
-
 如果现在我们把容器与进程在概念上对应起来，那容器编排的第一个扩展点，就是要找到容器领域中与“进程组”相对应的概念，这是实现容器从隔离到协作的第一步，在 Kubernetes 的设计里，这个对应物叫作 Pod。
 
 ## 容器设计模式
 
 
-笔者希望的是能说清楚“Kubernetes为什么这样设计？”，而回答这个问题最好**从它的设计意图出发，从解决问题的角度去理解为什么 Kubernetes 要设计这些资源和控制器**。为此，笔者虚构了一系列从简单到复杂的场景供你代入其中。如此知其所以然，方能真正理解，
-
-:::tip 场景一
-假设现在有两个应用，其中一个是 Nginx，另一个是为该 Nginx 收集日志的 Filebeat，你希望将它们封装为容器镜像，以方便日后分发。
-:::
-
-最直接的方案就将 Nginx 和 Filebeat 直接编译成同一个容器镜像，这是可以做到的，而且并不复杂，然而这样做会埋下很大隐患：它违背了 Docker 提倡的单个容器封装单进程应用的最佳实践。
-
-:::tip 场景二
-假设现在有两个 Docker 镜像，其中一个封装了 HTTP 服务，为便于称呼，我们叫它 Nginx 容器，另一个封装了日志收集服务，我们叫它 Filebeat 容器。现在要求 Filebeat 容器能收集 Nginx 容器产生的日志信息。
-:::
-
-场景二依然不难解决，只要在 Nginx 容器和 Filebeat 容器启动时，分别将它们的日志目录和收集目录挂载为宿主机同一个磁盘位置的 Volume 即可，这种操作在 Docker 中是十分常用的容器间信息交换手段。
-
-这种针对具体应用需求来共享名称空间的方案，的确可以工作，却并不够优雅，也谈不上有什么扩展性。容器的本质是对 cgroups 和 namespaces 所提供的隔离能力的一种封装，在 Docker 提倡的单进程封装的理念影响下，容器蕴含的隔离性也多了仅针对于单个进程的额外局限，然而 Linux 的 cgroups 和 namespaces 原本都是针对进程组而不仅仅是单个进程来设计的，同一个进程组中的多个进程天然就可以共享着相同的访问权限与资源配额。
+容器的本质是对 cgroups 和 namespaces 所提供的隔离能力的一种封装，在 Docker 提倡的单进程封装的理念影响下，容器蕴含的隔离性也多了仅针对于单个进程的额外局限，然而 Linux 的 cgroups 和 namespaces 原本都是针对进程组而不仅仅是单个进程来设计的，同一个进程组中的多个进程天然就可以共享着相同的访问权限与资源配额。
 
 
 <div  align="center">

container/resource-limit.md

@@ -1,6 +1,6 @@
 # 7.7 资源与调度
 
-对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，编排调度的职责便是实现两者之间最恰当的撮合。想要实现这个目标，那么管理以及分配集群节点的资源，至少要清楚这么几个问题：
+对于 Kubernetes 这个编排系统而言，编排调度的首要职责是实现资源提供者（Node）、资源使用者（Pod）两者之间最恰当的撮合。想要实现这个目标，那么管理以及分配集群节点的资源，至少要清楚这么几个问题：
 
 - **资源模型的抽象**有哪些种类的资源，如何表示这些资源。
 - **资源的调度**如何描述一个 workload 的资源申请、如何描述一台 node 当前的资源分配状态，例如已分配/未分配资源量。