ehlxr/docker_practice
1
0
Fork 0
mirror of https://github.com/yeasy/docker_practice.git synced 2026-03-11 04:14:38 +00:00
Code Issues Projects Releases Wiki Activity

Optimize content and fix issues

Browse Source
This commit is contained in:
baohua
2026-03-03 19:30:03 -08:00
parent be09a95d0d
commit a096947382
18 changed files with 239 additions and 506 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
01_introduction/1.3_why.md
View File

@@ -200,13 +200,7 @@ flowchart TD
### 1.3.5 与传统虚拟机的对比总结 ### 1.3.5 与传统虚拟机的对比总结
下表对比了容器技术与传统虚拟机的区别： 关于容器与虚拟机的详细特性对比，请参阅 [1.2.3 Docker vs 虚拟机](1.2_what.md) 中的对比表。总结来说：
| 特性 | Docker 容器 | 传统虚拟机 | - **性能差异**：虚拟机通常有 5-20% 的性能损耗，而容器接近原生性能。
|:------|:-----------|:-----------| - **最佳场景**：Docker 容器适合微服务、CI/CD、开发环境；虚拟机适合多租户、高安全需求场景。
| 启动速度 | 秒级 | 分钟级 |
| 磁盘占用 | MB 级别 | GB 级别 |
| 性能 | 接近原生 | 有 5-20% 损耗 |
| 单机支持量 | 上千个容器 | 几十个虚拟机 |
| 隔离性 | 进程级别 | 完全隔离 |
| 最佳场景 | 微服务、CI/CD、开发环境 | 多租户、高安全需求 |

7
06_repository/README.md
View File

@@ -5,3 +5,10 @@
一个容易混淆的概念是注册服务器 (`Registry`)。实际上注册服务器是管理仓库的具体服务器，每个服务器上可以有多个仓库，而每个仓库下面有多个镜像。从这方面来说，仓库可以被认为是一个具体的项目或目录。例如对于仓库地址 `docker.io/ubuntu` 来说，`docker.io` 是注册服务器地址，`ubuntu` 是仓库名。 一个容易混淆的概念是注册服务器 (`Registry`)。实际上注册服务器是管理仓库的具体服务器，每个服务器上可以有多个仓库，而每个仓库下面有多个镜像。从这方面来说，仓库可以被认为是一个具体的项目或目录。例如对于仓库地址 `docker.io/ubuntu` 来说，`docker.io` 是注册服务器地址，`ubuntu` 是仓库名。
大部分时候，并不需要严格区分这两者的概念。 大部分时候，并不需要严格区分这两者的概念。
## 本章内容
* [Docker Hub](6.1_dockerhub.md)
* [私有仓库](6.2_registry.md)
* [私有仓库高级配置](6.3_registry_auth.md)
* [Nexus 3](6.4_nexus3_registry.md)

4
07_dockerfile/README.md
View File

@@ -2,7 +2,7 @@
## 什么是 Dockerfile ## 什么是 Dockerfile
Dockerfile 是一个文本文件，其內包含了一条条的 **指令 (Instruction)**，每一条指令构建一层，therefore 每一条指令的内容，就是描述该层应当如何构建。 Dockerfile 是一个文本文件，其内包含了一条条的 **指令 (Instruction)**，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。
在[第四章](../04_image/README.md)中，我们通过 `docker commit` 学习了镜像的构成。但是，手动 `commit` 只能作为临时修补，并不适合作为生产环境镜像的构建方式。 在[第四章](../04_image/README.md)中，我们通过 `docker commit` 学习了镜像的构成。但是，手动 `commit` 只能作为临时修补，并不适合作为生产环境镜像的构建方式。
@@ -21,6 +21,7 @@ Dockerfile 一般分为四部分：基础镜像信息、维护者信息、镜像
本章将详细讲解 Dockerfile 中的各个指令： 本章将详细讲解 Dockerfile 中的各个指令：
* [RUN 执行命令](7.1_run.md)
* [COPY 复制文件](7.2_copy.md) * [COPY 复制文件](7.2_copy.md)
* [ADD 更高级的复制文件](7.3_add.md) * [ADD 更高级的复制文件](7.3_add.md)
* [CMD 容器启动命令](7.4_cmd.md) * [CMD 容器启动命令](7.4_cmd.md)
@@ -35,7 +36,6 @@ Dockerfile 一般分为四部分：基础镜像信息、维护者信息、镜像
* [ONBUILD 为他人作嫁衣裳](7.13_onbuild.md) * [ONBUILD 为他人作嫁衣裳](7.13_onbuild.md)
* [LABEL 为镜像添加元数据](7.14_label.md) * [LABEL 为镜像添加元数据](7.14_label.md)
* [SHELL 指令](7.15_shell.md) * [SHELL 指令](7.15_shell.md)
* [RUN 执行命令](7.1_run.md)
此外，我们还将介绍 Dockerfile 的最佳实践和常见问题。 此外，我们还将介绍 Dockerfile 的最佳实践和常见问题。

3
08_data/README.md
View File

@@ -6,7 +6,8 @@
图 8-1 Docker 数据挂载类型示意图 图 8-1 Docker 数据挂载类型示意图
这一章介绍如何在 Docker 内部以及容器之间管理数据，在容器中管理数据主要有两种方式： 这一章介绍如何在 Docker 内部以及容器之间管理数据，在容器中管理数据主要有以下几种方式：
* [数据卷](8.1_volume.md) * [数据卷](8.1_volume.md)
* [挂载主机目录](8.2_bind-mounts.md) * [挂载主机目录](8.2_bind-mounts.md)
* [tmpfs 挂载](8.3_tmpfs.md)

2
09_network/README.md
View File

@@ -34,8 +34,8 @@ graph TD
## 本章内容 ## 本章内容
* [配置 DNS](9.1_dns.md) * [配置 DNS](9.1_dns.md)
* [外部访问容器](9.5_port_mapping.md)
* [网络类型](9.2_network_types.md) * [网络类型](9.2_network_types.md)
* [自定义网络](9.3_custom_network.md) * [自定义网络](9.3_custom_network.md)
* [容器互联](9.4_container_linking.md) * [容器互联](9.4_container_linking.md)
* [外部访问容器](9.5_port_mapping.md)
* [网络隔离](9.6_network_isolation.md) * [网络隔离](9.6_network_isolation.md)

4
11_compose/11.5_compose_file.md
View File

@@ -399,8 +399,8 @@ mysql:
- my_other_secret - my_other_secret
secrets: secrets:
my_secret: db_root_password:
file: ./my_secret.txt file: ./db_root_password.txt
my_other_secret: my_other_secret:
external: true external: true
``` ```

2
12_implementation/README.md
View File

@@ -12,6 +12,8 @@ Docker 底层的核心技术包括 Linux 上的命名空间 (Namespaces)、控
随着 Linux 系统对于命名空间功能的完善实现，程序员已经可以实现上面的所有需求，让某些进程在彼此隔离的命名空间中运行。大家虽然都共用一个内核和某些运行时环境 (例如一些系统命令和系统库)，但是彼此却看不到，都以为系统中只有自己的存在。这种机制就是容器 (Container)，利用命名空间来做权限的隔离控制，利用 cgroups 来做资源分配。 随着 Linux 系统对于命名空间功能的完善实现，程序员已经可以实现上面的所有需求，让某些进程在彼此隔离的命名空间中运行。大家虽然都共用一个内核和某些运行时环境 (例如一些系统命令和系统库)，但是彼此却看不到，都以为系统中只有自己的存在。这种机制就是容器 (Container)，利用命名空间来做权限的隔离控制，利用 cgroups 来做资源分配。
## 本章内容
* [基本架构](12.1_arch.md) * [基本架构](12.1_arch.md)
* [命名空间](12.2_namespace.md) * [命名空间](12.2_namespace.md)
* [控制组](12.3_cgroups.md) * [控制组](12.3_cgroups.md)

263
13_kubernetes_concepts/13.2_concepts.md
View File

@@ -1,10 +1,10 @@
## 13.2 基本概念 ## 13.2 基本概念
如图 12-2 所示，Kubernetes 由控制平面与工作节点构成。 如图 13-2 所示，Kubernetes 由控制平面与工作节点构成。
![Kubernetes 基本概念示意图](./_images/kubernetes_design.jpg) ![Kubernetes 基本概念示意图](./_images/kubernetes_design.jpg)
图 12-2 Kubernetes 基本概念示意图 图 13-2 Kubernetes 基本概念示意图
* 节点 (`Node`)：一个节点是一个运行 Kubernetes 中的主机。 * 节点 (`Node`)：一个节点是一个运行 Kubernetes 中的主机。
* 容器组 (`Pod`)：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷 (volume)。 * 容器组 (`Pod`)：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷 (volume)。
@@ -39,41 +39,56 @@
#### 节点管理 #### 节点管理
节点并非 Kubernetes 创建，而是由云平台创建，或者就是物理机器、虚拟机。在 Kubernetes 中，节点仅仅是一条记录，节点创建之后，Kubernetes 会检查其是否可用。在 Kubernetes 中，节点用如下结构保存： 节点并非 Kubernetes 创建，而是由云平台创建，或者就是物理机器、虚拟机。在 Kubernetes 中，节点仅仅是一条记录，节点创建之后，Kubernetes 会检查其是否可用。可以通过 `kubectl` 查看节点信息：
```json ```bash
{ $ kubectl get nodes
"id": "10.1.2.3", NAME STATUS ROLES AGE VERSION
"kind": "Minion", control-plane Ready control-plane 10d v1.30.2
"apiVersion": "v1beta1", worker-1 Ready <none> 10d v1.30.2
"resources": { worker-2 Ready <none> 10d v1.30.2
"capacity": {
"cpu": 1000,
"memory": 1073741824
},
},
"labels": {
"name": "my-first-k8s-node",
},
}
``` ```
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 容器组 ### 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. **解耦依赖**：每个容器都可能独立地重新构建和发布。
* 1. 透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。 3. **方便使用**：用户不必运行独立的程序管理，也不用担心每个应用程序的退出状态。
* 2. 解耦软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes 必须支持热发布和热更新 (将来)。 4. **高效**：考虑到基础设施有更多的职责，容器必须要轻量化。
* 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`。 > 早期 Kubernetes 使用 Replication Controller (RC) 来管理副本，现已被 ReplicaSet/Deployment 取代。
举例如下。
* 容器组状态 `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。
### 13.2.4 服务 ### 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 卷 ### 13.2.5 卷
> 注：卷 (Volume) 包含可被 Pod 中容器访问的数据的目录。 卷 (Volume) 为 Pod 中的容器提供持久化存储。Kubernetes 支持多种卷类型：
| 卷类型 | 说明 |
|-------|------|
| **emptyDir** | 临时存储，Pod 删除后数据丢失 |
| **hostPath** | 挂载节点上的文件或目录 |
| **PersistentVolumeClaim** | 使用持久卷声明，与底层存储解耦 |
| **configMap / secret** | 将配置或敏感数据挂载为文件 |
生产环境中，推荐使用 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 来管理存储，实现存储资源与使用者的解耦。
### 13.2.6 标签 ### 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)章节。

6
13_kubernetes_concepts/13.3_design.md
View File

@@ -13,11 +13,11 @@
### 13.3.2 运行原理 ### 13.3.2 运行原理
如图 12-3 所示，该图完整展示了 Kubernetes 的运行原理。 如图 13-3 所示，该图完整展示了 Kubernetes 的运行原理。
![Kubernetes 架构](./_images/k8s_architecture.png) ![Kubernetes 架构](./_images/k8s_architecture.png)
图 12-3 Kubernetes 运行原理图 图 13-3 Kubernetes 运行原理图
可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点 (Master Node)；一类是属于运行平面的工作节点 (Worker Node)。 可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点 (Master Node)；一类是属于运行平面的工作节点 (Worker Node)。
@@ -52,4 +52,4 @@
![Proxy 代理对服务的请求](./_images/kube-proxy.png) ![Proxy 代理对服务的请求](./_images/kube-proxy.png)
图 12-4 kube-proxy 请求转发示意图 图 13-4 kube-proxy 请求转发示意图

12
13_kubernetes_concepts/README.md
View File

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

15
14_kubernetes_setup/README.md
View File

@@ -2,10 +2,13 @@
目前，Kubernetes 支持在多种环境下使用，包括本地主机 (Ubuntu、Debian、CentOS、Fedora 等)、云服务 ([腾讯云](https://cloud.tencent.com/act/cps/redirect?redirect=10058&cps_key=3a5255852d5db99dcd5da4c72f05df61)、[阿里云](https://www.aliyun.com/product/kubernetes?source=5176.11533457&userCode=8lx5zmtu&type=copy)、[百度云](https://cloud.baidu.com/product/cce.html)等)。 目前，Kubernetes 支持在多种环境下使用，包括本地主机 (Ubuntu、Debian、CentOS、Fedora 等)、云服务 ([腾讯云](https://cloud.tencent.com/act/cps/redirect?redirect=10058&cps_key=3a5255852d5db99dcd5da4c72f05df61)、[阿里云](https://www.aliyun.com/product/kubernetes?source=5176.11533457&userCode=8lx5zmtu&type=copy)、[百度云](https://cloud.baidu.com/product/cce.html)等)。
你可以使用以下几种方式部署 Kubernetes： 你可以使用以下几种方式部署 Kubernetes，接下来的小节会对各种方式进行详细介绍。
* kubeadm * [使用 kubeadm 部署 (CRI 使用 containerd)](14.1_kubeadm.md)
* docker-desktop * [使用 kubeadm 部署 (使用 Docker)](14.2_kubeadm-docker.md)
* k3s * [在 Docker Desktop 使用](14.3_docker-desktop.md)
* [Kind - Kubernetes IN Docker](14.4_kind.md)
接下来的小节会对以上几种方式进行详细介绍。 * [K3s - 轻量级 Kubernetes](14.5_k3s.md)
* [一步步部署 Kubernetes 集群](14.6_systemd.md)
* [部署 Dashboard](14.7_dashboard.md)
* [Kubernetes 命令行 kubectl](14.8_kubectl.md)

7
15_etcd/README.md
View File

@@ -1,3 +1,10 @@
# 第十五章 Etcd 项目 # 第十五章 Etcd 项目
`etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.x` 版本介绍该项目的目标，安装和使用，以及实现的技术。 `etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.x` 版本介绍该项目的目标，安装和使用，以及实现的技术。
## 本章内容
* [简介](15.1_intro.md)
* [安装](15.2_install.md)
* [集群](15.3_cluster.md)
* [使用 etcdctl](15.4_etcdctl.md)

8
16_cloud/README.md
View File

@@ -3,3 +3,11 @@
Docker 目前已经得到了众多公有云平台的支持，并成为除虚拟机之外的核心云业务。 Docker 目前已经得到了众多公有云平台的支持，并成为除虚拟机之外的核心云业务。
除了 AWS、Google、Azure 等，国内的各大公有云厂商，基本上都同时支持了虚拟机服务和基于 Kubernetes 的容器云业务。有的还推出了其他服务，例如[容器镜像服务](https://cloud.tencent.com/act/cps/redirect?redirect=11588&cps_key=3a5255852d5db99dcd5da4c72f05df61)让用户在云上享有安全高效的镜像托管、分发等服务。 除了 AWS、Google、Azure 等，国内的各大公有云厂商，基本上都同时支持了虚拟机服务和基于 Kubernetes 的容器云业务。有的还推出了其他服务，例如[容器镜像服务](https://cloud.tencent.com/act/cps/redirect?redirect=11588&cps_key=3a5255852d5db99dcd5da4c72f05df61)让用户在云上享有安全高效的镜像托管、分发等服务。
## 本章内容
* [简介](16.1_intro.md)
* [腾讯云](16.2_tencentCloud.md)
* [阿里云](16.3_alicloud.md)
* [亚马逊云](16.4_aws.md)
* [多云部署策略](16.5_multicloud.md)

4
17_ecosystem/17.1_coreos_intro.md
View File

@@ -22,7 +22,3 @@ FCOS 使用 rpm-ostree 系统进行事务性升级。无需像 yum 升级那样
对于诸如构建，复制和其他管理容器的任务，FCOS 用一组容器工具代替了 **Docker CLI**。**podman CLI** 工具支持许多容器运行时功能，例如运行，启动，停止，列出和删除容器和镜像。**skopeo CLI** 工具可以复制，认证和签名镜像。您还可以使用 **crictl CLI** 工具来处理 CRI-O 容器引擎中的容器和镜像。 对于诸如构建，复制和其他管理容器的任务，FCOS 用一组容器工具代替了 **Docker CLI**。**podman CLI** 工具支持许多容器运行时功能，例如运行，启动，停止，列出和删除容器和镜像。**skopeo CLI** 工具可以复制，认证和签名镜像。您还可以使用 **crictl CLI** 工具来处理 CRI-O 容器引擎中的容器和镜像。
### 17.1.2 参考文档
* [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/)
* [openshift 官方文档](https://docs.openshift.com/container-platform/4.3/architecture/architecture-rhcos.html)

4
17_ecosystem/17.2_coreos_install.md
View File

@@ -47,7 +47,3 @@ $ ssh core@虚拟机IP
$ docker --version $ docker --version
``` ```
### 17.2.6 参考链接
* [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/)

27
17_ecosystem/17.3_podman.md
View File

@@ -2,7 +2,7 @@
[`podman`](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发，旨在提供一个更安全的容器运行环境。 [`podman`](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发，旨在提供一个更安全的容器运行环境。
## 17.3 Podman vs Docker ### 17.3.1 Podman vs Docker
Podman 和 Docker 在设计理念上存在显著差异，主要体现在架构和权限模型上。 Podman 和 Docker 在设计理念上存在显著差异，主要体现在架构和权限模型上。
@@ -13,17 +13,17 @@ Podman 和 Docker 在设计理念上存在显著差异，主要体现在架构
| **生态** | 完整的生态系统 (Compose, Swarm) | 专注单机容器，配合 Kubernetes 使用 | | **生态** | 完整的生态系统 (Compose, Swarm) | 专注单机容器，配合 Kubernetes 使用 |
| **镜像构建** | `docker build` | `podman build` 或 `buildah` | | **镜像构建** | `docker build` | `podman build` 或 `buildah` |
## 17.3 安装 ### 17.3.2 安装
Podman 支持多种操作系统，安装过程也相对简单。 Podman 支持多种操作系统，安装过程也相对简单。
### 17.3.1 CentOS / RHEL #### CentOS / RHEL
```bash ```bash
$ sudo yum -y install podman $ sudo yum -y install podman
``` ```
### 17.3.2 macOS #### macOS
macOS 上需要安装 Podman Desktop 或通过 Homebrew 安装： macOS 上需要安装 Podman Desktop 或通过 Homebrew 安装：
@@ -33,11 +33,11 @@ $ podman machine init
$ podman machine start $ podman machine start
``` ```
## 17.3 使用 ### 17.3.3 基本使用
`podman` 的命令行几乎与 `docker` 完全兼容，大多数情况下，你只需将 `docker` 替换为 `podman` 即可。 `podman` 的命令行几乎与 `docker` 完全兼容，大多数情况下，你只需将 `docker` 替换为 `podman` 即可。
### 17.3.1 运行容器 #### 运行容器
```bash ```bash
## $ docker run -d -p 80:80 nginx:alpine ## $ docker run -d -p 80:80 nginx:alpine
@@ -45,19 +45,19 @@ $ podman machine start
$ podman run -d -p 80:80 nginx:alpine $ podman run -d -p 80:80 nginx:alpine
``` ```
### 17.3.2 列出容器 #### 列出容器
```bash ```bash
$ podman ps $ podman ps
``` ```
### 17.3.3 构建镜像 #### 构建镜像
```bash ```bash
$ podman build -t myimage . $ podman build -t myimage .
``` ```
## 17.3 Pods 的概念 ### 17.3.4 Pods 的概念
与 Docker 不同，Podman 支持“Pod”的概念 (类似于 Kubernetes 的 Pod)，允许你在同一个网络命名空间中运行多个容器。 与 Docker 不同，Podman 支持“Pod”的概念 (类似于 Kubernetes 的 Pod)，允许你在同一个网络命名空间中运行多个容器。
@@ -71,7 +71,7 @@ $ podman pod create --name mypod -p 8080:80
$ podman run -d --pod mypod --name webbing nginx $ podman run -d --pod mypod --name webbing nginx
``` ```
## 17.3 迁移到 Podman ### 17.3.5 迁移到 Podman
如果你习惯使用 `docker` 命令，可以简单地设置别名： 如果你习惯使用 `docker` 命令，可以简单地设置别名：
@@ -79,8 +79,6 @@ $ podman run -d --pod mypod --name webbing nginx
$ alias docker=podman $ alias docker=podman
``` ```
### 17.3.1 进阶用法
#### Systemd 集成 #### Systemd 集成
Podman 可以生成 systemd 单元文件，让容器像普通系统服务一样管理。 Podman 可以生成 systemd 单元文件，让容器像普通系统服务一样管理。
@@ -107,8 +105,3 @@ $ systemctl --user enable --now container-myweb.service
$ pip3 install podman-compose $ pip3 install podman-compose
$ podman-compose up -d $ podman-compose up -d
``` ```
### 17.3.2 参考
* [Podman 官方网站](https://podman.io/)
* [Podman GitHub 仓库](https://github.com/containers/podman)

359
18_security/README.md
View File

@@ -24,273 +24,24 @@ flowchart LR
end end
``` ```
--- ## 本章内容
## 核心安全机制 本章涵盖 Docker 安全的多个层面，从内核隔离机制到运行时防护和供应链安全。
### 1. 命名空间 * [内核命名空间](18.1_kernel_ns.md)
* 命名空间的安全意义、User Namespace 与提权防护。
提供进程、网络、文件系统等资源的隔离： * [控制组](18.2_control_group.md)
* 通过 Cgroups 限制容器资源使用，防止资源耗尽攻击。
| Namespace | 隔离内容 | 安全作用 | * [服务端防护](18.3_daemon_sec.md)
|-----------|---------|---------| * Docker 守护进程的安全配置与网络访问控制。
| PID | 进程 | 容器看不到其他进程 |
| NET | 网络 | 独立网络栈 |
| MNT | 文件系统 | 独立的根目录 |
| USER | 用户 | 容器 root ≠ 宿主机 root |
| IPC | 进程通信 | 隔离共享内存 |
| UTS | 主机名 | 独立主机名 |
详见[命名空间](../12_implementation/12.2_namespace.md)章节。 * [内核能力机制](18.4_kernel_capability.md)
* Linux Capabilities 的细粒度权限控制。
### 2. 控制组 * [其它安全特性](18.5_other_feature.md)
* 镜像安全（漏洞扫描、签名验证）、运行时安全（非 root 运行、只读文件系统、Seccomp、AppArmor）、Dockerfile 安全实践、软件供应链安全（SBOM、SLSA）。
限制容器的资源使用，防止资源耗尽攻击：
```bash
## 限制内存（超出会被 OOM Kill）
$ docker run -m 512m myapp
## 限制 CPU
$ docker run --cpus=1.5 myapp
## 限制磁盘 I/O
$ docker run --device-write-bps /dev/sda:10mb myapp
```
### 3. 能力机制
Linux 将 root 权限拆分为多个细粒度的能力。Docker 默认禁用危险能力：
| 能力 | 说明 | 默认状态 |
|------|------|---------|
| `CAP_NET_ADMIN` | 网络管理 | ❌ 禁用 |
| `CAP_SYS_ADMIN` | 系统管理 | ❌ 禁用 |
| `CAP_SYS_PTRACE` | 进程追踪 | ❌ 禁用 |
| `CAP_CHOWN` | 更改文件所有者 | ✅ 启用 |
| `CAP_NET_BIND_SERVICE` | 绑定低端口 | ✅ 启用 |
```bash
## 删除所有能力，只添加需要的
$ docker run --cap-drop=all --cap-add=NET_BIND_SERVICE myapp
## 查看容器的能力
$ docker exec myapp cat /proc/1/status | grep Cap
```
---
## 镜像安全
### 使用可信镜像
```bash
## ✅ 使用官方镜像
$ docker pull nginx
## ✅ 使用经过验证的镜像
$ docker pull bitnami/nginx
## ⚠️ 谨慎使用未知来源镜像
$ docker pull randomuser/suspicious-image
```
### 漏洞扫描
扫描镜像中的已知安全漏洞：
```bash
## Docker Scout（官方工具）
$ docker scout cves nginx:latest
$ docker scout recommendations nginx:latest
## Trivy（开源工具）
$ trivy image nginx:latest
## Snyk（商业工具）
$ snyk container test nginx:latest
```
### 镜像签名验证
当前更推荐使用 Sigstore / Notation 体系进行镜像签名。`Docker Content Trust (DCT)` 已进入退场阶段，不建议作为新项目主方案。
> 注意：Cosign 默认会把签名写回镜像所在仓库，请使用你有推送权限的镜像地址。
```bash
## 准备示例镜像
$ export IMAGE=<你的仓库地址>/myimage:latest
$ docker pull nginx:1.27
$ docker tag nginx:1.27 $IMAGE
$ docker push $IMAGE
## 生成签名密钥（会生成 cosign.key / cosign.pub）
$ cosign generate-key-pair
## Cosign: 签名与验证
$ cosign sign --key cosign.key $IMAGE
$ cosign verify --key cosign.pub $IMAGE
```
---
## 运行时安全
### 1. 非 root 用户运行
> 笔者强调：这是最重要的安全实践之一。
```dockerfile
FROM node:22-alpine
## 创建非 root 用户
RUN addgroup -g 1001 appgroup && \
adduser -u 1001 -G appgroup -D appuser
## 设置工作目录权限
WORKDIR /app
COPY --chown=appuser:appgroup . .
## 切换用户
USER appuser
CMD ["node", "server.js"]
```
或在运行时指定：
```bash
$ docker run -u 1001:1001 myapp
```
### 2. 只读文件系统
```bash
## 根文件系统只读
$ docker run --read-only myapp
## 需要写入的目录使用 tmpfs
$ docker run --read-only --tmpfs /tmp --tmpfs /var/run myapp
```
### 3. 禁用特权模式
```bash
## ❌ 绝对不要在生产环境使用
$ docker run --privileged myapp
## ✅ 只添加必要的能力
$ docker run --cap-add=SYS_TIME myapp
```
### 4. 限制资源
```bash
$ docker run \
-m 512m \ # 内存限制
--cpus=1 \ # CPU 限制
--pids-limit=100 \ # 进程数限制
--ulimit nofile=1024:1024 \ # 文件描述符限制
myapp
```
### 5. 网络隔离
```bash
## 禁用网络（适用于不需要网络的任务）
$ docker run --network=none myapp
## 使用自定义网络隔离
$ docker network create --internal isolated_net
$ docker run --network=isolated_net myapp
```
---
## Dockerfile 安全实践
### 1. 使用精简基础镜像
```dockerfile
## ✅ 好：使用精简镜像
FROM node:22-alpine # ~50MB
FROM gcr.io/distroless/nodejs # ~20MB
## ❌ 差：使用完整镜像
FROM node:22 # ~1GB
FROM ubuntu:24.04 # ~78MB
```
### 2. 多阶段构建
```dockerfile
## 构建阶段
FROM node:22 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build
## 生产阶段（不包含开发依赖和源码）
FROM node:22-alpine
COPY --from=builder /app/dist /app
USER node
CMD ["node", "/app/server.js"]
```
### 3. 不存储敏感信息
```dockerfile
## ❌ 错误：敏感信息写入镜像
ENV DB_PASSWORD=secret123
COPY .env /app/
## ✅ 正确：运行时传入
## docker run -e DB_PASSWORD=xxx 或使用 Docker Secrets
...
```
### 4. 固定依赖版本
```dockerfile
## ✅ 固定版本
FROM node:22.12.0-alpine3.21
RUN apk add --no-cache curl=8.5.0-r0
## ❌ 使用 latest
FROM node:latest
RUN apk add curl
```
---
## 安全扫描清单 ## 安全扫描清单
@@ -306,89 +57,3 @@ RUN apk add curl
| 最小能力 | 检查 `--cap-drop=all` | | 最小能力 | 检查 `--cap-drop=all` |
| 网络隔离 | 检查网络配置 | | 网络隔离 | 检查网络配置 |
| 敏感信息 | 确认无硬编码密码 | | 敏感信息 | 确认无硬编码密码 |
---
## 高级安全方案
### Seccomp 系统调用过滤
限制容器可以使用的系统调用：
```bash
$ docker run --security-opt seccomp=/path/to/profile.json myapp
```
### AppArmor / SELinux
使用强制访问控制：
```bash
$ docker run --security-opt apparmor=docker-default myapp
```
### 安全容器 (gVisor / Kata)
需要更强隔离时：
```bash
## 使用 gVisor 运行时
$ docker run --runtime=runsc myapp
```
---
## 软件供应链安全
随着软件供应链攻击日益频繁，仅保障运行时安全已不足够。
### 1. SBOM (软件物料清单)
SBOM 类似于食品的配料表，列出了容器镜像中包含的所有软件包及其版本。
- **生成 SBOM**：使用 `docker buildx build --sbom` 或 `docker scout sbom`。
- **管理 SBOM**：确保持续监控 SBOM 中的组件是否存在新披露的漏洞。
### 2. 镜像签名 (Sigstore / Notary v2)
确保镜像在构建后未被篡改，且确实来自可信的发布者。
- **Cosign**：Sigstore 项目的一部分，用于签署和验证容器镜像。
```bash
## 使用有写权限的仓库地址
$ export IMAGE=<你的仓库地址>/myimage:tag
$ docker pull nginx:1.27
$ docker tag nginx:1.27 $IMAGE
$ docker push $IMAGE
## 生成签名密钥（会生成 cosign.key / cosign.pub）
$ cosign generate-key-pair
## 签署与验证镜像
$ cosign sign --key cosign.key $IMAGE
$ cosign verify --key cosign.pub $IMAGE
```
### 3. SLSA (Supply-chain Levels for Software Artifacts)
遵循 SLSA 框架，确保构建过程的完整性，例如使用 GitHub Actions 等受控环境进行构建，而非在开发者本地机器上构建发布。
---
## 本章小结
| 安全措施 | 重要程度 | 实现方式 |
|---------|---------|---------|
| 非 root 运行 | ⭐⭐⭐ | `USER` 指令 |
| 漏洞扫描 | ⭐⭐⭐ | `docker scout`, `trivy` |
| 资源限制 | ⭐⭐⭐ | `-m`, `--cpus` |
| 只读文件系统 | ⭐⭐ | `--read-only` |
| 最小能力 | ⭐⭐ | `--cap-drop=all` |
| 镜像签名 | ⭐⭐ | `cosign` / Notation |
## 延伸阅读
- [命名空间](../12_implementation/12.2_namespace.md)：隔离机制详解
- [控制组](../12_implementation/12.3_cgroups.md)：资源限制详解
- [最佳实践](../appendix/best_practices.md)：Dockerfile 安全配置

4
21_case_devops/21.1_devops_workflow.md
View File

@@ -16,7 +16,7 @@
本节通过一组最小可用的片段，展示典型 DevOps 流程中与 Docker 相关的关键配置。 本节通过一组最小可用的片段，展示典型 DevOps 流程中与 Docker 相关的关键配置。
### 1. Dockerfile 多阶段构建 #### 1. Dockerfile 多阶段构建
使用 Docker 多阶段构建可以有效减小镜像体积。 使用 Docker 多阶段构建可以有效减小镜像体积。
@@ -36,7 +36,7 @@ COPY --from=builder /app/main .
CMD ["./main"] CMD ["./main"]
``` ```
### 2. GitLab CI 配置 #### 2. GitLab CI 配置
GitLab CI（`.gitlab-ci.yml`）配置如下： GitLab CI（`.gitlab-ci.yml`）配置如下：