diff --git a/13_kubernetes_concepts/13.4_advanced.md b/13_kubernetes_concepts/13.4_advanced.md
index baad36f..9b6d967 100644
--- a/13_kubernetes_concepts/13.4_advanced.md
+++ b/13_kubernetes_concepts/13.4_advanced.md
@@ -10,51 +10,16 @@
 *   **版本管理**：轻松回滚应用的发布版本。
 *   **模板化**：支持复杂的应用部署逻辑配置。
 
-### 13.4.2 Gateway API 与 Ingress
+### 13.4.2 Ingress - 服务的入口
 
-Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。集群需要 7 层 (HTTP/HTTPS) 路由能力来充当网关。
+Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress** 提供了 7 层 (HTTP/HTTPS) 路由能力，充当集群的网关。
 
-#### 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 将请求转发。
+*   **域名路由**：基于 Host 将请求转发不同服务 (api.example.com -> api-svc，web.example.com -> web-svc)。
+*   **路径路由**：基于 Path 将请求转发 (/api -> api-svc， / -> web-svc)。
 *   **SSL/TLS**：集中管理证书。
 
+常见的 Ingress Controller 有 Nginx Ingress Controller，Traefik，Istio Gateway 等。
+
 ### 13.4.3 Persistent Volume 与 StorageClass
 
 容器内的文件是临时的。对于有状态应用 (如数据库)，需要持久化存储。
@@ -94,23 +59,3 @@ 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
-```
diff --git a/18_security/18.6_image_security.md b/18_security/18.6_image_security.md
index 16cacb3..8d16778 100644
--- a/18_security/18.6_image_security.md
+++ b/18_security/18.6_image_security.md
@@ -270,16 +270,7 @@ cosign verify myregistry.com/myapp:v1.0.0 \
 
 #### Docker Content Trust 与 Notary
 
-> **注意：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 官方的传统签名解决方案。
+Docker Content Trust 使用 Notary 实现镜像签名，是 Docker 官方的签名解决方案。
 
 **启用 DCT：**