4. 门禁系统架构设计：门禁组件与部署模式
多集群变更门禁的核心在于将策略执行点从人工审批迁移至自动化管道。本章聚焦门禁系统的三大核心组件——Webhook、Policy Engine、Audit Log，以及两种主流部署模式——Sidecar 与 Agentless。理解这些组件的职责与部署拓扑，是后续环境移植适配的基础。
4.1 门禁组件职责与交互流程
门禁系统采用“拦截-评估-记录”三段式架构。每个组件独立部署、职责单一，通过标准 API 进行通信。
| 组件 | 核心职责 | 输入 | 输出 | 关键指标 |
|---|---|---|---|---|
| Webhook | 拦截变更请求，提取上下文并转发至 Policy Engine | K8s AdmissionReview / Git Push Event | AdmissionResponse / 阻断或放行信号 | P99 延迟 < 50ms |
| Policy Engine | 加载策略规则，执行评估并返回决策 | 请求上下文 + 策略 Bundle | Pass / Warn / Deny + 理由 | 评估吞吐 > 1000 req/s |
| Audit Log | 持久化所有变更事件与决策结果，提供可审计追溯 | 决策记录 + 原始请求 | 结构化日志（JSON/Parquet） | 写入延迟 < 200ms |
设计原则：Webhook 只做“拦截与转发”，不包含任何业务策略逻辑；Policy Engine 只做“评估”，不负责持久化；Audit Log 只做“记录”，不参与决策。这种解耦使得每个组件可以独立扩缩容与版本升级。
4.2 门禁组件交互架构
下图展示了变更请求从进入集群到完成审计的完整数据流。三个组件通过异步消息队列与同步 gRPC 调用协同工作。
4.3 部署模式对比：Sidecar vs Agentless
在多集群场景下，门禁组件的部署方式直接影响资源消耗、运维复杂度与安全边界。两种模式各有适用场景。
| 维度 | Sidecar 模式 | Agentless 模式 |
|---|---|---|
| 部署形态 | 每个目标 Pod 注入一个门禁 Sidecar 容器 | 集群级 DaemonSet 或独立 Service 统一代理 |
| 资源开销 | 每 Pod 额外 50-100m CPU / 128-256Mi 内存 | 每集群固定 2-4 副本，总开销更低 |
| 隔离性 | 强隔离，Sidecar 故障不影响其他 Pod | 共享代理，单点故障影响面较大 |
| 策略粒度 | 可针对每个工作负载定制策略注入 | 策略作用于集群/命名空间级别 |
| 运维复杂度 | 需管理 Sidecar 注入与版本同步 | 集中管理，升级简单 |
| 适用场景 | 金融核心、合规敏感、多租户隔离 | 开发测试、标准化策略、资源受限集群 |
移植适配建议：在环境移植过程中，优先采用 Agentless 模式降低初始部署复杂度；待策略体系稳定后，再对核心生产集群逐步切换至 Sidecar 模式以获得更强的隔离保障。
4.4 Sidecar 模式部署拓扑
Sidecar 模式下，每个工作负载 Pod 内运行一个门禁代理容器，负责拦截该 Pod 的入站/出站变更请求。策略评估在本地完成，仅审计日志异步上报至中心存储。
4.5 Agentless 模式部署拓扑
Agentless 模式在集群中部署一个独立的门禁代理服务（通常以 DaemonSet 或 Deployment 形式运行），所有 Pod 的变更请求通过集群内部的 Service 路由至该代理进行统一评估。
- 数据流路径：业务 Pod → 集群 DNS → 门禁代理 Service → Policy Engine → 决策返回
- 优势：零侵入，无需修改业务 Pod 定义；资源集中，适合大规模集群的标准化策略管控
- 风险：代理成为关键路径，需配置 HPA 与 PDB 保证高可用；策略粒度受限，难以针对单个 Pod 做差异化
移植适配风险提示：Agentless 模式下，门禁代理的 Service 名称与端口在不同集群环境（如自建 K8s、EKS、ACK）中可能不一致。环境移植时需将代理地址抽象为配置项，避免硬编码。建议使用 CoreDNS 的
rewrite 插件或 Service Mesh 的流量劫持能力统一入口。
4.6 组件部署决策矩阵
在实际的多集群门禁建设中，通常混合使用两种模式。以下决策矩阵帮助根据集群特征选择部署策略：
| 集群特征 | 推荐模式 | 理由 |
|---|---|---|
| 生产核心集群，多租户隔离 | Sidecar | 强隔离，故障域最小化，审计粒度精细 |
| 开发测试集群，快速迭代 | Agentless | 部署简单，策略变更即时生效，资源开销低 |
| 边缘集群，资源受限 | Agentless | 避免 Sidecar 带来的额外资源消耗 |
| 合规审计集群，需全量记录 | Sidecar | 本地审计队列保证不丢事件，异步上报不影响业务 |
| 混合集群，部分工作负载敏感 | 混合模式 | 敏感工作负载注入 Sidecar，其余走 Agentless |
架构总结：门禁系统的组件设计遵循“拦截-评估-记录”三段解耦原则，Webhook 负责边界拦截，Policy Engine 专注策略评估，Audit Log 保证可追溯。部署模式上，Sidecar 提供强隔离但增加资源开销，Agentless 简化运维但牺牲粒度。环境移植适配的核心在于将组件间的通信地址、策略分发机制、审计上报路径抽象为可配置的适配层，而非硬编码在代码中。