Optimize content and fix issues

2026-03-11 12:21:17 +00:00 · 2026-03-03 19:30:03 -08:00
parent be09a95d0d
commit a096947382
18 changed files with 239 additions and 506 deletions
--- a/13_kubernetes_concepts/13.2_concepts.md
+++ b/13_kubernetes_concepts/13.2_concepts.md
@@ -1,10 +1,10 @@
 ## 13.2 基本概念

-如图 12-2 所示，Kubernetes 由控制平面与工作节点构成。
+如图 13-2 所示，Kubernetes 由控制平面与工作节点构成。

 ![Kubernetes 基本概念示意图](./_images/kubernetes_design.jpg)

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

 * 节点 (`Node`)：一个节点是一个运行 Kubernetes 中的主机。
 * 容器组 (`Pod`)：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷 (volume)。
@@ -39,41 +39,56 @@

 #### 节点管理

-节点并非 Kubernetes 创建，而是由云平台创建，或者就是物理机器、虚拟机。在 Kubernetes 中，节点仅仅是一条记录，节点创建之后，Kubernetes 会检查其是否可用。在 Kubernetes 中，节点用如下结构保存：
+节点并非 Kubernetes 创建，而是由云平台创建，或者就是物理机器、虚拟机。在 Kubernetes 中，节点仅仅是一条记录，节点创建之后，Kubernetes 会检查其是否可用。可以通过 `kubectl` 查看节点信息：

-```json
-{
-  "id": "10.1.2.3",
-  "kind": "Minion",
-  "apiVersion": "v1beta1",
-  "resources": {
-    "capacity": {
-      "cpu": 1000,
-      "memory": 1073741824
-    },
-  },
-  "labels": {
-    "name": "my-first-k8s-node",
-  },
-}
+```bash
+$ kubectl get nodes
+NAME           STATUS   ROLES           AGE   VERSION
+control-plane  Ready    control-plane   10d   v1.30.2
+worker-1       Ready    <none>          10d   v1.30.2
+worker-2       Ready    <none>          10d   v1.30.2
 ```

-Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接口可以用来管理节点：节点控制和 Kube 管理。
+每个节点的详细信息以如下结构保存：

-#### 节点控制
+```yaml
+apiVersion: v1
+kind: Node
+metadata:
+  name: worker-1
+  labels:
+    kubernetes.io/os: linux
+status:
+  capacity:
+    cpu: "4"
+    memory: 8Gi
+  conditions:
+    - type: Ready
+      status: "True"
+```

-在 Kubernetes 主节点中，节点控制器是用来管理节点的组件。主要包含：
+#### 节点控制器

-* 集群范围内节点同步
+在 Kubernetes 控制平面中，节点控制器 (Node Controller) 负责管理节点的生命周期，主要包含：
+
+* 集群范围内节点状态同步
 * 单节点生命周期管理

-节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period` 标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines` 标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false` 标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。
+节点控制器会持续监控节点的健康状态。当节点变为不可达时，控制器会等待一个超时期限，然后将该节点上的 Pod 标记为失败，并触发重新调度。可以使用 `kubectl` 来管理节点，例如标记节点为不可调度或排空节点上的工作负载：
+
+```bash
+## 标记节点为不可调度
+$ kubectl cordon worker-1
+
+## 排空节点上的 Pod
+$ kubectl drain worker-1 --ignore-daemonsets
+```

 ### 13.2.2 容器组

-在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。一个容器组使用相同的 Docker 容器并共享卷 (挂载点)。一个容器组是一个特定应用的打包集合，包含一个或多个容器。
+在 Kubernetes 中，使用的最小调度单位是容器组 (Pod)，它是创建、调度、管理的最小单位。一个 Pod 包含一个或多个紧密协作的容器，它们共享网络命名空间和存储卷。

-和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，直到容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。(也许在将来的版本中会添加容器组的移动)。
+Pod 通常不会被直接创建，而是通过 Deployment 等控制器来管理。当节点发生故障时，控制器会在其他可用节点上重新创建 Pod。

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

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

 #### 容器组的使用

-容器组可以通过组合来构建复杂的应用，其本来的意义包含：
+容器组可以通过组合来构建复杂的应用，典型的使用模式包含：

 * 内容管理，文件和数据加载以及本地缓存管理等。
 * 日志和检查点备份，压缩，快照等。
@@ -101,108 +116,154 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
 * 代理，网桥
 * 控制器，管理，配置以及更新

-#### 替代方案
+#### 为什么不在一个容器里运行多个程序

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

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

-包括若干状态值：`pending`、`running`、`succeeded`、`failed`。
+包括若干状态值：`Pending`、`Running`、`Succeeded`、`Failed`。

-##### pending
+| 状态 | 说明 |
+|------|------|
+| **Pending** | Pod 已被集群接受，但有一个或多个容器还没有运行起来（可能在拉取镜像）。|
+| **Running** | Pod 已被调度到节点，并且所有容器都已启动。至少有一个容器处于运行状态。|
+| **Succeeded** | Pod 中的所有容器都正常退出，且不会被重启。|
+| **Failed** | Pod 中的所有容器都已终止，且至少有一个容器以失败状态退出。|

-容器组已经被节点接受，但有一个或多个容器还没有运行起来。这将包含某些节点正在下载镜像的时间，这种情形会依赖于网络情况。
+#### 容器组生命周期与重启策略

-##### running
+Pod 的重启策略 (`restartPolicy`) 决定了容器退出后的行为：

-容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态 (或者处于重启状态)。
+| 重启策略 | 容器正常退出 | 容器异常退出 |
+|---------|------------|------------|
+| **Always** (默认) | 重启容器 | 重启容器 |
+| **OnFailure** | 不重启 | 重启容器 |
+| **Never** | 不重启 | 不重启 |

-##### succeeded
+当节点故障或不可达时，节点控制器会将该节点上所有 Pod 的状态标记为 `Failed`。如果这些 Pod 由 Deployment 等控制器管理，控制器会自动在其他节点上重新创建。

-所有的容器都正常退出。
+### 13.2.3 Deployment 与 ReplicaSet

-##### failed
+Deployment 是管理无状态应用的推荐方式，它通过 ReplicaSet 来确保指定数量的 Pod 副本始终在运行。

-容器组中所有容器都意外中断了。
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+        - name: nginx
+          image: nginx:1.27
+          ports:
+            - containerPort: 80
+```

-#### 容器组生命周期
+Deployment 的核心能力包括：

-通常来说，如果容器组被创建了就不会自动销毁，除非被某种行为触发，而触发此种情况可能是人为，或者复制控制器所为。唯一例外的是容器组由 succeeded 状态成功退出，或者在一定时间内重试多次依然失败。
+* **副本管理**：确保始终有指定数量的 Pod 在运行
+* **滚动更新**：逐步替换旧版本 Pod，实现零停机部署
+* **回滚**：如果新版本出现问题，可以快速回滚到之前的版本

-如果某个节点死掉或者不能连接，那么节点控制器将会标记其上的容器组的状态为 `failed`。
-
-举例如下。
-
-* 容器组状态 `running`，有 1 容器，容器正常退出
-  * 记录完成事件
-  * 如果重启策略为：
-    * 始终：重启容器，容器组保持 `running`
-    * 失败时：容器组变为 `succeeded`
-    * 从不：容器组变为 `succeeded`
-* 容器组状态 `running`，有 1 容器，容器异常退出
-  * 记录失败事件
-  * 如果重启策略为：
-    * 始终：重启容器，容器组保持 `running`
-    * 失败时：重启容器，容器组保持 `running`
-    * 从不：容器组变为 `failed`
-* 容器组状态 `running`，有 2 容器，有 1 容器异常退出
-  * 记录失败事件
-  * 如果重启策略为：
-    * 始终：重启容器，容器组保持 `running`
-    * 失败时：重启容器，容器组保持 `running`
-    * 从不：容器组保持 `running`
-  * 当有 2 容器退出
-    * 记录失败事件
-    * 如果重启策略为：
-      * 始终：重启容器，容器组保持 `running`
-      * 失败时：重启容器，容器组保持 `running`
-      * 从不：容器组变为 `failed`
-* 容器组状态 `running`，容器内存不足
-  * 标记容器错误中断
-  * 记录内存不足事件
-  * 如果重启策略为：
-    * 始终：重启容器，容器组保持 `running`
-    * 失败时：重启容器，容器组保持 `running`
-    * 从不：记录错误事件，容器组变为 `failed`
-* 容器组状态 `running`，一块磁盘死掉
-  * 杀死所有容器
-  * 记录事件
-  * 容器组变为 `failed`
-  * 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
-* 容器组状态 `running`，对应的节点段溢出
-  * 节点控制器等到超时
-  * 节点控制器标记容器组 `failed`
-  * 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
-
-### 13.2.3 Replication Controllers
-
-> 注：Replication Controller (RC) 是早期的控制器类型，现代 Kubernetes 更推荐使用 ReplicaSet/Deployment。
+> 早期 Kubernetes 使用 Replication Controller (RC) 来管理副本，现已被 ReplicaSet/Deployment 取代。

 ### 13.2.4 服务

-> 注：服务 (Service) 定义一组 Pod 的逻辑集合和访问它们的策略。
+服务 (Service) 定义了一组 Pod 的逻辑集合和访问策略。由于 Pod 的 IP 地址是动态分配的，Service 提供了一个稳定的访问入口。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-service
+spec:
+  selector:
+    app: nginx
+  ports:
+    - port: 80
+      targetPort: 80
+  type: ClusterIP
+```
+
+常见的 Service 类型：
+
+| 类型 | 说明 |
+|------|------|
+| **ClusterIP** | 默认类型，仅集群内部可访问 |
+| **NodePort** | 在每个节点上开放固定端口，集群外部可通过 `节点IP:端口` 访问 |
+| **LoadBalancer** | 通过云平台的负载均衡器暴露服务 |

 ### 13.2.5 卷

-> 注：卷 (Volume) 包含可被 Pod 中容器访问的数据的目录。
+卷 (Volume) 为 Pod 中的容器提供持久化存储。Kubernetes 支持多种卷类型：
+
+| 卷类型 | 说明 |
+|-------|------|
+| **emptyDir** | 临时存储，Pod 删除后数据丢失 |
+| **hostPath** | 挂载节点上的文件或目录 |
+| **PersistentVolumeClaim** | 使用持久卷声明，与底层存储解耦 |
+| **configMap / secret** | 将配置或敏感数据挂载为文件 |
+
+生产环境中，推荐使用 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 来管理存储，实现存储资源与使用者的解耦。

 ### 13.2.6 标签

-> 注：标签 (Label) 是附加到对象 (如 Pods) 上的键值对，用于组织和选择对象子集。
+标签 (Label) 是附加到 Kubernetes 对象上的键值对，用于组织和选择对象子集。标签是 Kubernetes 中实现松耦合的关键机制。

-### 13.2.7 接口权限
+```bash
+## 为 Pod 添加标签
+$ kubectl label pod my-pod env=production

-> 注：接口权限通过认证、授权和准入控制来保护 Kubernetes API 的访问。
+## 通过标签选择器查询
+$ kubectl get pods -l env=production
+```

-### 13.2.8 web 界面
+Service、Deployment 等资源都通过标签选择器 (`selector`) 来关联目标 Pod。

-> 注：Kubernetes Dashboard 是一个基于 Web 的用户界面，用于管理集群。
+### 13.2.7 API 访问控制

-### 13.2.9 命令行操作
+Kubernetes API 的访问通过三个阶段进行控制：

-> 注：kubectl 是 Kubernetes 的命令行工具，用于与集群进行交互。
+1. **认证 (Authentication)**：验证请求者的身份（如证书、Token、OIDC）
+2. **授权 (Authorization)**：判断请求者是否有权限执行操作（通常使用 RBAC）
+3. **准入控制 (Admission Control)**：在请求被持久化之前对其进行校验或修改
+
+### 13.2.8 Dashboard
+
+Kubernetes Dashboard 是一个基于 Web 的用户界面，用于部署容器化应用、监控集群资源和排查问题。Dashboard 的部署方法详见[部署 Dashboard](../14_kubernetes_setup/14.7_dashboard.md) 章节。
+
+### 13.2.9 命令行工具 kubectl
+
+`kubectl` 是 Kubernetes 的命令行工具，用于与集群进行交互。常用命令如下：
+
+```bash
+## 查看集群中的资源
+$ kubectl get pods,deployments,services,nodes
+
+## 创建资源
+$ kubectl apply -f deployment.yaml
+
+## 查看 Pod 日志
+$ kubectl logs my-pod
+
+## 进入 Pod 执行命令
+$ kubectl exec -it my-pod -- /bin/sh
+
+## 查看资源详情
+$ kubectl describe pod my-pod
+```
+
+更多 kubectl 操作详见[kubectl 命令行](../14_kubernetes_setup/14.8_kubectl.md)章节。
--- a/13_kubernetes_concepts/13.3_design.md
+++ b/13_kubernetes_concepts/13.3_design.md
@@ -13,11 +13,11 @@

 ### 13.3.2 运行原理

-如图 12-3 所示，该图完整展示了 Kubernetes 的运行原理。
+如图 13-3 所示，该图完整展示了 Kubernetes 的运行原理。

 ![Kubernetes 架构](./_images/k8s_architecture.png)

-图 12-3 Kubernetes 运行原理图
+图 13-3 Kubernetes 运行原理图

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

@@ -52,4 +52,4 @@

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

-图 12-4 kube-proxy 请求转发示意图
+图 13-4 kube-proxy 请求转发示意图
--- a/13_kubernetes_concepts/README.md
+++ b/13_kubernetes_concepts/README.md
@@ -6,10 +6,10 @@

 Kubernetes 的最小调度单位是 `Pod`。一个 `Pod` 由一组紧密协作的容器构成，它们共享网络命名空间、IP 以及部分存储资源，也可以根据需要对 Pod 进行端口映射。

-本章将分为 5 节介绍 `Kubernetes`，包括
+本章将分为 5 节介绍 `Kubernetes`：

-* 项目简介
-* 快速入门
-* 基本概念
-* 实践例子
-* 架构分析等高级话题
+* [简介](13.1_intro.md)
+* [基本概念](13.2_concepts.md)
+* [架构设计](13.3_design.md)
+* [高级特性](13.4_advanced.md)
+* [实战练习](13.5_practice.md)