Complete Dockerfile instruction reference list

- ch12: 添加 TIME namespace (Linux 5.6+)，内核 namespace 类型从 7 更新为 8
- ch12: 补充 Docker Engine v29.x 实���性 nftables 支持
- ch13: Ingress-NGINX 退役通知，添加 Gateway API 推荐方案和示例
- ch13: 添加 Pod Security Standards 章节（替代已移除的 PSP）
- ch18: 补充 DCT 退役时间线（2028-03-31 完全移除）和迁移建议

02_basic_concept/2.3_repository.md

@@ -255,7 +255,7 @@ someuser/myapp # ⚠️ 需要评估
 
 #### 镜像签名
 
-当前更推荐使用 Sigstore / Notation 体系进行镜像签名与验证。`Docker Content Trust (DCT)` 已于 2025 年 8 月 8 日开始停用，官方 Docker 镜像已停止 DCT 签名，2028 年 3 月 31 日将完全删除此功能，不建议作为新项目方案。
+当前更推荐使用 Sigstore / Notation 体系进行镜像签名与验证。`Docker Content Trust (DCT)` 已进入弃用阶段：2025 年 8 月 8 日起最早的 DCT 签名证书开始过期，2025 年 9 月 30 日起不能在新 Registry 启用 DCT，2028 年 3 月 31 日将完全删除此功能。不建议作为新项目方案。
 
 > 注意：Cosign 默认会把签名推送回镜像所在仓库，请使用你有推送权限的镜像地址。
 

06_repository/6.1_dockerhub.md

@@ -67,15 +67,15 @@ $ docker push username/myapp:v1
 
 #### 镜像拉取限制
 
-Docker Hub 对不同类型用户实施拉取速率限制（2025 年 4 月起更新）：
+Docker Hub 对不同类型用户实施拉取速率限制（基于 6 小时周期）：
 
 | 用户类型 | 限制 |
 |---------|------|
-| **匿名用户** (未登录) | 每小时 10 次请求 |
-| **免费账户** (已登录) | 每小时 100 次请求 |
+| **匿名用户** (未登录) | 每 6 小时 100 次请求 |
+| **免费账户** (已登录) | 每 6 小时 200 次请求 |
 | **Pro/Team/Business 账户** | 无限制（公平使用政策） |
 
-> **注意**：2025 年 4 月前的旧限制为匿名用户每 6 小时 100 次、免费账户每 6 小时 200 次。新政策大幅收紧了匿名拉取额度，建议在 CI/CD 环境中始终配置 `docker login`。
+> **注意**：自 2025 年 4 月起，所有付费订阅用户享有无限制拉取额度。匿名用户和免费账户的限制保持不变，建议在 CI/CD 环境中始终配置 `docker login` 以获得更高的拉取额度。
 
 #### 滥用限流
 

07_dockerfile/7.16_references.md

@@ -14,12 +14,20 @@ Dockerfile 中的常用指令包括：
 
 - **FROM**: 指定基础镜像，必须是第一条指令
 - **RUN**: 在镜像中执行命令，用于安装软件包等
-- **WORKDIR**: 设置工作目录
-- **COPY/ADD**: 复制文件到镜像中
-- **EXPOSE**: 声明容器监听的端口
-- **ENV**: 设置环境变量
-- **ENTRYPOINT**: 容器启动时的入口点
+- **COPY**: 复制文件到镜像中
+- **ADD**: 更高级的复制文件（支持 URL 和自动解压）
 - **CMD**: 容器默认执行的命令
+- **ENTRYPOINT**: 容器启动时的入口点
+- **ENV**: 设置环境变量
+- **ARG**: 构建时的参数变量
+- **VOLUME**: 定义匿名卷挂载点
+- **EXPOSE**: 声明容器监听的端口
+- **WORKDIR**: 设置工作目录
+- **USER**: 指定运行容器时的用户
+- **HEALTHCHECK**: 配置容器健康检查
+- **ONBUILD**: 设置触发器指令，在子镜像构建时执行
+- **LABEL**: 为镜像添加元数据标签
+- **SHELL**: 指定 RUN 等指令使用的 shell
 
 ### 最佳实践建议
 

07_dockerfile/7.17_multistage_builds.md

@@ -68,7 +68,7 @@ RUN go get -d -v github.com/go-sql-driver/mysql \
 编写 `Dockerfile.copy` 文件
 
 ```docker
-FROM alpine:latest
+FROM alpine:3
 
 RUN apk --no-cache add ca-certificates
 
@@ -131,7 +131,7 @@ COPY app.go .
 
 RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
 
-FROM alpine:latest as prod
+FROM alpine:3 as prod
 
 RUN apk --no-cache add ca-certificates
 
@@ -176,5 +176,5 @@ $ docker build --target builder -t username/imagename:tag .
 上面例子中我们使用 `COPY --from=0 /go/src/github.com/go/helloworld/app .` 从上一阶段的镜像中复制文件，我们也可以复制任意镜像中的文件。
 
 ```docker
-COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
+COPY --from=nginx:1.25-alpine /etc/nginx/nginx.conf /nginx.conf
 ```

07_dockerfile/7.18_multistage_builds_laravel.md

@@ -61,7 +61,7 @@ server {
 
 ```docker
 # 注：node 镜像推荐使用具体的版本标签（如 node:20-alpine）
-FROM node:alpine as frontend
+FROM node:20-alpine as frontend
 
 COPY package.json /app/
 
@@ -83,7 +83,7 @@ RUN set -x ; cd /app \
 
 ```docker
 # 注：composer 镜像推荐使用具体的版本标签（如 composer:2.x）
-FROM composer as composer
+FROM composer:2 as composer
 
 COPY database/ /app/database/
 COPY composer.json composer.lock /app/
@@ -129,7 +129,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
 
 ```docker
 # 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.25-alpine）
-FROM nginx:alpine as nginx
+FROM nginx:1.25-alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
 
@@ -180,7 +180,7 @@ $ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
 
 ```docker
 # 注：生产环境推荐使用具体的版本标签，如 node:20-alpine、composer:2.x、php:8.3-fpm-alpine、nginx:1.25-alpine
-FROM node:alpine as frontend
+FROM node:20-alpine as frontend
 
 COPY package.json /app/
 
@@ -195,7 +195,7 @@ RUN set -x ; cd /app \
       && mkdir -p public \
       && npm run production
 
-FROM composer as composer
+FROM composer:2 as composer
 
 COPY database/ /app/database/
 COPY composer.json composer.lock /app/
@@ -229,8 +229,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
       && chmod -R 777 storage \
       && php artisan package:discover
 
-FROM nginx:alpine as nginx
-```
+FROM nginx:1.25-alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
 

07_dockerfile/multistage_example/laravel/Dockerfile

@@ -1,4 +1,4 @@
-FROM node:alpine as frontend
+FROM node:20-alpine as frontend
 
 COPY package.json /app/
 
@@ -13,7 +13,7 @@ RUN set -x ; cd /app \
       && mkdir -p public \
       && npm run production
 
-FROM composer as composer
+FROM composer:2 as composer
 
 COPY database/ /app/database/
 COPY composer.json /app/
@@ -47,7 +47,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
       && chmod -R 777 storage \
       && php artisan package:discover
 
-FROM nginx:alpine as nginx
+FROM nginx:1.25-alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
 

11_compose/11.5_compose_file.md

@@ -132,7 +132,43 @@ services:
   db:
     image: postgres
 ```
-> 注意：`web` 服务不会等待 `redis` `db` “完全启动” 之后才启动。
+
+> 注意：上述简写形式中，`web` 服务不会等待 `redis` `db` “完全启动” 之后才启动。
+
+如果需要等待依赖服务就绪，可以使用 `condition` 字段配合 `healthcheck`：
+
+```yaml
+services:
+  web:
+    build: .
+    depends_on:
+      db:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+
+  redis:
+    image: redis
+    healthcheck:
+      test: [“CMD”, “redis-cli”, “ping”]
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  db:
+    image: postgres
+    healthcheck:
+      test: [“CMD-SHELL”, “pg_isready -U postgres”]
+      interval: 5s
+      timeout: 3s
+      retries: 5
+```
+
+`condition` 支持三个值：
+
+* `service_started`：容器启动即满足（默认）。
+* `service_healthy`：容器的 `healthcheck` 状态为 healthy 时满足。
+* `service_completed_successfully`：容器成功退出（退出码为 0）时满足，适用于初始化任务等一次性容器。
 
 ### 11.5.10 `dns`
 

12_implementation/12.1_arch.md

@@ -101,6 +101,7 @@ flowchart TD
 
 - **Containerd 镜像存储 (Image Store)**：在 v29.x 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
   - **优势**：多平台镜像支持更好、镜像拉取更快 (lazy pulling)、与 K8s 共享镜像。
+- **实验性 nftables 支持**：随着主流 Linux 发行版逐步弃用 iptables，Docker v29.x 引入了实验性 nftables 后端。启用方式为 `dockerd --firewall-backend=nftables`，可直接创建 nftables 规则而无需依赖 iptables-nft 转换层。生产环境请谨慎使用。
 
 ---
 

12_implementation/12.2_namespace.md

@@ -28,7 +28,7 @@ flowchart LR
 
 ### 12.2.2 Namespace 的类型
 
-Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
+Linux 内核（5.6+）共提供 8 种 Namespace。Docker 容器默认使用其中 7 种（不含 Time）：
 
 | Namespace | 隔离内容 | 容器中的效果 |
 |-----------|---------|-------------|
@@ -39,6 +39,7 @@ Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
 | **IPC** | 进程间通信 | 独立的信号量、消息队列、共享内存 |
 | **USER** | 用户/组 ID | 容器内的 root 可以映射为宿主机的普通用户 |
 | **Cgroup** | Cgroup 根目录 | 隔离 cgroup 层级视图 (Linux 4.6+)|
+| **Time** | 系统时钟 | 隔离 CLOCK_MONOTONIC 和 CLOCK_BOOTTIME (Linux 5.6+)|
 
 ---
 
@@ -290,7 +291,7 @@ Namespace 提供了隔离但不是安全边界：
 | 方面 | 说明 |
 |------|------|
 | **共享内核** | 所有容器共享宿主机内核，内核漏洞可能影响所有容器 |
-| **部分资源未隔离** | /proc、/sys 部分内容仍可见；时间无法隔离 |
+| **部分资源未隔离** | /proc、/sys 部分内容仍可见；Time Namespace (Linux 5.6+) 虽已可用，但 Docker 默认不启用 |
 | **非虚拟化** | 比虚拟机隔离性弱 |
 
 > 需要更强隔离时，可考虑 gVisor、Kata Containers 等安全容器方案。

12_implementation/12.6_network.md

@@ -50,7 +50,7 @@ $ sudo ln -s /proc/$pid/ns/net /var/run/netns/$pid
 ```bash
 $ ip addr show docker0
 21: docker0: ...
-inet 172.17.42.1/16 scope global docker0
+inet 172.17.0.1/16 scope global docker0
 ...
 ```
 创建一对 “veth pair” 接口 A 和 B，绑定 A 到网桥 `docker0`，并启用它
@@ -64,8 +64,8 @@ $ sudo ip link set A up
 $ sudo ip link set B netns $pid
 $ sudo ip netns exec $pid ip link set dev B name eth0
 $ sudo ip netns exec $pid ip link set eth0 up
-$ sudo ip netns exec $pid ip addr add 172.17.42.99/16 dev eth0
-$ sudo ip netns exec $pid ip route add default via 172.17.42.1
+$ sudo ip netns exec $pid ip addr add 172.17.0.99/16 dev eth0
+$ sudo ip netns exec $pid ip route add default via 172.17.0.1
 ```
 以上，就是 Docker 配置网络的具体过程。
 

13_kubernetes_concepts/13.4_advanced.md

@@ -10,16 +10,51 @@
 *   **版本管理**：轻松回滚应用的发布版本。
 *   **模板化**：支持复杂的应用部署逻辑配置。
 
-### 13.4.2 Ingress - 服务的入口
+### 13.4.2 Gateway API 与 Ingress
 
-Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress** 提供了 7 层 (HTTP/HTTPS) 路由能力，充当集群的网关。
+Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。集群需要 7 层 (HTTP/HTTPS) 路由能力来充当网关。
 
-*   **域名路由**：基于 Host 将请求转发不同服务 (api.example.com -> api-svc，web.example.com -> web-svc)。
-*   **路径路由**：基于 Path 将请求转发 (/api -> api-svc， / -> web-svc)。
+#### Gateway API（推荐）
+
+> **重要**：Kubernetes 社区推荐使用 [Gateway API](https://gateway-api.sigs.k8s.io/) 作为新一代流量管理标准。原 `kubernetes/ingress-nginx` 项目已于 2026 年 3 月退役停止维护，不再接收安全更新。
+
+Gateway API 基于 CRD 实现，提供了比 Ingress 更强大和标准化的流量管理能力：
+
+*   **GatewayClass**：定义网关实现（类似 IngressClass）。
+*   **Gateway**：定义监听端口和协议（由基础设施团队管理）。
+*   **HTTPRoute**：定义 HTTP 路由规则（由应用团队管理）。
+*   **职责分离**：基础设施、集群运维和应用开发者各管各的资源。
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: my-route
+spec:
+  parentRefs:
+  - name: my-gateway
+  hostnames:
+  - "api.example.com"
+  rules:
+  - matches:
+    - path:
+        type: PathPrefix
+        value: /api
+    backendRefs:
+    - name: api-svc
+      port: 80
+```
+
+常见的 Gateway API 实现有 Envoy Gateway、Istio、Cilium、Traefik、Kong 等。
+
+#### Ingress（传统方案）
+
+Ingress 资源仍可正常使用，但建议新项目直接采用 Gateway API。已有 Ingress 配置可按需逐步迁移。
+
+*   **域名路由**：基于 Host 将请求转发不同服务。
+*   **路径路由**：基于 Path 将请求转发。
 *   **SSL/TLS**：集中管理证书。
 
-常见的 Ingress Controller 有 Nginx Ingress Controller，Traefik，Istio Gateway 等。
-
 ### 13.4.3 Persistent Volume 与 StorageClass
 
 容器内的文件是临时的。对于有状态应用 (如数据库)，需要持久化存储。
@@ -59,3 +94,23 @@ spec:
 *   **Secret**：存储机密数据 (密码、Token、证书)，在 Etcd 中加密存储。
 
 通过将配置与镜像分离，保证了容器的可移植性。
+
+### 13.4.6 Pod Security Standards
+
+> **注意**：PodSecurityPolicy (PSP) 已在 Kubernetes 1.25 中完全移除。
+
+Kubernetes 使用 **Pod Security Standards** 定义三个安全级别，通过内置的 Pod Security Admission 控制器在命名空间级别执行：
+
+*   **Privileged**：不受限制，适用于系统级和基础设施工作负载。
+*   **Baseline**：防止已知的权限提升，适用于大多数工作负载。
+*   **Restricted**：严格限制，遵循 Pod 安全加固最佳实践。
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: my-app
+  labels:
+    pod-security.kubernetes.io/enforce: baseline
+    pod-security.kubernetes.io/warn: restricted
+```

14_kubernetes_setup/14.1_kubeadm.md

@@ -105,13 +105,13 @@ $ sudo modprobe br_netfilter
 
 #### cgroup v2 要求：必须
 
-Kubernetes v1.36 要求节点使用 cgroup v2（不再支持 cgroup v1）。kubelet 在 cgroup v1 节点上会拒绝启动。验证节点是否支持 cgroup v2：
+Kubernetes v1.36 默认要求节点使用 cgroup v2。kubelet 在 cgroup v1 节点上默认会拒绝启动，但管理员可以在 kubelet 配置中设置 `failCgroupV1: false` 来兼容 cgroup v1（仅建议用于遗留系统过渡期）。验证节点是否支持 cgroup v2：
 
 ```bash
 $ mount | grep cgroup2
 ```
 
-如果输出包含 `cgroup2`，则系统已支持 cgroup v2。对于仍在使用 cgroup v1 的系统（如较旧的 RHEL 8），需要升级内核或更新系统配置。
+如果输出包含 `cgroup2`，则系统已支持 cgroup v2。对于仍在使用 cgroup v1 的系统（如较旧的 RHEL 8），建议升级内核或更新系统配置以启用 cgroup v2。
 
 #### 禁用 swap：必须
 

14_kubernetes_setup/14.2_kubeadm-docker.md

@@ -122,13 +122,13 @@ $ sudo yum install -y kubelet kubeadm kubectl
 
 #### cgroup v2 要求：必须
 
-Kubernetes v1.36 要求节点使用 cgroup v2（不再支持 cgroup v1）。kubelet 在 cgroup v1 节点上会拒绝启动。验证节点是否支持 cgroup v2：
+Kubernetes v1.36 默认要求节点使用 cgroup v2。kubelet 在 cgroup v1 节点上默认会拒绝启动，但管理员可以在 kubelet 配置中设置 `failCgroupV1: false` 来兼容 cgroup v1（仅建议用于遗留系统过渡期）。验证节点是否支持 cgroup v2：
 
 ```bash
 $ mount | grep cgroup2
 ```
 
-如果输出包含 `cgroup2`，则系统已支持 cgroup v2。对于仍在使用 cgroup v1 的系统（如较旧的 RHEL 8），需要升级内核或更新系统配置。
+如果输出包含 `cgroup2`，则系统已支持 cgroup v2。对于仍在使用 cgroup v1 的系统（如较旧的 RHEL 8），建议升级内核或更新系统配置以启用 cgroup v2。
 
 #### 加载内核模块
 

15_etcd/15.2_install.md

@@ -51,7 +51,7 @@ $ ETCDCTL_API=3 etcdctl member list
 $ ETCDCTL_API=3 etcdctl put testkey "hello world"
 OK
 
-$ etcdctl get testkey
+$ ETCDCTL_API=3 etcdctl get testkey
 testkey
 hello world
 ```
@@ -96,5 +96,5 @@ $ brew install etcd
 
 $ etcd
 
-$ etcdctl member list
+$ ETCDCTL_API=3 etcdctl member list
 ```

15_etcd/15.4_etcdctl.md

@@ -16,7 +16,7 @@ USAGE:
 	etcdctl
 
 VERSION:
-	3.5.21
+	3.5.29
 
 API VERSION:
 	3.5

18_security/18.6_image_security.md

@@ -270,7 +270,16 @@ cosign verify myregistry.com/myapp:v1.0.0 \
 
 #### Docker Content Trust 与 Notary
 
-Docker Content Trust 使用 Notary 实现镜像签名，是 Docker 官方的签名解决方案。
+> **注意：DCT 退役时间线**
+>
+> Docker 已宣布[退役 Content Trust](https://www.docker.com/blog/retiring-docker-content-trust/)。关键节点：
+> - 2025 年 8 月起：最早一批 DCT 签名证书开始过期
+> - 2025 年 9 月 30 日起：新注册表不可再启用 DCT
+> - **2028 年 3 月 31 日**：DCT 完全移除，所有 DCT 数据永久删除
+>
+> 建议新项目直接使用上文介绍的 **Cosign (Sigstore)** 进行镜像签名；现有 DCT 用户应尽早制定迁移计划。
+
+Docker Content Trust 使用 Notary 实现镜像签名，是 Docker 官方的传统签名解决方案。
 
 **启用 DCT：**
 
@@ -411,13 +420,13 @@ jobs:
 
     steps:
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v6
 
     - name: Set up Docker Buildx
-      uses: docker/setup-buildx-action@v3
+      uses: docker/setup-buildx-action@v4
 
     - name: Build Docker image
-      uses: docker/build-push-action@v6
+      uses: docker/build-push-action@v7
       with:
         context: .
         push: false
@@ -467,7 +476,7 @@ jobs:
         password: ${{ secrets.GITHUB_TOKEN }}
 
     - name: Push image
-      uses: docker/build-push-action@v6
+      uses: docker/build-push-action@v7
       with:
         context: .
         push: true

19_observability/19.1_prometheus.md

@@ -60,7 +60,7 @@ rule_files:
 ```yaml
 services:
   prometheus:
-    image: prom/prometheus:v3.11.0
+    image: prom/prometheus:v3.11.2
     volumes:
       - ./prometheus.yml:/etc/prometheus/prometheus.yml
       - ./rules.yml:/etc/prometheus/rules.yml
@@ -245,7 +245,7 @@ receivers:
 
 ```yaml
   alertmanager:
-    image: prom/alertmanager:v0.27.0
+    image: prom/alertmanager:v0.32.0
     volumes:
       - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
     ports:

19_observability/19.3_performance_optimization.md

@@ -164,12 +164,12 @@ scrape_configs:
 **完整监控栈部署：**
 
 > [!TIP]
-> 以下示例中的镜像标签（如 `prom/prometheus:v3.11.0`、`prom/node-exporter:v1.11.1`、`ghcr.io/google/cadvisor:v0.56.2`、`grafana/grafana:13.0.1`）仅为参考。在生产环境部署前，请访问各项目的官方发布页或文档获取最新版本号。
+> 以下示例中的镜像标签（如 `prom/prometheus:v3.11.2`、`prom/node-exporter:v1.11.1`、`ghcr.io/google/cadvisor:v0.56.2`、`grafana/grafana:13.0.1`）仅为参考。在生产环境部署前，请访问各项目的官方发布页或文档获取最新版本号。
 
 ```yaml
 services:
   prometheus:
-    image: prom/prometheus:v3.11.0
+    image: prom/prometheus:v3.11.2
     container_name: prometheus
     ports:
       - "9090:9090"