3. IDP 自助门户蓝图概述

在 Kubernetes 与 IDP 的集成体系中，蓝图（Blueprint）是连接开发者自助操作与平台工程治理的核心契约。它既不是简单的模板文件，也不是一成不变的配置快照，而是一个具备版本、门禁和回滚能力的可执行部署定义。本节将系统阐述蓝图的定义、与模板的本质区别，以及在自助服务中的具体角色。

3.1 蓝图的定义

蓝图是对一个完整应用环境的声明式描述，它封装了以下三类信息：

• 基础设施拓扑：Namespace、NetworkPolicy、StorageClass、Ingress 等 Kubernetes 资源的定义。
• 运行时配置：环境变量、ConfigMap、Secret、资源配额（Requests/Limits）等应用级参数。
• 变更策略：允许的更新路径、回滚触发条件、审批门禁规则（与第 5 章门禁引擎联动）。

3.2 蓝图与模板的区别

很多团队会将蓝图与 Helm Chart 或 Kubernetes 模板混为一谈。下表从六个维度明确区分：

3.3 蓝图在自助服务中的角色

在 IDP 自助门户中，蓝图扮演了三个核心角色：

1. 自助服务目录的原子单元：开发者从门户的“服务目录”中选择一个蓝图（如“Spring Boot 微服务 + PostgreSQL”），填写少量参数即可发起部署请求。蓝图封装了所有底层复杂性。
2. 变更门禁的执行边界：每次对蓝图实例的修改（如升级镜像、调整副本数）都会触发门禁引擎。蓝图版本号决定了当前变更是否合规、是否需要审批、是否触发自动回滚。
3. 回滚判断的决策依据：当门禁检查失败或运行时健康检查异常时，平台根据蓝图的回滚策略（如“回滚到上一版本”或“回滚到指定基线版本”）自动执行恢复操作。回滚不是简单的重新部署，而是基于蓝图版本的差异计算。

3.4 蓝图版本与回滚基线

每个蓝图实例在 IDP 中维护一个版本链，典型结构如下：

回滚判断的核心逻辑是：当新版本（如 v1.2.1）门禁失败时，平台自动计算当前版本与最近一个通过门禁的基线版本之间的差异，执行逆向变更。这个基线版本由蓝图定义中的 rollbackBaseline 字段指定，或默认取上一个通过门禁的版本。

# 蓝图定义示例 (blueprint.yaml)
apiVersion: idp.example.com/v1
kind: Blueprint
metadata:
  name: order-service-blueprint
  version: v1.2.0
spec:
  rollbackBaseline: v1.1.0          # 指定回滚基线
  gatePolicies:
    - name: image-signature-check
      action: block                  # 门禁失败时阻止部署
      autoRollback: true            # 自动回滚到基线
  resources:
    - helmChart: order-service
      values:
        replicaCount: 3
        image: registry.example.com/order:1.2.0
    - helmChart: postgresql
      values:
        storageSize: 50Gi