From 9de6b523c4d11b8a761cb413717eb9e01128788d Mon Sep 17 00:00:00 2001 From: yeasy Date: Sun, 26 Apr 2026 00:18:39 +0000 Subject: [PATCH] Update Gateway API docs and image security practices --- 13_kubernetes_concepts/13.4_advanced.md | 67 ++++++++++++++++++++++--- 18_security/18.6_image_security.md | 11 +++- 2 files changed, 71 insertions(+), 7 deletions(-) diff --git a/13_kubernetes_concepts/13.4_advanced.md b/13_kubernetes_concepts/13.4_advanced.md index 9b6d967..baad36f 100644 --- a/13_kubernetes_concepts/13.4_advanced.md +++ b/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 +``` diff --git a/18_security/18.6_image_security.md b/18_security/18.6_image_security.md index 8d16778..16cacb3 100644 --- a/18_security/18.6_image_security.md +++ b/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:**