容器化 2025：为什么 containerd 2.0 和 eBPF 正在改变一切

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Simplified Chinese translation while preserving the source link, formatting, markdown, and any code blocks or URLs unchanged.

容器化全景 – 2024 → 2025

容器化生态系统始终充满活力，2024 年底至 2025 年期间出现了一系列实用且坚固的进步。作为资深开发者，我们已经走出“炒作周期”，深入实际，评估能够带来切实运营收益并解决真实约束的特性。过去一年巩固了以下趋势：

• 供应链安全的增强
• 运行时效率的根本提升
• 多架构部署的构建易用性显著跃进
• WebAssembly 作为特定工作负载的可信（但仍新兴）替代方案的出现

下面深入探讨真正重要的进展。

1. 容器运行时 – containerd 2.0

作为容器化世界的基石，容器运行时在 2024 年底发布的 containerd 2.0 中实现了巨大的演进。这不仅是一次增量升级；它是 1.0 版发布七年后对核心能力的战略性稳定与增强。

• Kubernetes v1.24 中对 dockershim 的移除，使 containerd 与 CRI‑O 成为焦点，巩固了 容器运行时接口（CRI） 作为 kubelet 与底层运行时之间的标准交互协议。

稳定通道的关键特性

示例用例 – 通过 NRI 实现 CPU 绑定
某组织需要对性能关键工作负载强制特定的 CPU 绑定。NRI 插件可以在容器启动时进行调解，确保在不同节点类型上保持一致的应用，而无需修改 containerd 守护进程的核心代码。

2. 镜像签名 – Sigstore 成为领头羊

2025 年标志着容器镜像签名的决定性转折。Sigstore 已牢固确立为软件供应链安全的开放标准，而 Docker 在 2025 年 8 月正式开始退役基于 Notary v1 的 Docker Content Trust（DCT）。

Sigstore 工作流（使用 Mermaid 绘制）

graph TD
    A["📥 OIDC Identity"] --> B{"🔍 Fulcio Check"}
    B -->|Valid| C["⚙️ Issue Certificate"]
    B -->|Invalid| D["🚨 Reject Request"]
    C --> E["📊 Sign & Log (Rekor)"]
    D --> F["📝 Audit Failure"]
    E --> G(("✅ Image Signed"))
    F --> G

    classDef input fill:#6366f1,stroke:#4338ca,color:#fff
    classDef process fill:#3b82f6,stroke:#1e40af,color:#fff
    classDef success fill:#22c55e,stroke:#15803d,color:#fff
    classDef error fill:#ef4444,stroke:#b91c1c,color:#fff
    classDef decision fill:#8b5cf6,stroke:#6d28d9,color:#fff
    classDef endpoint fill:#1e293b,stroke:#475569,color:#fff

    class A input
    class C,E process
    class B decision
    class D,F error
    class G endpoint

Sigstore 组件

Source: …

签名事件 |

这个三位一体实现了 无密钥签名：开发者使用来自其身份提供者（GitHub、Google 等）的 OIDC 令牌，从 Fulcio 获取临时签名证书。Cosign 使用该证书对镜像进行签名，签名（连同证书）被记录在不可变的 Rekor 日志中。

使用无密钥进行镜像签名与验证

# 1️⃣ 使用你的 OIDC 提供者进行身份验证
# （Cosign 通常会自动从环境变量中读取此信息。）

# 2️⃣ 对镜像进行签名（无密钥）
cosign sign --yes /:

# 3️⃣ 验证镜像
cosign verify /:

• --yes 标志会跳过交互式提示——这对 CI/CD 流水线至关重要。
• cosign verify 会查询 Rekor，以确保签名的真实性和完整性，并将其关联回可验证的身份。这在容器启动之前就提供了强大的供应链级别保证。

3. 对团队的意义

4. TL;DR

• containerd 2.0 引入 NRI、稳定的镜像验证插件以及简化的配置迁移。
• Sigstore 已成为镜像签名的事实标准；Docker 的 DCT 正在退役。
• 使用 Cosign/Fulcio/Rekor 的无密钥签名让你在无需管理长期密钥的情况下获得可验证的来源信息。
• 摒弃 aufs，拥抱新运行时特性，将同时提升安全姿态和性能。

敬请关注——2025 年将继续在 WebAssembly 运行时和多架构构建流水线等方面进行细化，但今年奠定的基础已经在重新塑造我们大规模交付和运行容器的方式。

Source: …

Docker Buildx 与 BuildKit

Docker 的 Buildx，由 BuildKit 后端提供支持，已经成熟为任何严肃容器开发工作流中不可或缺的工具，尤其在多平台镜像构建和缓存策略方面表现突出。

传统的 docker build 命令虽然可用，但常常受到性能瓶颈和跨架构支持有限的制约。BuildKit 通过使用 有向无环图 (DAG) 来重新构建构建过程，使得独立步骤可以并行执行，并提供更强大的缓存机制。

为什么多平台构建很重要

突出的特性——多平台构建——不再是小众功能，而是在快速向 amd64、arm64 甚至 arm/v7 架构多元化的世界中的实际需求。buildx 允许使用单个 docker buildx build 命令生成包含多个目标平台镜像的 manifest list，从而无需为每个平台准备单独的构建环境。

示例 Dockerfile

# Dockerfile
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/my-app ./cmd/server

FROM --platform=$BUILDPLATFORM alpine:3.18
COPY --from=builder /app/my-app /usr/local/bin/my-app
CMD ["/usr/local/bin/my-app"]

为多个平台构建并推送

docker buildx create --name multiarch-builder --use
docker buildx inspect --bootstrap
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myregistry/my-app:latest \
  --push .

缓存优势

• 本地层缓存 – 标准 Docker 行为。
• 注册表缓存 – 之前推送的层会在后续构建中复用，显著缩短频繁更新项目的构建时间。
• CI/CD 影响 – 对于构建环境是临时的场景尤为有价值。

eBPF 在 Kubernetes 网络与可观测性中的应用

eBPF（extended Berkeley Packet Filter） 已从实验性的好奇心转变为 2024 年底和 2025 年的基础技术，深入整合到 Kubernetes 的网络和可观测性栈中。eBPF 允许沙箱程序直接在 Linux 内核中运行，并由各种事件触发，提供前所未有的性能和灵活性，且无需传统的内核‑用户空间上下文切换开销。

网络

• CNI 插件 如 Cilium 和 Calico 现在都利用 eBPF，取代或提供比基于 iptables 的方案更优的替代方案。
• 效率 – eBPF 程序在内核网络栈的早期阶段做路由和策略决策，降低 CPU 开销和延迟，尤其在大规模集群中表现突出。

可观测性

• 通过将 eBPF 程序附加到系统调用、网络事件和进程活动，开发者可以实时从内核捕获详细的遥测数据。
• 工具 – 例如 Cilium Hubble 使用 eBPF 监控网络流量，公开服务间通信的延迟、字节计数以及策略执行决策。

Source: …

服务器端的 WebAssembly (Wasm)

WebAssembly 最初是为浏览器而构思的，但它已经无可否认地跨越了鸿沟，进入了服务器端和云原生环境，并在 2025 年为特定使用场景提供了相较传统容器的有力替代方案。其核心优势——极快的启动时间、微小的体积以及强大的沙箱安全性——使其在无服务器函数和边缘计算中尤为具有吸引力。

运行时生态（2025）

• Node.js、Deno、Bun 等运行时正在演进，以原生支持 Wasm。
• 冷启动 差异：Wasm 模块在 毫秒 级别启动，而典型容器的冷启动需要 秒 级别。

在 Kubernetes 中运行 Wasm

Kubernetes 通过 CRI 兼容的运行时和 shim 调度 Wasm 模块。像 runwasi 这样的项目提供了一个 containerd shim，使 Kubernetes 能够像对待普通 Pod 那样处理 Wasm 工作负载。

示例：使用 crun 部署 Wasm 应用

# runtimeclass.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasm-crun
handler: crun
---
# wasm-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-demo
  annotations:
    module.wasm.image/variant: compat
spec:
  runtimeClassName: wasm-crun
  containers:
  - name: my-wasm-app
    image: docker.io/myuser/my-wasm-app:latest
    command: ["/my-wasm-app"]

Source: …

Kubernetes API 弃用与移除

Kubernetes 持续优化其 API 表面，以引入新功能并淘汰已弃用的特性。2024 年底至 2025 年期间，监控 API 弃用和移除仍是关键的运维任务。项目遵循在 Alpha → Beta → GA 各阶段的明确弃用政策。

为什么重要

• 自 v1.19 起，对已弃用的 REST API 的任何请求都会返回警告。
• 自动化工具和 CI/CD 流水线检查对于识别使用了已弃用 API 的资源至关重要。

示例：查找使用 extensions/v1beta1 API 的 Deployment

kubectl get deployments.v1.apps -A \
  -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" \
  | grep "extensions/v1beta1"

主动迁移

• 在升级窗口之前 提前规划 迁移。
• 重要发行版：v1.34（2025 年 8 月） 和 v1.31（2024 年 7 月） 均引入了需要关注的弃用和移除。

运行时安全的进展

虽然漏洞扫描仍然是基本的最佳实践，但最近的进展侧重于在运行时层面加强安全原语。containerd 2.0 的一项重要进展是 im（源文档内容被截断）。

容器安全与开发者工具 2025

User Namespaces – 容器现在可以在容器内部以 root 身份运行，同时在宿主机上映射到非特权 UID。这大幅降低了容器逃逸的影响范围。

运行时安全

• 基于 eBPF 的解决方案 提供对容器行为的实时可视化，标记异常和策略违规。
• 最小特权强制：
  • 删除不必要的 Linux 能力（例如 CAP_NET_ADMIN）。
  • 尽可能使用只读文件系统。

开发者工具改进

对于高级开发者而言，这些渐进但稳健的改进意味着更实用、更安全且更高效的工作流。

有用链接

• 个人站点：

  • henrikgerdes.me
  • karp.dev
  • github.io
  • dev.to
  • kubernetes.io

• DataFormatHub 工具（与主题相关）：

  • YAML to JSON – 转换 Kubernetes 清单
  • JSON Formatter – 格式化容器配置

• 近期文章：

  • dbt 与 Airflow 2025：为何这些数据巨头正在重新定义工程
  • AWS Lambda 与 S3 Express One Zone：2025 年对 re:Invent 2023 的深度解析
  • GitHub Actions 与 Codespaces：为何是 2025

本文最初发布在 DataFormatHub，您获取数据格式和开发者工具洞见的首选资源。