구성의 상속

1) 왜 구성 상속이 필요합니까?

성숙한 제품에서는 구성 매개 변수 수가 서비스 수보다 빠르게 증가합니다. 상속은 다음을 허용합니다

공통 값 (로깅, 배상, 타임 아웃) 을 재사용하십시오.
공유 책임: 플랫폼은 기본 정책, 서비스 명령을 설정합니다. 편차 만 있습니다.
복제를 피하고 정렬이 잘못 될 위험을 줄이십시오.
속도 향상: 기본적으로 트리 아래로 변경 사항이 방송됩니다.
단일 접근 방식으로 다중 환경 및 다중 임차를 지원하십시오.

2) 상속 패턴

2. 1 계층 구조 (부모 → 자식)

기본 (글로벌) → 환경 (prod/stage/dev) → 영역/클러스터 → 서비스 → 인스턴스.
단순하고 투명하지만 깊은 체인 및 복잡한 디버깅으로 이어질 수 있습니다.

2. 2 층 (베이스/오버레이)

기본 계층 + 오버레이 세트 (기능 x, 지역, 보안 경화).
GitOps 및 Kustomize와 잘 작동합니다. 오버레이는 독립적이고 구성적입니다.

2. 3 복합 (모듈/패키지)

구성은 'logging @ v2', 'metrics @ v1', 'http @ v3' 모듈로 구성됩니다.
모듈 버전 지정, 시맨틱 호환성, 명시 적 종속성.

2. 4 코드 정책

기본 "리미터" 및 불변 (OPA/Rego, Kyverno, Conftest).
가치 자체는 상속되지 않고 허용 가능성에 대한 규칙입니다.

3) 합병 알고리즘 및 우선 순위

중요한 문제는 갈등을 해결하는 절차입니다. 사양을 수정하는 것이 좋습니다

1. 소스 순서: 왼쪽에서 오른쪽으로 (기본 유엔 지역 서비스 인스턴스).

• 스칼라: "마지막 쓰기".
• 개체: 키에서 재귀 병합.

• '추가 '/' 예약'
• 'uniqueby (key)' (키별로 설정)
• '패치' ('이름' 및 부분 병합 항목 찾기).
• 3. 예약 된 키 (예: 노드 레벨에서 '_ merge: replace '/' _ merge: deep').

• 시작 플래그/ENV 변수> 런타임 비밀> 디스크의 파일> 코드의 기본 값.

YAML 병합의 예

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, 패턴, 제약 조건 ('최소', '형식', '패턴 속성').
스키마 버전 (반주): 메이저-파괴, 마이너-새로운 필드, 패치-수정.
사전 병합 및 사후 병합 점검: 조각과 결과를 모두 검증합니다.
기본값: 스키마 수준으로 설정 (draft-07 + 는 '기본값' 을 지원합니다).

5) 환경 및 배포 매트릭스

• env: 개발, 테스트, 단계, prod 영역: eu-central-1, us-east-1 계층: 배치, 실시간, 내부 임차인: A/B/C (화이트 라벨, B2B)
• 조합은 오버레이 트리를 형성합니다. 과도한 깊이를 피하십시오 (3-4 레벨로 충분 함).

6) 멀티 테넌시

• 하드 스플릿: 테넌트 당 별도의 파일/폴더.
• Parameterization: 임차인 당 하나의 템플릿 + 값.
• 상속 된 정책: 리소스/할당량 제한, SLO, 로그 보존.
• 중요: 보안 경계 (비밀/키) 가 세입자간에 흐르지 않아야합니다.

7) 비밀과 보안

비밀을 명시 적으로 물려받지 마십시오. 상속 된 참고 문헌: 'secretRef', 'vaultPath'.
KMS/Vault/SOPS: 암호화 된 값을 Git에 저장합니다. 키-out.
공유 책임: 플랫폼은 경로와 정책, 서비스 팀-실제로 필요한 것을 관리합니다.
정책: CI 검사에서 '일반 텍스트' 비밀을 금지합니다.
회전: "덮어 쓰기" 하지 마십시오-별칭/추상화 ('db/기본/암호 @ 2025-Q4') 사용.

금고 링크 예

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/맞춤형 스크립트를 사용한 마이그레이션.
안전한 롤백을위한 업/다운 마이그레이션.
긴 가지: 드리프트를 피하십시오. 정기적으로 꼬치 오버레이를베이스로 옮깁니다.

9) 도구 및 실습

9. 쿠 베르네 테스 1 명

Kustomize (오버레이): 'base '/' resources', 'patchesStrategicMerge '/' patchesJSON6902' 를 통한 자연 상속 모델.
헬름 (값): 계층 구조 값. yaml '+' sharber '(그러나 CI의 오버 라이드에주의하십시오).
Kyverno/OPA: "안전망" 으로서의 정치인.

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

9. 2 테라 폼

+ '변수 모듈. 계약으로 tf '.
계산 된 값에 대한 '로컬', '파일 무시-디렉토리 계층 및 작업 공간 (' 작업 공간 ') 사용.
소스 순서: 기본값은 <tfvars-files <'-var '/' -var-File' 입니다.

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

9. 3 불가능한

변수의 명확한 계층 구조 (오름차순 우선 순위): 역할 기본값 <인벤토리 그룹 _ vars <host _ vars <extra vars.
상속을 위해-' 그룹 _ vars/{ env }/{ region} .yml '구조.

9. 4 Jsonnet/ytt

풍부한 구성, 기능 및 "키 의도" ('오버레이. '', 오버레이를 대체합니다. 병합 ').

10) 계약 및 배터리 제한

플랫폼 팀 정의 스키마, 정책, 기본 값 및 병합 논리.
제품 팀: 계약 내에서만 오버레이.
SRE/보안: 감사, 검증, 서명, 집행.

11) CI/CD... GitOps

1. 린트 (형식, 알 수없는 키 금지).

2. 검증 (JSON Schema/OpenAPI).

3. 드라이 런/렌더 (헬름 템플릿/쿠스토 마이즈 빌드).

4. 정책 점검 (OPA/Kyverno/Conftest).

5. Diff 대 대상 클러스터 (kubectl diff/ArgoCD diff).

6. 점진적인 배송: 트래픽이 제한된 카나리아 오버레이.

7. 인공물 서명 (Cosign, SLSA 증명).

12) 관찰 가능성 및 디버깅

증명 추적: 누가 필드에 기여했으며 언제 어느 계층에서 최종 값이 나왔습니다.
시각화 병합: "승리" 키의 보고서.
활성 구성의 런타임 내보내기 (비밀 마스킹이있는 엔드 포인트 '/설정 ').
드리프트 경고: 선언 된 것과 실제의 불일치.

13) 반 패턴

명시적인 우선 순위 규칙이없는 "매직".
딥 체인 (> 4-5 층): 인지 부하를 증가시킵니다.
상속 된 파일의 비밀.
CI에서 '헤일러' 를 통해 숨겨져 있습니다.
스키마 및 렌더링 테스트 부족.

14) 구현 점검표

• 모델을 정의하십시오 (계층/계층/구성).
• 유형별로 병합 순서와 전략을 수정합니다.
• 스키마 게시 및 버전 지정.
• 비밀 공유 (링크/심판 만).
• 정책 점검 및 아티팩트 서명 추가
• 드라이 런, 확산 및 원점 시각화를 사용하십시오.
• 활동 시간에 활성 구성을 내보냅니다.
• 설정 변경을위한 프로그레시브 릴리스 설정

15) FAQ

Q: 레이어가 너무 깊다는 것을 이해하는 방법?
A: 매개 변수를 변경하려면> 3 파일을 열고 "스크롤"> 2 단계 추상화가 필요한 경우 구조를 수정하십시오.

Q: 상충되는 배열로 무엇을해야합니까?
A: '대체', '추가', 'uniqueBy (키)', 'patchBy (이름)' 와 같은 명시 적 전략을 입력하고 문서에서 수정하십시오.

Q: 비밀을 물려받을 수 있습니까?
A: 아니요. 비밀 상점 및 액세스 정책에 대한 링크 만 상속됩니다.

Q: 상속을 테스트하는 방법?
A: 키 오버레이 조합을 위해 "슬라이스" 를 촬영하고 황금 파일로 확인하십시오. PR 당 CI의 레이스 렌더링.

부록 A: 미니 스펙 병합

'스칼라': 마지막 글쓰기

'객체': 키로 깊이 병합

• 기본 '대체'

• '부록'
• 'uniqueby (키)'
• 재귀 요소가 병합 된 'patchBy (key)'

• '_ merge:' deep '교체
• '_ 전략. 배열: 'complib' uniqueBy (이름) | patchBy (이름) '

부록 B: 예

B.1 투구 값 (베이스 위의 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

마지막 파일의 우선 순위는 '값입니다. prod. yaml '.

B.2 Kustomize 오버레이

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

요약

구성 상속은 많은 YAML 파일뿐만 아니라 계약 + 병합 알고리즘 + 보안 정책입니다. "성공은 다음과 같이 정의됩니다

1. 명확한 모델과 우선 순위,

2. 검증 체계 및 독립적 인 오버레이,

3. 비밀을 물려받는 것을 거부하고

4. 드라이 런, 정책 점검 및 확산이있는 GitOps 파이프 라인,

5. 최종 값의 출처를 관찰 할 수 있습니다.

이러한 원칙을 따르면 모든 환경과 토폴로지에 대해 예측 가능하고 확장 가능하며 안전한 구성을 얻을 수 있습니다.