继承配置

1）为什么需要继承配置

• 重新使用通用值（拼写、转义、时间）。
• 分担责任：平台设置基本策略，服务命令-仅拒绝。
• 避免重复并降低不同步的风险。
• 加快发布速度：默认更改在树上播放。
• 单一方法支持多环境和多影子。

2）继承模式

2.1等级（父母→子女）

基地（全球）→环境（prod/stage/dev）→区域/群集→ →实例服务。
简单而透明，但可能会导致"深度链"和复杂的调试。

2.2层次（基数/覆盖）

基层+覆盖集（feature-x, region-eu, security-hardening）。
与GitOps和Kustomize完美结合；覆盖物是独立和构成的。

2.3复合（模块/软件包）

配置由以下模块组装："logging@v2"，"metrics@v1"，"http@v3"。
模块版本控制、语义兼容性、显式依赖性。

2.4上面的策略（策略即代码）

基本的"约束"和不变式（OPA/Rego，Kyverno，Conftest）。
不继承值本身，而是继承其有效性的规则。

3）合并算法和优先级

1.源顺序：从左到右（base env region service instance）。

• Scallar："最后赢了"（最后的写作）。
• 对象：按键递归垃圾。

• `append`/`prepend`
• 'uniqueBy （key）'（按键数）
• "patch"（通过"名称"和部分merge搜索项目）。
• 3.保留键（例如节点级别的'_merge： replace'/'_merge： deep'）。

• 启动标志/ENV变量>rantime秘密>磁盘上的文件>代码中的默认值。

YAML-merge示例

yaml base. yaml http:
port: 8080 timeouts:
read: 2s write: 2s features:
- name: audit enabled: false

prod. yaml http:
timeouts:
read: 1s features:
- name: audit enabled: true
- name: billing enabled: true

Result (under policy: object = deep merge, array = uniqueBy (name) + patch)
http:
port: 8080 timeouts:
read: 1s write: 2s features:
- name: audit enabled: true
- name: billing enabled: true

4）方案和验证

方案的存在是安全继承的先决条件。

JSON Schema/OpenAPI：类型，必填字段，enum，模式，限制（"minimum"，"format"，"patternProperties"）。
电路转化（semver）：主要是断裂，次要是新字段，补丁是假字。
前期和后期检查：验证片段和结果。
默认值：在架构级别设置（draft-07+支持"默认"）。

5）环境和部署矩阵

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• 组合形成覆盖树；避免过度深度（3-4层足够）。

6）多重性

• 刚性分离：每个tenant的单个文件/文件夹。
• 参数化：一个模板+values per tenant。
• 继承政策：资源限制/配额，SLO，重新定义日志。
• 重要的是：安全界限（秘密/钥匙）不应在Tenant之间流动。

7）秘密和安全

不要以明确的形式继承秘密。继承链接："secretRef"，"vaultPath"。
KMS/Vault/SOPS：将加密值存储在Git,密钥存储在外部。
分担责任：平台管理路径和策略，服务团队是真正需要的。
策略：在CI检查中禁止"plaintext"秘密。
Rotation：不要重写下去-使用alias/抽象 （'db/primary/password@2025-Q4'）。

带有Vault引用的示例

yaml db:
host: postgres. service user: app passwordFrom:
vaultPath: "kv/prod/app-db"
key: "password" # secret is taken at the deploy stage, not stored in files

8）验证和迁移

配置模块版本： 'logging@2.3.1`.

方案的Changelog：使用jsonnet/ytt/定制脚本进行迁移。
双向迁移（up/down）以进行安全回滚。
长枝：避免漂移；定期重新建立基地。

9）工具和做法

9.1 Kubernetes

Kustomize（过量）：通过"bases"/"资源"，"patchesStrategicMerge"/"patchesJSON 6902"的自然继承模型。
Helm（values）：values的层次结构。yaml '+'-set'（但要小心CI中的重新定义）。
Kyverno/OPA：政治家作为"保险网"。

yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod

9.2 Terraform

模块+'variables。tf"作为合同。
"locals"用于计算值,"override"文件不使用-使用目录层和工作区（"workspaces"）。
源顺序：默认值<tfvars文件<'-var'/'-var-file'。

hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}

9.3 Ansible

清晰的变量层次结构（按优先级增加）：role defaults <inventory group_vars <host_vars <extra vars。
对于继承，是结构"grupp_vars/{env}/{region} .yml"。

9.4 Jsonnet / ytt

丰富的构图，功能和"关键意图"（'overlay。replace`, `overlay.merge`).

10）合同和责任范围

平台（platform team）：定义模式、策略、基本值、商品逻辑。
杂货团队：仅在合同范围内覆盖。
SRE/安全：审计，验证，签名，执行。

11) CI/CD и GitOps

1.Lint（格式，禁止未知密钥）。

2.Validate (JSON Schema/OpenAPI).

3.Dry-run/Render (helm template/kustomize build).

4.Policy check (OPA/Kyverno/Conftest).

5.Diff与目标群集（kubectl diff/ArgoCD diff）。

6.渐进式交付：交通有限的金丝雀覆盖物。

7.工件签名（Cosign，SLSA认证）。

12）可观察性和调试

原点跟踪（provenance）：谁以及何时输入字段,最终值来自哪个层。
Merj渲染："获胜"密钥的报告。
Runtime导出活动配置（带有秘密掩码的endpoint "/config"）。
Alertes漂移：声明和事实之间的差异。

13）反模式

没有明确优先权规则的"魔术"。
深链（>4-5层）：增加认知负荷。
继承文件中的秘密。
通过CI中的"-set"隐藏重新定义。
缺乏方案和渲染测试。

14）实施支票

• 定义模型（层次结构/图层/组成）。
• 按类型确定商品的顺序和策略。
• 发布图表和版本。
• 分享秘密（仅限链接/裁判）。
• 添加策略检查和工件签名。
• 启用dry-run、诽谤和来源可视化。
• 确保在rantime中导出活动配置。
• 为config更改配置渐进版本。

15) FAQ

Q：如何理解层太深？
A：如果您需要打开>3个文件并滚动>2抽象级别-请重新定义结构。

Q： 如何处理冲突阵列?

答：输入显式策略："replace"、"append"、"uniqueBy （key）"、"patchBy （name）"-并在文档中记录它们。

问：秘密可以继承吗？
答：没有。仅继承对秘密存储和访问策略的引用（URI/refs）。

问：如何测试继承？
答：拍摄关键迭加组合的"切片",并检查黄金文件；在每个PR的CI中进行渲染。

附录A： Merge Mini Spack

`scalars`: last-write-wins

'objects'： 按键进行深度处理

`arrays`:

默认情况下"replace"

• `append`
• `uniqueBy(key)`
• 带有递归元素的"patchBy （key）"

• `_merge: replace|deep`
• `_strategy.array: replace|append|uniqueBy(name)|patchBy(name)`

附件B： 示例

B.1 Helm values（数据库顶部的prod）

yaml values. base. yaml replicas: 2 resources:
requests:
cpu: "100m"
memory: "128Mi"
logging:
level: info

values. prod. yaml replicas: 4 logging:
level: warn

helm template svc chart/ -f values. base. yaml -f values. prod. yaml

最后一个文件的优先级是'values。prod.yaml`.

B.2 Kustomize overlays

yaml base/deployment. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 2

overlays/prod/patch. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 4

B.3 Ansible vars

group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priority

结果

1.明确的模式和优先事项，

2.通过验证方案和独立的覆盖物，

3.拒绝继承秘密，

4.GitOps-pipline带有干跑，策略检查和诽谤，

5.观察结果值的起源。

按照这些原则，您可以为任何环境和拓扑获得可预测、可扩展且安全的配置。