mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 16:37:34 +00:00
更新 Namespace/Gateway API/nftables/DCT 退役时间线
- 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 完全移除）和迁移建议
This commit is contained in:
yeasy
@@ -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 转换层。生产环境请谨慎使用。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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 等安全容器方案。
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
@@ -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：**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user