繼承配置

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.觀察結果值的起源。

按照這些原則，您可以為任何環境和拓撲獲得可預測、可擴展且安全的配置。