更新内容

Observability/metrics.md

@@ -13,4 +13,8 @@
 
 云原生监控指标可观测产品大都是从传统的监控产品发展而来的，传统监控中Zabbix以其高可用和图形化展示而广受欢迎。
 
-而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。
+而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。
+
+从存储上来讲所有的监控指标metric都是相同的，但是在不同的场景下这些metric又有一些细微的差异。例如，在Node Exporter返回的样本中指标node_load1反应的是当前系统的负载状态，随着时间的变化这个指标返回的样本数据是在不断变化的。而指标node_cpu所获取到的样本数据却不同，它是一个持续增大的值，因为其反应的是CPU的累积使用时间，从理论上讲只要系统不关机，这个值是会无限变大的。
+
+为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4种不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。

architecture/container.md

@@ -1,6 +1,8 @@
 # 1.5.1 容器技术
 
-虽然容器概念是在 Docker 出现以后才开始在全球范围内火起来的，但容器却不是从 Docker 诞生的。事实上，容器连新技术都算不上，在 Docker 之前，就已经有无数先驱在探索这一极具前瞻性的虚拟化技术。
+时间回到 2013 年，当一条简单的 docker run postgre 命令就能运行起 postgre 这样复杂的传统服务时，开发者在震惊之余犹如受到天启。
+
+以 docker 为代表的实用容器技术的横空出世，也预示着一扇通往敏捷基础设施的大门即将打开。越来越多的开发者开始采用容器作为一种标准构建和运行方式，同时业界也意识到，很容易将这种封装方式引入计算集群，通过 Kubernetes 或 Mesos 这样的编排器来调度计算任务 —— 自此，容器便成为这些调度器最重要的 workload 类型。
 
 本节内容我们概览容器技术演进历程以及各个阶段所试图解决的问题，以便更全面地了解容器技术。
 
@@ -14,9 +16,9 @@ chroot 被认为是最早的容器化技术之一，chroot 可以重定向进程
 
 ## 2.Linux 容器阶段：封装系统 
 
-2006 年，Google 推出 Process Container（进程容器），Process Container 的目的非常直白，它希望能够像虚拟化技术那样给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。带着这样的设计思路，Process Container 推出不久就进入了 Linux Kernel 主干，不过由于 container 这一命名在内核中具有许多不同的含义，为了避免代码命名的混乱，后来就将 Process Container 更名为了 Control Groups，简称 cgroups。
+2006 年，Google 推出 Process Container（进程容器），Process Container 的目的非常直白，它希望能够像虚拟化技术那样给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。带着这样的设计思路，Process Container 推出不久就进入了 Linux 内核主干，不过由于 container 这一命名在内核中具有许多不同的含义，为了避免代码命名的混乱，后来就将 Process Container 更名为了 Control Groups，简称 cgroups。
 
-2008 年 Linux Kernel 2.6.24 刚刚开始提供 cgroups 的同一时间，社区开发者将 cgroups 的资源管理能力和 Linux namespace（命名空间）的资源隔离能力组合在一起，形成了完整的容器技术 LXC（Linux Container，Linux 容器），这就是如今被广泛应用的容器技术的实现基础。
+2008 年 Linux 内核版本 2.6.24 刚刚开始提供 cgroups 的同一时间，社区开发者将 cgroups 的资源管理能力和 Linux namespace（命名空间）的资源隔离能力组合在一起，形成了完整的容器技术 LXC（Linux Container，Linux 容器），这就是如今被广泛应用的容器技术的实现基础。
 
 至 2013 年，Linux 虚拟化技术已基本成型，通过 cgroups、namespace 以及安全防护机制，大体上解决了容器核心技术“运行环境隔离”。彼时，虽然容器运行环境隔离基础已经基本就位，但仍需等待另一项关键技术的出现，才能迎来容器技术的全面繁荣。
 

container/k8s-deploy-containerd.md

@@ -80,6 +80,11 @@ kubelet 和底层容器运行时都需要对接 cgroup 实现容器的资源的
 
 部分系统譬如 debian、centos7 都是使用 systemd 初始化系统，相当于已经有一套 cgroup 资源分配视图了。如果 kubelet 和容器运行时使用 cgroupfs ，也就意味着一个系统里面存在两套资源分配视图。
 
+kubernetes 1.25.0 版本已经全面支持 cgroup v2[^3]，将 cgroupDriver 配置为 systemd，这样将 kubelet 可以通过 systemd 在 cgroup 的 v1 和 v2 版本之间进行自适应：
+- 操作系统发行版启用 cgroup v2
+- Linux 内核为 5.8 或更高版本
+- 容器运行时支持 cgroup v2（containerd v1.4+、cri-o v1.20+）
+
 4. 创建 containerd 的 systemd service 文件
 
 也可从 gtihub 中下载 containerd service 配置文件[^2]，确认二进制执行文件配置正确。
@@ -164,4 +169,5 @@ $ ctr run docker.io/library/nginx:alpine nginx
 
 [^2]: 参见 https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
 [^1]: 参见 https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto
+[^3]: 参见 https://kubernetes.io/zh-cn/docs/concepts/architecture/cgroups/
 

container/resource-limit.md

@@ -1,16 +1,26 @@
 # 7.7 资源与调度
 
-对于 Kubernetes 编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，调度的意思是实现两者之间最恰当的撮合，撮合的关键在于容器编排系统如何管理以及分配集群节点的资源。
-
-管理集群的资源至少要考虑这几个问题：资源模型的抽象（有何种资源、如何表示这些资源）；资源的调度（如何描述一个资源申请、如何描述一台 node 资源分配的状态以及调度的算法）；资源不足时，如何驱逐，如何实现 Pod 的优先级。
+调度是编排系统最重要的功能之一。对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，Kuberntes 调度的职责便是实现两者之间最恰当的撮合，撮合的关键在于容器编排系统。
+
+想要实现资源恰当的撮合，管理以及分配集群节点的资源，至少要清楚这么几个问题：资源模型的抽象（有哪些种类的资源，如何表示这些资源）、
+- 资源模型的抽象
+	- 有哪些种类的资源，例如，CPU、内存等；
+	- 如何用数据结构表示这些资源
+- 资源的调度
+	- 如何描述一个 workload 的资源申请（spec），例如，“该容器需要 4 核和 12GB~16GB 内存”；
+	- 如何描述一台 node 当前的资源分配状态，例如已分配/未分配资源量，是否支持超分等
+	- 调度算法：如何根据 workload spec 为它挑选最合适的 node
+- 资源的限额
+	- 如何确保 workload 使用的资源量不超出预设范围
+	- 如何确保 workload 和系统/基础服务的限额，使二者互不影响
 
 ## 资源模型的抽象
 
 与调度关系最密切的物理资源是处理器和内存/显存，根据调度的处理方式的差别，这两类资源又可分为可压缩和不可压缩两类。
 
 可压缩的资源典型的是 CPU，此类资源超限时，容器进程使用 CPU 会被限制，应用表现变得卡顿，业务延迟明显增加，但**容器进程不会被杀掉**。在 Kubernetes 中，一个 Node 节点 CPU 核心数量乘以 1000，得到的就是该 Node 节点总的 CPU 总数量。CPU 的计量单位为毫核（m），计量方式有多种写法：50m、0.5（`1000m*0.5`）。CPU 的计量是绝对值，这意味着无论容器运行在单核、双核机器上，500m CPU 表示的是相同的计算能力。
 
-不可压缩的资源为内存、显存（GPU），此类资源不足时，容器进程产生 OOM 问题（Out of Memory，内存溢出）并**被杀掉**。内存的计算单位为字节，计量方式有多种写法，譬如使用 M（Megabyte）、Mi（Mebibyte）以及不带单位的数字，以下表达式所代表的是相同的值。
+不可压缩的资源为内存、显存（GPU），容器之间无法共享且完全独占，这也就意味着资源一旦耗尽或者不足，容器进程一定产生 OOM 问题（Out of Memory，内存溢出）并**被杀掉**。内存的计算单位为字节，计量方式有多种写法，譬如使用 M（Megabyte）、Mi（Mebibyte）以及不带单位的数字，以下表达式所代表的是相同的值。
 
 ```plain
 128974848, 129e6, 129M, 123Mi
@@ -24,7 +34,16 @@ Kubernetes 抽象了两个概念 requests 和 limits 用以描述容器资源的
 - **requests** 容器需要的最小资源量。举例来讲，对于一个 Spring Boot 业务容器，这里的 requests 必须是容器镜像中 JVM 虚拟机需要占用的最少资源。
 - **limits** 容器最大可以消耗的资源上限，防止过量消耗资源导致资源短缺甚至宕机。
 
-Pod 是由一到多个容器组成，所以资源的需求作用在容器上的。如下图所示，每一个容器都可以独立地通过 resources 属性设定相应的 requests 和 limits，容器的资源调度以 requests 为准。
+Pod 是由一到多个容器组成，所以资源的需求作用在容器上的。如下图所示，每一个容器都可以独立地通过 resources 属性设定相应的 requests 和 limits，
+
+
+
+CPU 属于可压缩资源，其中 CPU 资源的分配和管理是 Linux 内核借助于完全公平调度算法（ CFS ）和 Cgroup 机制共同完成的。简单地讲，如果 pod 中服务使用 CPU 超过设置的 CPU limits， pod 的 CPU 资源会被限流（ throttled ）。对于没有设置 limit 的 pod ，一旦节点的空闲 CPU 资源耗尽，之前分配的 CPU 资源会逐渐减少。不管是上面的哪种情况，最终的结果都是 Pod 已经越来越无法承载外部更多的请求，表现为应用延时增加，响应变慢。
+
+
+容器的资源调度以 requests 为准。
+
+有的 Pod 内部进程在初始化启动时会提前开辟出一段内存空间。比如 JVM 虚拟机在启动的时候会申请一段内存空间，如果内存 requests 指定的数值小于 JVM 虚拟机向系统申请的内存，导致内存申请失败（ oom-kill ），从而 Pod 出现不断地失败重启。
 
 <div  align="center">
 	<img src="../assets/requests-limits.png" width = "500"  align=center />