Lineage驱动的多站点基础设施管理：构建可追溯、可审计、可复用的IaC范式

1. 项目概述这不是简单的“多站点管理”而是用Lineage构建可复用的基础设施DNA你有没有遇到过这样的场景手头同时维护着5个客户部署每个都跑着同一套核心业务系统但数据库名、API网关地址、SSL证书路径、日志轮转策略、监控告警阈值却各不相同每次上线新功能得挨个登录服务器改配置、手动执行SQL脚本、反复核对Nginx虚拟主机文件——改错一个整条交付线就卡住。更糟的是某次紧急热修复后忘了同步到测试环境结果预发验证通过生产一上线就报502。这种“配置漂移”带来的运维熵增不是靠加班能解决的而是系统性设计缺陷的必然结果。“Multisite Management using Lineage (PC14 Recap)”这个标题里藏着三个关键信号Multisite指的不是网站多语言切换而是指同一套软件在多个物理或逻辑隔离环境中的并行部署比如华东集群、华南集群、金融云专有区、客户私有IDCLineage不是血缘关系而是指一种以“变更溯源”和“依赖图谱”为内核的基础设施即代码IaC范式而PC14则明确指向了2023年Cloud Native Computing FoundationCNCF年度技术峰会中关于“可验证基础设施”的核心议题编号——这意味着它不是某个小众工具的技巧分享而是当前云原生领域应对规模化交付挑战的主流工程实践。我从2018年开始在金融级SaaS产品线做交付架构亲手把一套风控引擎从单体部署扩展到覆盖17个省级政务云节点。踩过的最大坑就是早期用Ansible写了一堆“playbook”每个客户目录下放一份vars.yml结果三年后没人敢动common_role里的一个JVM参数——因为没人知道哪个客户的site.yml里悄悄覆盖了它。后来我们彻底重构核心就是引入Lineage思维把每个站点看作一个“基因型”Genotype把运行时状态看作“表型”Phenotype而Lineage就是记录每一次“基因编辑”配置变更、版本升级、安全补丁如何影响最终“表型”的完整链条。这篇文章不讲抽象理论只说我们怎么用这套方法在6个月内把客户交付周期从平均22天压缩到3.8天且零配置相关P1事故。如果你正被多环境一致性问题折磨或者团队还在用Git分支管理不同客户配置那接下来的内容就是你该抄的作业。2. 核心设计思路拆解为什么放弃“环境分支”选择“Lineage驱动”的基础设施演进模型2.1 传统方案的三大死结与Lineage的破局点先说清楚我们抛弃了什么。业内常见的多站点管理方案主要有三类每种都在我们生产环境里真实跑过也真实翻过车Git分支模式为每个客户建一个feature/customer-a分支所有配置、模板、脚本都放在分支里。问题在于当主干修复了一个Kubernetes Ingress的TLS握手bug你需要手工把修复patch cherry-pick到17个分支漏掉一个那个客户就会在证书更新日集体失联。我们统计过2021年Q3的12次线上故障中7次根因是分支同步遗漏。配置中心外挂模式用Apollo/Nacos统一管配置应用启动时拉取。这解决了运行时配置动态化但埋下了更隐蔽的雷——配置中心本身成了单点故障且无法回答“这个配置项在2023-09-15 14:22:03被谁修改依据哪个需求文档影响了哪些服务实例”这类审计刚需。某次等保测评监管方要求提供某敏感字段的全生命周期变更记录我们花了3天时间人工拼凑日志最后还是被开了不符合项。Helm Chart参数化模式用values.yaml区分环境。看似优雅实则脆弱。当values-production.yaml里定义了replicaCount: 5而values-staging.yaml里写replicaCount: 2表面看没问题。但一旦业务增长需要把生产副本数提升到8你必须同时修改Chart模板里的resources.limits.cpu计算逻辑否则Pod会因CPU配额不足被OOMKilled。这种隐式耦合让参数不再是“变量”而成了“硬编码陷阱”。Lineage模型的破局本质是把“配置”升维成“事件”。它不关心你最终要多少个副本而是记录“2023-10-01根据RFC-2023-001《华东区扩容方案》将web-service的replicaCount从5调整为8触发hpa-min-replicas联动更新影响范围prod-shanghai、prod-hangzhou两个站点”。这个事件本身自带上下文、责任人、审批链路、回滚预案。这才是可审计、可追溯、可自动化的根基。2.2 Lineage的核心组件不是工具而是工作流契约很多人误以为Lineage是某个叫“Lineage”的开源工具。实际上在PC14共识中Lineage是一种声明式工作流契约由三个不可分割的组件构成Site Manifest站点清单一个YAML文件定义站点的静态身份。它不包含任何运行时参数只描述“你是谁”。例如# site-manifests/shanghai-prod.yaml metadata: name: shanghai-prod lineageId: ln-7a3f9b21 # 全局唯一生成后永不变更 labels: region: east-china compliance: gb18030 tier: production spec: baseTemplate: template-v2.4.1 # 继承自哪个基线模板 overridePolicy: strict # 覆盖策略strict仅允许白名单字段/permissive关键点在于lineageId——它像DNA序列一样是站点在整个生命周期中的唯一指纹。哪怕你把整个上海生产环境重建只要lineageId不变所有历史变更记录、监控指标、审计日志依然能精准关联。Lineage Graph谱系图一张有向无环图DAG节点是“变更事件”边是“依赖关系”。比如事件A升级PostgreSQL到13.5触发事件B调整连接池参数事件B又触发事件C更新备份策略。这张图不是人工绘制的而是由CI/CD流水线在每次成功部署后自动解析Git提交信息、PR描述、Jira工单链接调用GraphQL API写入Neo4j图数据库生成的。我们用它实现“影响分析”当发现PostgreSQL 13.5存在一个已知内存泄漏bug只需查询MATCH (e:Event)-[:TRIGGERS*]-(v:Version {name:13.5}) RETURN e就能秒级列出所有受影响的站点及对应负责人。Reconciler Engine协调引擎这是真正的“大脑”。它持续监听Kubernetes API Server的资源变更同时比对Lineage Graph中该站点的最新期望状态desired state。一旦发现实际状态actual state与期望状态偏差超过阈值比如Pod Ready状态为False超过5分钟它不会直接执行修复而是生成一个RemediationEvent进入审批队列。只有当该事件被指定的安全组成员二次确认才会触发自动化修复脚本。这杜绝了“自动化越权操作”——2022年某大厂因自动化脚本误删生产数据库的事故根源就在于缺少这一层人类决策门禁。提示Lineage不是银弹。它要求团队接受一个反直觉原则“慢即是快”。每次配置变更必须走完整的Lineage事件创建流程平均耗时4分32秒看似拖慢了单次操作但换来的是全局稳定性的指数级提升。我们内部测算当站点数超过8个时Lineage模型的总人力运维成本开始低于传统模式。2.3 为什么选Lineage而非GitOps一次真实的选型辩论在立项初期团队曾激烈争论是否采用FluxCD/GitOps方案。最终选择Lineage是基于三个硬性约束的深度权衡合规审计刚性需求金融客户要求所有生产变更必须附带Jira需求号、安全扫描报告哈希值、三方渗透测试通过证明。GitOps的“配置即代码”模型天然难以将这些非代码资产与Git提交强绑定。而Lineage的Event Schema明确预留了auditEvidence字段支持上传PDF、JSON等多种格式的证据附件并自动生成数字签名。混合云网络拓扑复杂性我们的客户环境横跨阿里云、腾讯云、华为云及本地IDC各云厂商的VPC CIDR网段、安全组规则、NAT网关策略千差万别。GitOps依赖统一的Git仓库作为单一事实源但在网络策略这种强地域性配置上强行统一会导致模板臃肿一个network-policy.yaml文件长达2000行且80%的条件判断永远不生效。Lineage则允许为每个站点定义network-profile插件由Reconciler在部署时按需加载模板复用率反而从32%提升到79%。灰度发布粒度控制GitOps通常以“整个应用”为单位同步而Lineage支持event-scoped reconciliation。例如我们可以创建一个只影响shanghai-prod站点的FeatureFlagEvent它仅更新feature-flagsConfigMap中的payment-methods字段而不触碰其他任何资源。这种原子级控制是支撑我们“每日百次发布”的底层能力。这场辩论没有输赢只有适配。GitOps适合标准化程度高、变更频次低的场景Lineage则是为复杂、异构、强合规的多站点交付量身定制的手术刀。3. 核心细节与实操要点从零搭建Lineage工作流的7个生死关卡3.1 关卡一Lineage ID的生成与管理——别让DNA突变毁掉一切lineageId是整个体系的基石它的生成规则直接决定后续所有环节的稳定性。我们试过三种方案最终锁定第三种UUIDv4随机生成简单粗暴但无法保证语义可读性。当运维在Kibana里看到ln-8f3a9c21完全无法判断这是测试环境还是生产环境更别说区域信息。排查问题时光是确认站点身份就要额外消耗2分钟。命名空间哈希用{region}-{env}-{customer}字符串做SHA256哈希。解决了可读性但引入新风险——如果客户名称变更如“XX科技”收购“YY数据”后更名哈希值改变历史Lineage图就断裂了。我们曾因此丢失了某客户连续14个月的变更审计链。分层编码方案最终采用ln-{region-code}-{env-code}-{serial-4digit}-{checksum-2char} 示例ln-sh-prod-0023-7aregion-code上海sh北京bj深圳sz固定2字符避免拼音缩写歧义env-codeprodprodstagingstgdevdev强制小写避免大小写混淆serial-4digit按申请顺序递增由中央ID服务分配确保全局唯一且有序checksum-2char对前缀做Luhn算法校验码防止人工录入错误实操心得我们开发了一个轻量级Web UI50KB JS供交付经理在客户签约后自助申请Lineage ID。输入区域、环境、客户简称点击生成页面实时显示校验码并高亮错误。这个UI背后调用的是Consul KV存储的序列号服务所有请求都经过Rate Limiting5 QPS/人彻底杜绝了ID冲突。记住Lineage ID一旦分配终身不可变更。宁可废弃一个ID也不要重用。3.2 关卡二Site Manifest的Schema设计——拒绝“配置地狱”的第一道防火墙Manifest文件看似简单却是最容易失控的环节。我们初期犯的最大错误是把Manifest当成values.yaml的替代品塞进了大量运行时参数。结果导致Manifest体积膨胀版本diff变得毫无意义。正确的做法是Manifest只定义“身份”和“契约”不定义“行为”。我们最终收敛出一个极简但强大的Schema# site-manifests/shanghai-prod.yaml metadata: name: shanghai-prod lineageId: ln-sh-prod-0023-7a labels: region: east-china compliance: gb18030 tier: production business-unit: risk-control spec: # --- 身份契约 --- baseTemplate: template-risk-v2.4.1 # 必填继承的基线模板版本 overridePolicy: strict # 必填覆盖策略 # --- 安全契约 --- securityProfile: encryptionKeys: - name: data-encryption-key version: 2023-q3 rotationDate: 2023-10-01 networkZones: - dmz - app-tier - db-tier # --- 合规契约 --- complianceProfile: auditLogRetention: 365d pciDssLevel: level-1 dataResidency: shanghai # --- 扩展点仅允许在此处注入插件 --- plugins: - name: aliyun-vpc-plugin config: vpcId: vpc-xxxxxx natGatewayId: ngw-xxxxxx - name: custom-metrics-plugin config: prometheusScrapeInterval: 15s关键设计哲学baseTemplate强制版本化不允许latest或master。每次模板升级必须显式声明新版本号并触发全量回归测试。我们用GitHub Actions自动检测baseTemplate字段变更一旦发现立即阻断PR合并除非附带TEMPLATE_UPGRADE_TEST_REPORT.md。overridePolicy: strict是默认且唯一推荐选项它要求所有覆盖字段必须在基线模板的overrideWhitelist.yaml中明确定义。例如基线模板允许覆盖replicaCount但禁止覆盖image.tag——因为镜像标签应由CI流水线自动注入人工覆盖等于绕过安全扫描。这个白名单本身也是Lineage事件的一部分变更需走完整审批流。plugins是唯一合法的“特例处理”入口当某个客户有特殊需求如必须使用华为云专属DNS不能修改基线模板而是开发一个独立插件。插件代码存于plugins/子仓库通过plugin-name和version精确引用。这保证了基线模板的纯净性也让插件可被复用——后来我们发现7个客户都需要“等保2.0日志加密插件”直接复用同一个插件节省了23人日开发。注意Manifest文件本身不存敏感信息密码、密钥。所有密钥均通过外部密钥管理服务KMS注入Manifest中只存KMS密钥ID。这是等保三级的硬性要求也是我们通过ISO27001认证的关键证据。3.3 关卡三Lineage Graph的构建——让每一次变更都留下可追溯的“数字足迹”Graph不是静态图表而是动态演化的知识库。它的构建质量直接决定“影响分析”的准确率。我们踩过的坑几乎都源于事件采集的颗粒度不当。错误示范粗粒度事件早期我们把整个CI/CD流水线的成功执行当作一个事件。结果当shanghai-prod部署失败时Lineage Graph只显示“Event-12345: deploy failed”你根本不知道是Helm渲染失败、Kubernetes API超时还是PostgreSQL连接池耗尽。排查时间从5分钟拉长到47分钟。正确实践原子化事件链我们将一次部署拆解为7个原子事件每个事件独立生成Lineage ID并建立依赖关系事件类型触发条件关键字段依赖关系TemplateRenderHelm template命令成功chartVersion,valuesHash无依赖K8sApplykubectl apply --dry-run返回0resourceKind,resourceName依赖TemplateRenderHealthCheck自定义探针返回HTTP 200probeType,latencyMs依赖K8sApplyCanaryPromote灰度流量达标canaryTrafficPercent,errorRate依赖HealthCheck这样当shanghai-prod的HealthCheck事件失败我们能立刻定位到是service/web的/healthz端点超时进而关联到K8sApply事件中该Service的readinessProbe配置——原来initialDelaySeconds被误设为10秒而应用冷启动实际需要12秒。Graph数据存储在Neo4jSchema设计遵循“事件即节点动作即关系”原则// 创建事件节点 CREATE (e:Event { lineageId: ev-7a3f9b21-001, type: HealthCheck, timestamp: 2023-10-01T14:22:03Z, status: failed, details: {probeType: http, latencyMs: 15200} }) // 建立依赖关系 MATCH (prev:Event {lineageId: ev-7a3f9b21-000}), (e:Event {lineageId: ev-7a3f9b21-001}) CREATE (prev)-[:TRIGGERS]-(e)实操心得我们给每个事件类型配置了“失败熔断阈值”。例如HealthCheck事件连续3次失败Reconciler会自动暂停该站点的所有后续事件并发送企业微信告警给交付负责人。这比等待监控告警再人工介入快了整整8分钟——而这8分钟往往就是P0故障的黄金处置窗口。3.4 关卡四Reconciler Engine的“人类决策门禁”——自动化与可控性的终极平衡Reconciler不是无脑执行器而是“智能协作者”。它的核心设计原则是所有可能造成状态破坏的操作必须经过人类二次确认。我们定义了三类操作等级等级操作示例自动化策略人工确认方式L1无害操作更新ConfigMap内容、重启无状态Pod全自动执行无需确认仅邮件通知L2可逆操作扩容Deployment副本、调整HPA阈值自动执行但保留15分钟回滚窗口企业微信机器人推送30秒内回复“APPROVE”或“REJECT”L3高危操作删除StatefulSet、修改PersistentVolumeClaim、变更Ingress TLS证书仅生成RemediationEvent进入审批队列必须登录内部Portal用UKey进行数字签名确认关键实现细节L2级确认的防呆设计企业微信消息包含唯一confirmationCode如SH-PROD-20231001-7a3f。回复时必须包含此代码否则视为无效。且每个代码仅限使用1次超时30秒自动失效。这杜绝了“误触发送”和“重复确认”。L3级审批的强审计Portal审批页强制显示三项信息① 变更前后的YAML diff高亮差异② 该操作在过去30天内的执行记录是否有同类操作导致过故障③ 影响分析报告Lineage Graph查询结果列出所有关联站点。审批人必须勾选“已阅读并理解全部风险”才能提交。Reconciler的“心跳”机制它每30秒向Consul注册一次健康检查。如果连续3次心跳失败自动触发FailoverEvent将协调职责移交至备用Reconciler实例部署在另一可用区。我们用这种方式实现了99.99%的SLA。提示不要试图用技术手段绕过人类确认。我们曾尝试用“AI风险评分”替代人工审批模型给出“风险分30建议自动执行”结果一次误判导致生产数据库连接池被错误清空。教训是在关键基础设施领域人类的模糊判断力远胜于AI的精确计算力。3.5 关卡五基线模板Base Template的治理——让17个站点共享同一套“进化基因”基线模板是Lineage的心脏。它不是一堆Helm Chart的集合而是一个有严格版本控制、可组合、可验证的“基础设施基因库”。我们的模板仓库结构如下templates/ ├── risk-control-v2.4.1/ # 主版本目录 │ ├── chart/ # Helm Chart源码 │ ├── tests/ # 集成测试用例BATS框架 │ ├── schema/ # OpenAPI规范定义values.yaml结构 │ └── lineage/ # Lineage专用元数据 │ ├── overrideWhitelist.yaml # 允许覆盖的字段白名单 │ └── compatibilityMatrix.yaml # 与各K8s版本的兼容性声明 ├── risk-control-v2.4.2/ # 新版本仅当v2.4.1通过全量测试后才创建 └── common-libraries/ # 公共函数库Go模板、Shell脚本最关键的治理实践“不可变版本”原则risk-control-v2.4.1目录一旦Tag发布git tag -a v2.4.1 -m Release for PC14其内容永久冻结。任何Bug修复都必须发布v2.4.2而不是修改v2.4.1。这保证了Lineage Graph中所有引用v2.4.1的事件其上下文永远可重现。“测试即准入”机制每个新模板版本必须通过三级测试单元测试验证模板语法、变量引用、条件判断逻辑使用ct suite集成测试在Minikube集群中部署验证所有资源创建成功、健康检查通过BATS脚本合规测试调用Open Policy AgentOPA引擎校验生成的YAML是否符合PCI DSS、等保2.0策略如spec.containers[].securityContext.runAsNonRoot: true。“渐进式推广”策略新模板不会直接用于生产。流程是dev→staging→canary-prod1个客户→all-prod。每个阶段停留至少48小时并收集Reconciler上报的EventSuccessRate指标。只有当canary-prod的72小时成功率≥99.95%才允许进入下一阶段。实操心得我们给每个模板版本生成一个template-report.html自动包含测试覆盖率、安全扫描结果Trivy、性能基准部署耗时、资源占用、已知限制Known Issues。交付经理在为客户选择模板时不再凭经验而是看这份报告。这大幅降低了“选错版本”导致的返工。3.6 关卡六插件Plugin开发规范——让“特例”成为可复用的“通用能力”插件是Lineage应对现实世界复杂性的接口。但若无规范插件会迅速沦为新的技术债黑洞。我们强制所有插件遵守“三定律”第一定律插件即容器每个插件必须打包为Docker镜像入口点是/plugin/run.sh。它接收两个参数--manifest站点Manifest路径和--output-dir输出渲染后YAML的目录。插件不得修改任何外部系统只能生成YAML文件。这样插件的执行完全可预测、可审计、可回滚。第二定律契约先行插件开发前必须先提交plugin-spec.yaml到plugins/specs/目录经架构委员会评审通过。该文件定义name: aliyun-vpc-plugin version: 1.0.0 description: Configure Alibaba Cloud VPC-specific resources inputs: - name: vpcId type: string required: true - name: natGatewayId type: string required: false outputs: - resources/network/vpc.yaml - resources/network/nat-gateway.yaml compatibility: - template-risk-v2.4.1 - template-risk-v2.4.2第三定律沙箱执行Reconciler在调用插件时使用podman run --rm --network none --memory 512m --cpus 0.5启动容器挂载/tmp/plugin-input和/tmp/plugin-output两个临时卷。插件无法访问网络、无法读写宿主机文件系统、资源受限。这杜绝了恶意插件或Bug插件拖垮整个集群。我们已积累12个经过生产验证的插件包括aws-iam-role-plugin、azure-keyvault-plugin、custom-backup-schedule-plugin。其中custom-backup-schedule-plugin被9个客户复用它根据complianceProfile.backupSchedule字段自动生成Velero的Schedule资源精确到分钟级——这是基线模板无法覆盖的精细化需求。注意插件的版本号必须与基线模板版本号解耦。aliyun-vpc-plugin:v1.2.0可以同时兼容template-risk-v2.4.1和v2.4.2。这通过compatibility字段声明由Reconciler在运行时校验。3.7 关卡七监控与可观测性——用Lineage Graph本身做故障诊断Lineage不是黑盒它的Graph就是最强大的监控仪表盘。我们摒弃了传统“指标日志链路”的三支柱模型转而构建“Lineage即监控”体系。核心监控视图站点健康度仪表盘每个站点显示一个环形进度条颜色代表EventSuccessRate最近24小时成功事件占比。绿色≥99.9%、黄色99.5%-99.9%、红色99.5%。点击红色站点直接跳转到Lineage Graph中失败事件的详情页。变更影响热力图X轴是时间过去7天Y轴是站点列表格子颜色深浅表示该站点在该时间段内触发的L2/L3级事件数量。突然出现的深色区块往往预示着批量配置错误或上游依赖变更。谱系图谱搜索输入任意关键词如tls-certificate、postgres-13.5自动查询Graph中所有关联事件并按时间倒序排列。这是我们处理安全漏洞应急响应的标准动作——当CVE-2023-12345公布时10秒内就能列出所有受影响站点及对应负责人。技术实现上我们用Prometheus Exporter暴露Graph指标lineage_event_total{typeHealthCheck,statussuccess,siteshanghai-prod}lineage_reconciliation_duration_seconds{siteshanghai-prod,phaserender}lineage_plugin_execution_seconds{pluginaliyun-vpc-plugin,statussuccess}这些指标全部接入Grafana与Kubernetes原生指标同屏展示。当lineage_reconciliation_duration_seconds异常升高我们首先检查kube-apiserver的etcd_request_duration_seconds——因为Reconciler的瓶颈90%来自API Server延迟。实操心得我们给每个L3级事件生成一个唯一的incidentId并将其注入到所有关联的Kubernetes资源Annotation中。例如一次证书更新事件inc-7a3f9b21会让ingress/web资源带上lineage.incidentId: inc-7a3f9b21。这样当ingress出现503错误时kubectl get ingress web -o yaml就能立刻看到关联的Incident无需跨系统关联。这是真正的一体化可观测性。4. 实操过程详解从创建第一个站点到完成全量交付的完整流水线4.1 第一步初始化Lineage基础设施——5分钟搭建你的“基因实验室”所有操作均在Linux终端完成无需安装客户端。我们使用lineagectl这个轻量CLI5MB二进制文件它通过HTTPS调用Reconciler的REST API。环境准备假设你已有Kubernetes集群和Git仓库# 1. 下载lineagectl自动识别OS/Arch curl -sfL https://get.lineage.dev | sh -s -- -b /usr/local/bin # 2. 配置Reconciler连接指向你的Reconciler服务 lineagectl config set-context prod \ --reconciler-url https://reconciler.internal.company.com \ --ca-file /path/to/ca.crt \ --token $(cat ~/.lineage/token) # 3. 验证连接 lineagectl context use prod lineagectl status # 输出Reconciler Status: Healthy, Graph Nodes: 1247, Last Sync: 2023-10-01T14:22:03Z初始化基线模板仓库# 4. 克隆官方模板我们已为你准备好金融风控模板 git clone https://github.com/company/lineage-templates.git cd lineage-templates # 5. 发布首个基线版本v1.0.0 git checkout -b release/v1.0.0 git tag -a v1.0.0 -m Initial release for PC14 recap git push origin v1.0.0 # 6. 注册到Lineage系统让Reconciler知晓此模板 lineagectl template register \ --name risk-control-v1.0.0 \ --git-url https://github.com/company/lineage-templates.git \ --git-ref v1.0.0 \ --description Baseline template for financial risk control system # 输出Template registered successfully. lineageId: tm-1a2b3c4d提示lineagectl的所有命令都支持--dry-run参数。首次执行关键操作前务必加此参数查看将要创建的Lineage事件确认无误后再执行真实操作。这是避免“手抖误操作”的最佳实践。4.2 第二步创建你的第一个站点——上海生产环境shanghai-prod现在我们为上海客户创建生产站点。全程无需SSH、无需kubectl纯声明式。生成Site Manifest# 使用lineagectl生成初始Manifest交互式向导 lineagectl site init \ --name shanghai-prod \ --region sh \ --environment prod \ --customer Shanghai Financial Group \ --template risk-control-v1.0.0 \ --output site-manifests/shanghai-prod.yaml # 查看生成的Manifest已包含lineageId和基础契约 cat site-manifests/shanghai-prod.yaml # 输出 # metadata: # name: shanghai-prod # lineageId: ln-sh-prod-0001-8b # 已生成唯一ID # labels: {region: east-china, compliance: gb18030, tier: production} # spec: # baseTemplate: risk-control-v1.0.0 # overridePolicy: strict # ...提交Manifest到Git仓库这是唯一需要Git操作的步骤git add site-manifests/shanghai-prod.yaml git commit -m feat(sites): add shanghai-prod lineage manifest git push origin main触发首次部署# lineagectl监听Git仓库发现新Manifest后自动创建DeployEvent # 你也可以手动触发用于调试 lineagectl site deploy --name shanghai-prod --wait # 输出实时流式日志 # [2023-10-01 14:22:03] Event ev-8b1c2d3e-001: TemplateRender STARTED # [2023-10-01 14:22:05] Event ev-8b1c2d3e-001: TemplateRender SUCCESS # [2023-10-01 14:22:06] Event ev-8b1c2d3e-002: K8sApply STARTED # [2023-10-01 14:22:12] Event ev-8b1c2d3e-002: K8sApply SUCCESS # [2023-10-01 14:22:13] Event ev-8b1c2d3e-003: HealthCheck STARTED # [2023-10-01 14:22:15] Event ev-8b1c2d3e-003: HealthCheck SUCCESS # Deployment completed in 12.3 seconds.此时打开Kubernetes