style: apply global formatting fixes (struct, spacing, zhlint)

2026-03-11 12:21:17 +00:00 · 2026-02-21 11:08:52 -08:00
parent ad68b2d973
commit 79ac9c639a
159 changed files with 1708 additions and 882 deletions
--- a/12_orchestration/kubernetes/advanced.md
+++ b/12_orchestration/kubernetes/advanced.md
@@ -1,10 +1,10 @@
 ## Kubernetes 高级特性

-掌握了 Kubernetes 的核心概念（Pod, Service, Deployment）后，我们需要了解更多高级特性以构建生产级应用。
+掌握了 Kubernetes 的核心概念 (Pod，Service，Deployment) 后，我们需要了解更多高级特性以构建生产级应用。

 ### Helm - 包管理工具

-[Helm](https://helm.sh/) 被称为 Kubernetes 的包管理器（类似于 Linux 的 apt/yum）。它将一组 Kubernetes 资源定义文件打包为一个 **Chart**。
+[Helm](https://helm.sh/) 被称为 Kubernetes 的包管理器 (类似于 Linux 的 apt/yum)。它将一组 Kubernetes 资源定义文件打包为一个 **Chart**。

 *   **安装应用**：`helm install my-release bitnami/mysql`
 *   **版本管理**：轻松回滚应用的发布版本。
@@ -12,25 +12,25 @@

 ### Ingress - 服务的入口

-Service 虽然提供了负载均衡，但通常是 4 层（TCP/UDP）。**Ingress** 提供了 7 层（HTTP/HTTPS）路由能力，充当集群的网关。
+Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress** 提供了 7 层 (HTTP/HTTPS) 路由能力，充当集群的网关。

-*   **域名路由**：基于 Host 将请求转发不同服务 (api.example.com -> api-svc, web.example.com -> web-svc)。
-*   **路径路由**：基于 Path 将请求转发 (/api -> api-svc, / -> web-svc)。
+*   **域名路由**：基于 Host 将请求转发不同服务 (api.example.com -> api-svc，web.example.com -> web-svc)。
+*   **路径路由**：基于 Path 将请求转发 (/api -> api-svc， / -> web-svc)。
 *   **SSL/TLS**：集中管理证书。

-常见的 Ingress Controller有 Nginx Ingress Controller, Traefik, Istio Gateway 等。
+常见的 Ingress Controller 有 Nginx Ingress Controller，Traefik，Istio Gateway 等。

-### Persistent Volume（PV） 与 StorageClass
+### Persistent Volume 与 StorageClass

-容器内的文件是临时的。对于有状态应用（如数据库），需要持久化存储。
+容器内的文件是临时的。对于有状态应用 (如数据库)，需要持久化存储。

 *   **PVC (Persistent Volume Claim)**：用户申请存储的声明。
-*   **PV (Persistent Volume)**：实际的存储资源（NFS, AWS EBS, Ceph 等）。
+*   **PV (Persistent Volume)**：实际的存储资源 (NFS，AWS EBS，Ceph 等)。
 *   **StorageClass**：定义存储类，支持动态创建 PV。

-### Horizontal Pod Autoscaling（HPA）
+### Horizontal Pod Autoscaling

-HPA 根据 CPU 利用率或其他指标（如内存、自定义指标）自动扩缩 Deployment 或 ReplicaSet 中的 Pod 数量。
+HPA 根据 CPU 利用率或其他指标 (如内存、自定义指标) 自动扩缩 Deployment 或 ReplicaSet 中的 Pod 数量。

 ```yaml
 apiVersion: autoscaling/v2
@@ -55,7 +55,7 @@ spec:

 ### ConfigMap 与 Secret

-*   **ConfigMap**：存储非机密的配置数据（配置文件、环境变量）。
-*   **Secret**：存储机密数据（密码、Token、证书），在 Etcd 中加密存储。
+*   **ConfigMap**：存储非机密的配置数据 (配置文件、环境变量)。
+*   **Secret**：存储机密数据 (密码、Token、证书)，在 Etcd 中加密存储。

 通过将配置与镜像分离，保证了容器的可移植性。
--- a/12_orchestration/kubernetes/concepts.md
+++ b/12_orchestration/kubernetes/concepts.md
@@ -6,16 +6,16 @@

 图 12-2 Kubernetes 基本概念示意图

-* 节点（`Node`）：一个节点是一个运行 Kubernetes 中的主机。
-* 容器组（`Pod`）：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。
-* 容器组生命周期（`pod-states`）：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。
+* 节点 (`Node`)：一个节点是一个运行 Kubernetes 中的主机。
+* 容器组 (`Pod`)：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷 (volume)。
+* 容器组生命周期 (`pod-states`)：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。
 * Replication Controllers：主要负责指定数量的 pod 在同一时间一起运行。
-* 服务（`services`）：一个 Kubernetes 服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。
-* 卷（`volumes`）：一个卷就是一个目录，容器对其有访问权限。
-* 标签（`labels`）：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
-* 接口权限（`accessing_the_api`）：端口，IP 地址和代理的防火墙规则。
-* web 界面（`ux`）：用户可以通过 web 界面操作 Kubernetes。
-* 命令行操作（`cli`）：`kubectl`命令。
+* 服务 (`services`)：一个 Kubernetes 服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。
+* 卷 (`volumes`)：一个卷就是一个目录，容器对其有访问权限。
+* 标签 (`labels`)：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
+* 接口权限 (`accessing_the_api`)：端口，IP 地址和代理的防火墙规则。
+* web 界面 (`ux`)：用户可以通过 web 界面操作 Kubernetes。
+* 命令行操作 (`cli`)：`kubectl` 命令。

 ### 节点

@@ -25,7 +25,7 @@

 容器状态用来描述节点的当前状态。现在，其中包含三个信息：

-##### 主机IP
+##### 主机 IP

 主机 IP 需要云平台来查询，`Kubernetes` 把它作为状态的一部分来保存。如果 `Kubernetes` 没有运行在云平台上，节点 ID 就是必需的。IP 地址可以变化，并且可以包含多种类型的 IP 地址，如公共 IP，私有 IP，动态 IP，ipv6 等等。

@@ -67,17 +67,17 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
 * 集群范围内节点同步
 * 单节点生命周期管理

-节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period`标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines`标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false`标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。
+节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period` 标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines` 标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false` 标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。

 ### 容器组

-在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。 一个容器组使用相同的 Docker 容器并共享卷（挂载点）。一个容器组是一个特定应用的打包集合，包含一个或多个容器。
+在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。一个容器组使用相同的 Docker 容器并共享卷 (挂载点)。一个容器组是一个特定应用的打包集合，包含一个或多个容器。

-和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，直到容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）。
+和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，直到容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。(也许在将来的版本中会添加容器组的移动)。

 #### 容器组设计的初衷

-容器组（Pod）的设计主要是为了解决应用间的紧密协作和资源共享问题。
+容器组 (Pod) 的设计主要是为了解决应用间的紧密协作和资源共享问题。

 #### 资源共享和通信

@@ -85,7 +85,7 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接

 在一个容器组中，容器都使用相同的网络地址和端口，可以通过本地网络来相互通信。每个容器组都有独立的 IP，可用通过网络来和其他物理主机或者容器通信。

-容器组有一组存储卷（挂载点），主要是为了让容器在重启之后可以不丢失数据。
+容器组有一组存储卷 (挂载点)，主要是为了让容器在重启之后可以不丢失数据。

 #### 容器组管理

@@ -105,10 +105,10 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接

 为什么不在一个单一的容器里运行多个程序？

-* 1.透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。
-* 2.解偶软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes 必须支持热发布和热更新（将来）。
-* 3.方便使用。用户不必运行独立的程序管理，也不用担心每个应用程序的退出状态。
-* 4.高效。考虑到基础设施有更多的职责，容器必须要轻量化。
+* 1。透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。
+* 2。解偶软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes 必须支持热发布和热更新 (将来)。
+* 3。方便使用。用户不必运行独立的程序管理，也不用担心每个应用程序的退出状态。
+* 4。高效。考虑到基础设施有更多的职责，容器必须要轻量化。

 #### 容器组的生命状态

@@ -120,7 +120,7 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接

 ##### running

-容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态（或者处于重启状态）。
+容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态 (或者处于重启状态)。

 ##### succeeded

@@ -144,19 +144,19 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
    * 始终：重启容器，容器组保持 `running`
    * 失败时：容器组变为 `succeeded`
    * 从不：容器组变为 `succeeded`
-* 容器组状态 `running`，有1容器，容器异常退出
+* 容器组状态 `running`，有 1 容器，容器异常退出
  * 记录失败事件
  * 如果重启策略为：
    * 始终：重启容器，容器组保持 `running`
    * 失败时：重启容器，容器组保持 `running`
    * 从不：容器组变为 `failed`
-* 容器组状态 `running`，有2容器，有1容器异常退出
+* 容器组状态 `running`，有 2 容器，有 1 容器异常退出
  * 记录失败事件
  * 如果重启策略为：
    * 始终：重启容器，容器组保持 `running`
    * 失败时：重启容器，容器组保持 `running`
    * 从不：容器组保持 `running`
-  * 当有2容器退出
+  * 当有 2 容器退出
    * 记录失败事件
    * 如果重启策略为：
      * 始终：重启容器，容器组保持 `running`
@@ -181,25 +181,25 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接

 ### Replication Controllers

-> 注：Replication Controller（RC）是早期的控制器类型，现代 Kubernetes 更推荐使用 ReplicaSet/Deployment。
+> 注：Replication Controller (RC) 是早期的控制器类型，现代 Kubernetes 更推荐使用 ReplicaSet/Deployment。

 ### 服务

-> 注：服务（Service）定义一组 Pod 的逻辑集合和访问它们的策略。
+> 注：服务 (Service) 定义一组 Pod 的逻辑集合和访问它们的策略。

 ### 卷

-> 注：卷（Volume）包含可被 Pod 中容器访问的数据的目录。
+> 注：卷 (Volume) 包含可被 Pod 中容器访问的数据的目录。

 ### 标签

-> 注：标签（Label）是附加到对象（如 Pods）上的键值对，用于组织和选择对象子集。
+> 注：标签 (Label) 是附加到对象 (如 Pods) 上的键值对，用于组织和选择对象子集。

 ### 接口权限

 > 注：接口权限通过认证、授权和准入控制来保护 Kubernetes API 的访问。

-### web界面
+### web 界面

 > 注：Kubernetes Dashboard 是一个基于 Web 的用户界面，用于管理集群。

--- a/12_orchestration/kubernetes/design.md
+++ b/12_orchestration/kubernetes/design.md
@@ -19,7 +19,7 @@

 图 12-3 Kubernetes 运行原理图

-可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（Master Node）；一类是属于运行平面的工作节点（Worker Node）。
+可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点 (Master Node)；一类是属于运行平面的工作节点 (Worker Node)。

 显然，复杂的工作肯定都交给控制节点去做了，工作节点负责提供稳定的操作接口和能力抽象即可。

@@ -27,7 +27,7 @@

 ### 控制平面

-控制平面（Control Plane）是 Kubernetes 集群的大脑，负责做出全局决策（如调度）以及检测和响应集群事件。
+控制平面 (Control Plane) 是 Kubernetes 集群的大脑，负责做出全局决策 (如调度) 以及检测和响应集群事件。

 #### 主节点服务

@@ -35,7 +35,7 @@

 * `apiserver` 是整个系统的对外接口，提供一套 RESTful 的 [Kubernetes API](https://kubernetes.io/zh/docs/concepts/overview/kubernetes-api/)，供客户端和其它组件调用；
 * `scheduler` 负责对资源进行调度，分配某个 pod 到某个节点上。是 pluggable 的，意味着很容易选择其它实现方式；
-* `controller-manager` 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。
+* `controller-manager` 负责管理控制器，包括 endpoint-controller (刷新服务和 pod 的关联信息) 和 replication-controller (维护某个 pod 的复制为配置的数值)。

 #### Etcd

@@ -48,7 +48,7 @@
 ### 工作节点

 * kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
-* kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（同一类标签）。
+* kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod (同一类标签)。

 ![Proxy 代理对服务的请求](./_images/kube-proxy.png)

--- a/12_orchestration/kubernetes/intro.md
+++ b/12_orchestration/kubernetes/intro.md
@@ -8,11 +8,11 @@

 ### 什么是 Kubernetes

-Kubernetes（常简称为 K8s）是 Google 开源的容器编排引擎。如果说 Docker 解决了"如何打包和运送集装箱"的问题，那么 Kubernetes 解决的就是"如何管理海量集装箱的调度、运行和维护"的问题。
+Kubernetes (常简称为 K8s) 是 Google 开源的容器编排引擎。如果说 Docker 解决了 “如何打包和运送集装箱” 的问题，那么 Kubernetes 解决的就是 “如何管理海量集装箱的调度、运行和维护” 的问题。

 它不仅仅是一个编排系统，更是一个**云原生应用操作系统**。

-> **名字由来**：Kubernetes 在希腊语中意为"舵手"或"飞行员"。K8s 是因为 k 和 s 之间有 8 个字母。
+> **名字由来**：Kubernetes 在希腊语中意为 “舵手” 或 “飞行员”。K8s 是因为 k 和 s 之间有 8 个字母。

 ---

@@ -32,23 +32,25 @@ Kubernetes 完美解决了这些问题。

 ### 核心概念

-#### Pod（豆荚）
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：

-Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密协作的容器（共享网络和存储）。就像豌豆荚里的豌豆一样。
+#### Pod (豆荚)

-#### Node（节点）
+Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密协作的容器 (共享网络和存储)。就像豌豆荚里的豌豆一样。
+
+#### Node (节点)

 运行 Pod 的物理机或虚拟机。

-#### Deployment（部署）
+#### Deployment (部署)

-定义应用的期望状态（如：需要 3 个副本，镜像版本为 v1）。K8s 会持续确保当前状态符合期望状态。
+定义应用的期望状态 (如：需要 3 个副本，镜像版本为 v1)。K8s 会持续确保当前状态符合期望状态。

-#### Service（服务）
+#### Service (服务)

 定义一组 Pod 的访问策略。提供稳定的 Cluster IP 和 DNS 名称，负责负载均衡。

-#### Namespace（命名空间）
+#### Namespace (命名空间)

 用于多租户资源隔离。

@@ -69,17 +71,17 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密

 ### 架构

-Kubernetes 也是 C/S 架构，由 **Control Plane（控制平面）**和**Worker Node（工作节点）** 组成：
+Kubernetes 也是 C/S 架构，由 **Control Plane (控制平面) **和** Worker Node (工作节点)** 组成：

- **Control Plane**：负责决策（API Server, Scheduler, Controller Manager, etcd）
- **Worker Node**：负责干活（Kubelet, Kube-proxy, Container Runtime）
+- **Control Plane**：负责决策 (API Server，Scheduler，Controller Manager，etcd)
+- **Worker Node**：负责干活 (Kubelet，Kube-proxy，Container Runtime)

 ---

 ### 学习建议

 Kubernetes 的学习曲线较陡峭。建议的学习路径：
-1. **理解基本概念**：Pod, Deployment, Service
+1. **理解基本概念**：Pod，Deployment，Service
 2. **动手实践**：使用 Minikube 或 Kind 在本地搭建集群
 3. **部署应用**：编写 YAML 部署一个无状态应用
 4. **深入原理**：网络模型、存储机制、调度算法
--- a/12_orchestration/kubernetes/practice.md
+++ b/12_orchestration/kubernetes/practice.md
@@ -6,7 +6,7 @@

 1.  部署一个 Nginx Deployment。
 2.  创建一个 Service 暴露 Nginx。
-3.  （可选）通过 Ingress 访问服务。
+3.  (可选) 通过 Ingress 访问服务。

 ### 步骤 1：创建 Deployment

@@ -75,7 +75,7 @@ kubectl get svc nginx-service

 如果输出端口是 `80:30080/TCP`，你可以通过 `http://<NodeIP>:30080` 访问 Nginx。

-### 步骤 3：模拟滚动更新（Rolling Update）
+### 步骤 3：模拟滚动更新

 修改 `nginx-deployment.yaml`，将镜像版本改为 `nginx:1.27-alpine`。