Update Gateway API docs and image security practices

- 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 完全移除）和迁移建议

07_dockerfile/7.18_multistage_builds_laravel.md

@@ -230,7 +230,6 @@ RUN set -x ; cd ${LARAVEL_PATH} \
       && php artisan package:discover
 
 FROM nginx: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 addr add 172.17.0.99/16 dev eth0
-$ sudo ip netns exec $pid ip route add default via 172.17.42.1
+$ 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)。
+#### Gateway API（推荐）
-*   **路径路由**：基于 Path 将请求转发 (/api -> api-svc， / -> web-svc)。
+
+> **重要**：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.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

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"