3. SPIRE 架构：SPIRE Server、SPIRE Agent、节点与工作负载注册

SPIRE（SPIFFE Runtime Environment）是 SPIFFE 规范的生产级参考实现。在服务网格的版本回滚场景中，SPIRE 负责为每个工作负载实例颁发唯一的 SPIFFE ID，并确保该身份在节点迁移、Pod 重启或版本切换时仍然可信。理解 SPIRE 的架构组件及其注册流程，是构建版本差异校验护栏的基础。

3.1 核心组件与职责

SPIRE 采用两层架构：SPIRE Server 作为全局身份控制面，SPIRE Agent 作为节点级身份代理。两者通过 gRPC 通信，共同完成节点和工作负载的身份注册与证书签发。

3.2 SPIRE 架构交互流程

下图展示了 SPIRE Server、SPIRE Agent 与工作负载之间的身份注册与 SVID 签发流程：

3.3 节点注册流程

节点注册是工作负载注册的前提。SPIRE Agent 启动后，必须首先向 SPIRE Server 证明自己的节点身份。Kubernetes 环境下，节点注册通常基于 PSAT（Projected Service Account ） 或 JWT-SVID 方式。

1. Agent 启动：读取配置文件中的 join_ 或节点凭证。
2. 节点挑战：Agent 向 Server 发起节点认证请求，附带节点凭证（如 K8s Node 的 SA ）。
3. Server 验证：Server 调用节点验证器（Node Attestor）验证凭证有效性，确认节点身份。
4. 节点注册：验证通过后，Server 在注册条目数据库中创建或更新节点条目，并下发节点 SVID。
5. Agent 就绪：Agent 持有节点 SVID，开始监听 Workload API 的 UDS 套接字。

3.4 工作负载注册流程

工作负载注册是 SPIRE 的核心能力。每个工作负载（如 Envoy sidecar、业务容器）通过一组 选择器（Selector） 来定义身份。选择器是 SPIRE 区分不同版本工作负载的关键机制。

工作负载注册的典型步骤：

1. 定义注册条目：管理员通过 spire-server entry create 命令或 API 创建注册条目，指定 SPIFFE ID、父节点 ID、选择器集合。
2. Agent 匹配：SPIRE Agent 定期扫描节点上的进程/容器，根据选择器匹配工作负载。
3. CSR 请求：匹配成功后，Agent 代表工作负载向 Server 发起证书签名请求（CSR）。
4. Server 签发：Server 验证 CSR 来源（通过节点 SVID 签名），签发 SVID 并返回给 Agent。
5. 工作负载获取：工作负载通过 Workload API 获取 SVID，用于 mTLS 通信。

# 创建注册条目示例：为 reviews 服务 v1 版本注册 SPIFFE ID
spire-server entry create \
  --parentID spiffe://example.local/spire/agent/k8s_psat/node-worker-1 \
  --spiffeID spiffe://example.local/ns/default/sa/reviews-sa/v1 \
  --selector k8s:ns:default \
  --selector k8s:sa:reviews-sa \
  --selector k8s:label:version:v1

3.5 版本差异校验中的注册条目管理

在服务网格回滚护栏场景中，SPIRE 的注册条目管理需要支持 多版本共存 和 版本切换。以下是关键设计原则：

• 版本化 SPIFFE ID：在 SPIFFE ID 路径中嵌入版本信息，例如 spiffe://example.local/ns/default/sa/reviews/v1 和 .../v2，使身份与版本绑定。
• 选择器版本标签：使用 K8s 标签选择器（如 version: v1）区分不同版本的工作负载，避免依赖容器镜像名。
• 注册条目优先级：当同一工作负载匹配多个注册条目时，SPIRE 根据条目创建时间或显式优先级决定使用哪个条目。
• 回滚时的条目更新：回滚操作应触发注册条目的更新或切换，确保回滚后的工作负载获得正确的 SPIFFE ID。

3.6 SPIRE 架构在回滚护栏中的角色总结

下表总结了 SPIRE 各组件在版本差异校验中的具体职责：

通过 SPIRE 的注册条目机制，服务网格可以在回滚时精确控制每个工作负载实例的身份，从而在版本差异校验中提供可信的身份基础。