mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 16:37:34 +00:00
Add blank lines before lists per CommonMark
This commit is contained in:
yeasy
@@ -36,6 +36,7 @@ COPY index.html /usr/share/nginx/html/index.html
|
||||
```bash
|
||||
$ docker build -t my-hello-world .
|
||||
```
|
||||
|
||||
* `docker build`：构建命令
|
||||
* `-t my-hello-world`：给镜像起个名字 (标签)
|
||||
* `.`：指定上下文路径为当前目录
|
||||
@@ -47,6 +48,7 @@ $ docker build -t my-hello-world .
|
||||
```bash
|
||||
$ docker run -d -p 8080:80 my-hello-world
|
||||
```
|
||||
|
||||
* `docker run`：运行命令
|
||||
* `-d`：后台运行
|
||||
* `-p 8080:80`：将宿主机的 8080 端口映射到容器的 80 端口
|
||||
|
||||
@@ -93,6 +93,7 @@ flowchart LR
|
||||
runC --> OCI["OCI<br/>标准化"]
|
||||
end
|
||||
```
|
||||
|
||||
- **LXC** (2013)：Docker 最初基于 Linux Containers
|
||||
- **libcontainer** (2014，Docker 0.9)：Docker 自研的容器运行时
|
||||
- **runC** (2015，Docker 1.11 整合)：捐献给 OCI 的标准容器运行时
|
||||
|
||||
@@ -41,6 +41,7 @@ Docker 镜像是一个特殊的文件系统，包含：
|
||||
| **元数据** | 启动命令、暴露端口、数据卷定义 |
|
||||
|
||||
**关键特性**：
|
||||
|
||||
- ✅ 镜像是 **只读** 的
|
||||
- ✅ 镜像 **不包含** 动态数据
|
||||
- ✅ 镜像构建后 **内容不会改变**
|
||||
|
||||
@@ -7,16 +7,19 @@
|
||||
树莓派是 Docker 在边缘计算的一个优秀用例。但在安装前，笔者建议你了解几个实际情况：
|
||||
|
||||
**性能特性**：
|
||||
|
||||
- Raspberry Pi 4 及以上才能流畅运行 Docker 和基本容器
|
||||
- Raspberry Pi Zero 2 可以运行，但性能受限
|
||||
- 磁盘 I/O 是主要瓶颈（特别是使用 microSD 卡时）
|
||||
|
||||
**镜像可用性**：
|
||||
|
||||
- 并非所有 Docker 镜像都有 ARM 版本（arm64 或 armv7）
|
||||
- 官方镜像通常提供多架构支持，但第三方镜像可能没有
|
||||
- 某些依赖 Intel 特定指令的应用无法在 ARM 上运行
|
||||
|
||||
**存储和内存**：
|
||||
|
||||
- 容器镜像会占用较多存储空间，128GB microSD 卡建议最多运行 3-4 个中等大小的容器
|
||||
- 512MB 或 1GB 内存的树莓派运行多个容器会非常吃力
|
||||
|
||||
|
||||
@@ -5,11 +5,13 @@
|
||||
macOS 上没有原生 Linux 内核，Docker 需要运行在一个轻量级虚拟机中。Docker Desktop 完全封装了这个复杂性，让 Mac 用户可以像 Linux 用户一样使用 Docker。但有几点需要特别了解：
|
||||
|
||||
**性能特性**：
|
||||
|
||||
- Apple Silicon（M 系列芯片）比 Intel Mac 的性能更好，且拥有原生支持
|
||||
- 文件 I/O 性能：macOS 与容器之间的卷挂载性能不如 Linux（这是虚拟化的代价）
|
||||
- 内存使用：Docker Desktop 本身会消耗一定内存用于虚拟机管理
|
||||
|
||||
**许可考虑**：
|
||||
|
||||
- 小型企业（少于 250 名员工且年收入低于 1000 万美元）、个人使用、教育和非商业开源项目可免费使用
|
||||
- 超出上述范围的商业用途需要付费订阅
|
||||
|
||||
|
||||
@@ -7,12 +7,14 @@
|
||||
与 macOS 类似，Windows 也没有原生 Linux 容器支持。Docker Desktop for Windows 有两种运行后端可选：
|
||||
|
||||
**WSL 2（Windows Subsystem for Linux 2）** - 推荐：
|
||||
|
||||
- 利用 Hyper-V 虚拟化运行真正的 Linux 内核
|
||||
- 性能更好，文件系统集成更深
|
||||
- 现代 Windows 10/11 的标准选择
|
||||
- 支持在 Linux 和 Windows 之间的无缝文件访问
|
||||
|
||||
**Hyper-V** - 传统方案：
|
||||
|
||||
- 纯虚拟化方式
|
||||
- 性能略低于 WSL 2
|
||||
- 在某些企业网络环境下仍被使用
|
||||
|
||||
@@ -11,11 +11,13 @@ Docker Engine 主要提供 `stable` 和 `test` 两个更新频道；`test.docker
|
||||
### 生产环境 vs 开发环境
|
||||
|
||||
**生产环境**（服务器部署）：
|
||||
|
||||
- 优先使用**官方 APT/YUM 源安装**（Ubuntu、Debian、Fedora、CentOS）
|
||||
- 优势：获得官方安全更新、长期技术支持、版本管理清晰
|
||||
- 安装步骤稍多一些，但这种“麻烦”是值得的——它为你的生产系统争取了稳定性和可维护性
|
||||
|
||||
**开发环境**（本地开发机、测试服务器）：
|
||||
|
||||
- 使用**脚本自动安装**或**包管理器直接安装**
|
||||
- 如果你想快速上手，官方脚本（`get.docker.com`）是最便捷的选择
|
||||
- 国内用户注意：这一步一定要选对镜像源，否则网络卡顿会严重影响体验
|
||||
|
||||
@@ -59,6 +59,7 @@ FROM scratch
|
||||
```docker
|
||||
RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
|
||||
```
|
||||
|
||||
* *exec* 格式：`RUN ["可执行文件", "参数1", "参数2"]`，这更像是函数调用中的格式。
|
||||
|
||||
在会修改文件系统的指令里，`RUN` 是最典型的一类。每一个 `RUN` 的行为，都可以类比为我们刚才手工建立镜像的过程：先基于当前结果启动一个临时构建环境，在其上执行这些命令，再把这一步产生的文件系统变化保存为新的结果层。
|
||||
|
||||
@@ -38,6 +38,7 @@ flowchart TD
|
||||
end
|
||||
Note["所有的写操作都在容器层这里"] -.-> L4
|
||||
```
|
||||
|
||||
* **读取文件**：当容器需要读取文件时，Docker 会从最上层 (容器层) 开始向下层 (镜像层) 寻找，直到找到该文件为止。
|
||||
* **修改文件**：当容器需要修改某个文件时，Docker 会从下层镜像中将该文件复制到上层的容器层，然后对副本进行修改。这被称为 **写时复制 (Copy-on-Write，CoW)** 策略。
|
||||
* **删除文件**：当容器删除某个文件时，Docker 并不是真的去下层删除它 (因为下层是只读的)，而是在容器层创建一个特殊的 “白障 (Whiteout)” 文件，用来标记该文件已被删除，从而在容器视图中隐藏它。
|
||||
|
||||
@@ -82,6 +82,7 @@ Docker Hub 对不同类型用户实施拉取速率限制（2025 年 4 月起更
|
||||
除了上述针对特定账号拉取镜像数量的 Pull Rate Limit 之外，Docker Hub 对所有用户（包含已认证及付费用户）还实施了 **滥用保护限流 (Abuse Rate Limiting)**。它是根据网络出口 IP (IPv4 或 IPv6 /64 子网) 计算整体请求频率，阈值动态触发（通常为每分钟数千级别请求）。
|
||||
|
||||
**两类的差异与排查方法**：
|
||||
|
||||
- **Pull Rate Limit**：针对拉取量达到上限。报错返回 `429 Too Many Requests`，并且 HTTP 返回体/CLI 错误提示中会带有明确的 `toomanyrequests: You have reached your pull rate limit` 提示，常附有账户升级链接。
|
||||
- **Abuse Rate Limit**：防范接口频率打击。报错仅返回简化的 `429 Too Many Requests`。这一限流不分付费与否，常发生在“多终端共享出口 IP”的企业局域网或者第三方云 CI 服务（如 GitHub Actions 等）中，即使你已正常配置 `docker login` 也依旧可能触发。
|
||||
|
||||
|
||||
@@ -11,15 +11,18 @@
|
||||
在讨论具体的安装和配置前，让我们先理解：**什么时候你应该建设私有仓库？**
|
||||
|
||||
**开发团队**（有专利代码、不能公开）：
|
||||
|
||||
- 需要私有仓库存储内部镜像
|
||||
- 涉及访问控制和审计
|
||||
- 强烈推荐使用托管方案（如 Harbor 或云厂商提供的镜像仓库）
|
||||
|
||||
**开源项目或个人学习**：
|
||||
|
||||
- Docker Hub 公开仓库足够
|
||||
- 无需自建私有仓库的成本
|
||||
|
||||
**企业级部署**：
|
||||
|
||||
- 需要高可用、备份、灾难恢复
|
||||
- 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
|
||||
|
||||
|
||||
@@ -28,6 +28,7 @@ RUN ["executable", "param1", "param2"]
|
||||
```docker
|
||||
RUN apt-get update
|
||||
```
|
||||
|
||||
- **特点**：默认通过 `/bin/sh -c` 执行。
|
||||
- **优势**：可以使用环境变量、管道、重定向等 Shell 特性。
|
||||
- **示例**：
|
||||
@@ -40,6 +41,7 @@ RUN apt-get update
|
||||
```docker
|
||||
RUN ["apt-get", "update"]
|
||||
```
|
||||
|
||||
- **特点**：直接调用可执行文件，不经过 Shell。
|
||||
- **优势**：避免 Shell 字符串解析问题，适用于参数中包含特殊字符的情况。
|
||||
- **注意**：无法使用 `$VAR` 环境变量替换 (除非显式调用 shell)。
|
||||
|
||||
@@ -10,6 +10,7 @@
|
||||
- **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
|
||||
|
||||
**决策树**：
|
||||
|
||||
1. **你的容器是否有不可变的启动逻辑？** 比如需要先做一些初始化工作，然后才运行应用 → 使用 ENTRYPOINT
|
||||
2. **用户经常会在 `docker run` 时传入不同的命令吗？** → 使用 CMD（让用户灵活覆盖）
|
||||
3. **大多数情况下，你希望容器始终以相同的方式启动？** → 使用 ENTRYPOINT
|
||||
|
||||
@@ -7,21 +7,25 @@ Docker Compose 提供了丰富的命令来管理项目和容器。本节将详
|
||||
在学习具体命令前，让我们从使用场景出发，这样可以帮助你更快地找到需要的命令：
|
||||
|
||||
**项目启动与停止**：
|
||||
|
||||
- `docker compose up`：第一次启动项目，拉取镜像、创建容器
|
||||
- `docker compose start`：启动已停止的容器（项目已存在）
|
||||
- `docker compose stop`：优雅地停止容器（不删除容器）
|
||||
- `docker compose down`：完全清理，删除容器和网络（开发时常用）
|
||||
|
||||
**调试与查看**：
|
||||
|
||||
- `docker compose ps`：查看项目中的容器状态
|
||||
- `docker compose logs`：查看容器日志（排查问题的第一步）
|
||||
- `docker compose exec`：进入正在运行的容器执行命令
|
||||
|
||||
**构建与更新**：
|
||||
|
||||
- `docker compose build`：重新构建镜像（修改 Dockerfile 后）
|
||||
- `docker compose pull`：更新所有镜像到最新版本
|
||||
|
||||
**配置验证**：
|
||||
|
||||
- `docker compose config`：验证 docker-compose.yml 格式是否正确
|
||||
|
||||
### 11.4.1 命令对象与格式
|
||||
|
||||
@@ -114,6 +114,7 @@ max_execution_time = 600
|
||||
```bash
|
||||
$ docker compose up -d
|
||||
```
|
||||
|
||||
2. 访问安装界面：
|
||||
打开浏览器访问 `http://localhost:8000`
|
||||
|
||||
|
||||
@@ -83,6 +83,7 @@ flowchart TD
|
||||
R -->|7. 进程退出| E
|
||||
S -->|8. 监控 IO 和退出| P
|
||||
```
|
||||
|
||||
1. **CLI** 发送请求给 **Dockerd**
|
||||
2. **Dockerd** 解析请求，调用 **Containerd**
|
||||
3. **Containerd** 准备镜像，转换为 OCI Bundle
|
||||
@@ -117,6 +118,7 @@ flowchart TD
|
||||
CLI -- "(Socket 映射)" --> Engine
|
||||
end
|
||||
```
|
||||
|
||||
- 使用轻量级虚拟机 (Apple Virtualization / WSL 2) 运行 Linux 内核
|
||||
- 文件挂载 (Bind Mount) 需要跨越 VM 边界 (这也是文件 I/O 慢的原因)
|
||||
- 网络端口需要从宿主机转发到 VM
|
||||
|
||||
@@ -102,6 +102,7 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
|
||||
#### Classic Graph Drivers 与 Snapshotters 的核心差异
|
||||
|
||||
传统模型（如 `overlay2`）将镜像拉取解包的过程由 Docker 的 graph drivers 处理。而新的 `containerd image store` 则将这一职责彻底下放给了 `containerd` 自身的 `snapshotters`（底层在 Linux 发行版通常依然利用操作系统的 overlayfs）。这种架构改变带来了：
|
||||
|
||||
1. 本地免拉取查看多平台镜像 index manifest 与 attestations (SBOM、Provenance)。
|
||||
2. 避免了以前绕过 CRI 获取本地镜像的问题，带来更好的原生 Kubernetes 生态兼容性。
|
||||
|
||||
@@ -136,6 +137,7 @@ flowchart TD
|
||||
OverlayFS --> Lower2
|
||||
OverlayFS --> Lower1
|
||||
```
|
||||
|
||||
- **lowerdir**：只读的镜像层 (可以有多个)
|
||||
- **upperdir**：可写的容器层
|
||||
- **workdir**：OverlayFS 的工作目录
|
||||
|
||||
@@ -175,6 +175,7 @@ $ sudo kubeadm init \
|
||||
--v 5 \
|
||||
--ignore-preflight-errors=all
|
||||
```
|
||||
|
||||
* `--pod-network-cidr 10.244.0.0/16` 参数与后续 CNI 插件有关，这里以 `flannel` 为例，若后续部署其他类型的网络插件请更改此参数。
|
||||
|
||||
> 执行可能出现错误，例如缺少依赖包，根据提示安装即可。
|
||||
|
||||
@@ -195,6 +195,7 @@ $ sudo kubeadm init --image-repository registry.cn-hangzhou.aliyuncs.com/google_
|
||||
--v 5 \
|
||||
--ignore-preflight-errors=all
|
||||
```
|
||||
|
||||
* `--cri-socket unix:///var/run/cri-dockerd.sock` 参数指定使用 cri-dockerd 作为容器运行时接口。
|
||||
* `--pod-network-cidr 10.244.0.0/16` 参数与后续 CNI 插件有关，这里以 `flannel` 为例，若后续部署其他类型的网络插件请更改此参数。
|
||||
|
||||
|
||||
@@ -140,6 +140,7 @@ docker info | grep -A 5 "Registry Mirrors"
|
||||
#### Windows/Mac 配置
|
||||
|
||||
在 Docker Desktop 的 Settings 中：
|
||||
|
||||
1. 进入 “Docker Engine” 标签
|
||||
2. 编辑 JSON 配置，添加 `registry-mirrors` 字段
|
||||
3. 点击 “Apply & Restart”
|
||||
|
||||
@@ -23,6 +23,7 @@
|
||||
在早期，Docker 引擎是一个包含了所有功能的单体架构。随着技术的发展和标准化要求，Docker 将底层关于容器运行时的部分解耦出来，形成了 `containerd` 和 `runc`。
|
||||
|
||||
当你执行一个 `docker run` 命令时，调用链路大致如下：
|
||||
|
||||
1. Docker Client 发送请求给 Docker Daemon（`dockerd`）。
|
||||
2. `dockerd` 将请求转发给 `containerd`。
|
||||
3. `containerd` 准备好镜像和容器的必要环境，然后调用 `runc`。
|
||||
|
||||
@@ -25,6 +25,7 @@
|
||||
限制内存可以防止应用程序因内存泄漏或恶意载荷导致宿主机 OOM。
|
||||
|
||||
**关键参数：**
|
||||
|
||||
- `-m, --memory=""`：硬限制，容器可使用的最大内存量。
|
||||
- `--memory-swap=""`：限制容器可使用的内存与 Swap 总量。
|
||||
|
||||
@@ -46,6 +47,7 @@ $ docker run -d \
|
||||
限制 CPU 可以防止个别计算密集型的容器垄断 CPU 时间片，保证系统的调度公平性。
|
||||
|
||||
**关键参数：**
|
||||
|
||||
- `--cpus=<value>`：指定容器可以使用的 CPU 核心数量（可以是小数）。
|
||||
- `-c, --cpu-shares=0`：软限制，设置容器使用 CPU 的相对权重（默认是 1024）。
|
||||
|
||||
@@ -67,6 +69,7 @@ $ docker run -d \
|
||||
进程炸弹（Fork Bomb）是一种典型的拒绝服务攻击方式，它通过不断 `fork()` 新进程来耗尽系统的进程表条目，导致系统无法创建任何新任务。
|
||||
|
||||
**关键参数：**
|
||||
|
||||
- `--pids-limit=<number>`：限制容器内允许创建的最大进程数。
|
||||
|
||||
**实战示例：**
|
||||
|
||||
@@ -33,6 +33,7 @@ dockerd \
|
||||
--tlskey=server-key.pem \
|
||||
-H=0.0.0.0:2376
|
||||
```
|
||||
|
||||
3. 客户端想要连接时，也必须出示客户端证书。
|
||||
|
||||
> [!TIP]
|
||||
@@ -61,14 +62,17 @@ Rootless 模式允许在完全局限于非 `root` 用户的环境中运行 Docke
|
||||
```bash
|
||||
$ sudo apt-get install uidmap
|
||||
```
|
||||
|
||||
2. 切换到一个没有任何 `sudo` 权限的普通用户（假设用户名为 `testuser`）：
|
||||
```bash
|
||||
$ su - testuser
|
||||
```
|
||||
|
||||
3. 运行 Docker 官方提供的 Rootless 安装脚本：
|
||||
```bash
|
||||
$ curl -fsSL https://get.docker.com/rootless | sh
|
||||
```
|
||||
|
||||
4. 配置环境变量指向新创建的私有 socket：
|
||||
```bash
|
||||
$ export DOCKER_HOST=unix:///run/user/1000/docker.sock
|
||||
|
||||
@@ -9,6 +9,7 @@
|
||||
Trivy 是由 Aqua Security 开发的开源漏洞扫描器，以其轻量级、快速、准确而闻名，已成为业界标准。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 零依赖，单个二进制文件
|
||||
- 扫描速度快（秒级）
|
||||
- 支持镜像、文件系统、Git 仓库多种扫描源
|
||||
@@ -47,6 +48,7 @@ trivy image --severity HIGH,CRITICAL \
|
||||
Grype 由 Anchore 开发，支持更广泛的软件包管理器和语言。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 支持 Java、Python、Go、Ruby、JavaScript 等多种语言的依赖检测
|
||||
- 与 Syft（SBOM 生成器）配合效果好
|
||||
- 可自定义漏洞数据库源
|
||||
@@ -74,6 +76,7 @@ grype dir:/path/to/app
|
||||
Snyk 提供了商业级的安全扫描服务，特别适合企业环境。
|
||||
|
||||
**特点：**
|
||||
|
||||
- 支持开源漏洞和许可证扫描
|
||||
- 与多个 Git 平台深度集成（GitHub、GitLab、Bitbucket）
|
||||
- 提供修复建议和自动化修复 PR
|
||||
|
||||
@@ -9,6 +9,7 @@
|
||||
容器性能监控涉及以下关键指标：
|
||||
|
||||
**CPU 相关指标：**
|
||||
|
||||
- `cpu.usage_usec`：容器 CPU 使用时间（微秒）
|
||||
- `cpu.stat.nr_throttled`：CPU 限流发生次数
|
||||
- `cpu.stat.throttled_usec`：CPU 限流总时间
|
||||
@@ -16,6 +17,7 @@
|
||||
- `cpu_quota`：CPU 配额设置（微秒）
|
||||
|
||||
**内存相关指标：**
|
||||
|
||||
- `memory.usage_bytes`：当前内存使用量
|
||||
- `memory.max_usage_bytes`：内存使用峰值
|
||||
- `memory.limit_in_bytes`：内存限制
|
||||
@@ -25,6 +27,7 @@
|
||||
- `memory.stat.swap`：SWAP 使用量
|
||||
|
||||
**网络相关指标：**
|
||||
|
||||
- `rx_bytes`：接收字节数
|
||||
- `tx_bytes`：发送字节数
|
||||
- `rx_packets`：接收包数
|
||||
@@ -35,6 +38,7 @@
|
||||
- `tx_dropped`：发送丢包数
|
||||
|
||||
**I/O 相关指标：**
|
||||
|
||||
- `io_service_bytes`：I/O 操作字节数
|
||||
- `io_service_time`：I/O 操作耗时
|
||||
- `io_queued`：I/O 队列长度
|
||||
|
||||
@@ -49,5 +49,6 @@
|
||||
|
||||
* Linux 下如果遇到容器内写文件权限问题，优先确保容器内用户与宿主机 UID/GID 对齐。
|
||||
VS Code Dev Containers 支持自动处理；手写 Dockerfile/compose 时也可以显式设置用户。
|
||||
|
||||
* 如果遇到文件变更监听不生效（常见于 macOS/Windows 的虚拟化文件系统），
|
||||
优先使用语言/工具支持的轮询模式或提高 watcher 限制。
|
||||
|
||||
@@ -9,6 +9,7 @@ Docker 学习可分为四个递进阶段，每个阶段都有明确的学习目
|
||||
#### 第一阶段：基础入门（0-2 周）
|
||||
|
||||
**学习目标：**
|
||||
|
||||
- 理解容器化的基本概念
|
||||
- 能够运行、管理基本的容器
|
||||
- 了解镜像和仓库的基本操作
|
||||
@@ -36,11 +37,13 @@ Docker 安装配置
|
||||
└── 权限和用户配置
|
||||
```
|
||||
**学习资源：**
|
||||
|
||||
- [官方教程](https://docs.docker.com/get-started/)
|
||||
- 本书第 1-3 章：入门篇基础概念
|
||||
- [Docker CLI 参考](https://docs.docker.com/engine/reference/commandline/)
|
||||
|
||||
**时间投入：**
|
||||
|
||||
- 理论学习：3-4 小时
|
||||
- 实操练习：8-10 小时
|
||||
- 总计：2 周
|
||||
@@ -57,6 +60,7 @@ Docker 安装配置
|
||||
#### 第二阶段：核心开发（2-6 周）
|
||||
|
||||
**学习目标：**
|
||||
|
||||
- 掌握 Dockerfile 编写
|
||||
- 能够构建自己的应用镜像
|
||||
- 理解数据管理和网络配置
|
||||
@@ -110,11 +114,13 @@ Docker Compose
|
||||
└── build / push
|
||||
```
|
||||
**学习资源：**
|
||||
|
||||
- 本书第 4-11 章：进阶篇
|
||||
- [Docker 官方最佳实践](https://docs.docker.com/develop/dev-best-practices/)
|
||||
- [Dockerfile 参考](https://docs.docker.com/engine/reference/builder/)
|
||||
|
||||
**时间投入：**
|
||||
|
||||
- 理论学习：8-10 小时
|
||||
- 实操练习：30-40 小时（多个实战项目）
|
||||
- 总计：4-6 周
|
||||
@@ -140,6 +146,7 @@ Docker Compose
|
||||
#### 第三阶段：生产优化（6-12 周）
|
||||
|
||||
**学习目标：**
|
||||
|
||||
- 掌握容器安全最佳实践
|
||||
- 理解性能监控和优化
|
||||
- 学会容器编排（Kubernetes 基础）
|
||||
@@ -218,11 +225,13 @@ CI/CD 集成
|
||||
└── Kollabot
|
||||
```
|
||||
**学习资源：**
|
||||
|
||||
- 本书第 12-21 章：深入篇和实战篇
|
||||
- [Kubernetes 官方文档](https://kubernetes.io/docs/)
|
||||
- [CNCF 学习路线](https://landscape.cncf.io/)
|
||||
|
||||
**时间投入：**
|
||||
|
||||
- 理论学习：15-20 小时
|
||||
- 实操练习：60-80 小时（多个生产级项目）
|
||||
- 总计：6-12 周
|
||||
@@ -254,6 +263,7 @@ CI/CD 集成
|
||||
#### 第四阶段：专家深造（12+ 周）
|
||||
|
||||
**学习目标：**
|
||||
|
||||
- 掌握 Kubernetes 高级特性
|
||||
- 理解容器运行时底层实现
|
||||
- 能够设计和优化大规模容器平台
|
||||
@@ -318,6 +328,7 @@ DevOps 工程化
|
||||
└── 文档和最佳实践传播
|
||||
```
|
||||
**贡献机会：**
|
||||
|
||||
- [Kubernetes](https://github.com/kubernetes/kubernetes)
|
||||
- [Cilium](https://github.com/cilium/cilium)
|
||||
- [Prometheus](https://github.com/prometheus/prometheus)
|
||||
@@ -484,6 +495,7 @@ docker stats / events / inspect
|
||||
#### Kubernetes 认证
|
||||
|
||||
**认证路径：**
|
||||
|
||||
1. **CKA - Certified Kubernetes Administrator**
|
||||
- 难度：高
|
||||
- 时间：3 小时（实操）
|
||||
|
||||
Reference in New Issue
Block a user