SAS Viya 4 의 설정을 바꿀 때 sas-bases 아래 파일을 직접 고치면 다음 업그레이드에서 그 수정이 사라지거나 충돌한다. 모든 커스터마이징은 site-config 아래에 두고 최상위 kustomization.yaml 에서 참조하게 만든다.
sas-bases/examples 아래 파일은 예제다. 그 자리에서 값을 채워 쓰는 것이 아니라 site-config 로 복사한 뒤 복사본을 수정한다.
cp $deploy/sas-bases/examples/backup/configure/sas-scheduled-backup-job-change-default-backup-transformer.yaml \
$deploy/site-config/backup/
복사한 파일 안의 {{ ... }} 플레이스홀더를 실제 값으로 바꾼다. 플레이스홀더를 그대로 두면 빌드는 통과해도 적용은 되지 않는다.
파일의 종류에 따라 등록할 블록이 다르다. 여기를 틀리면 빌드가 바로 깨진다.
| 파일 종류 | 등록 블록 |
|---|---|
| Kubernetes 리소스(Deployment · PVC · ConfigMap 등) | resources: |
kind: PatchTransformer 같은 kustomize 내장 변환기 |
transformers: |
| ConfigMap 값 병합 | configMapGenerator: (behavior: merge) |
transformers:
- site-config/backup/sas-scheduled-backup-job-change-default-backup-transformer.yaml
- sas-bases/overlays/required/transformers.yaml
configMapGenerator:
- name: sas-backup-job-parameters
behavior: merge
literals:
- RETENTION_PERIOD=7
sas-bases/overlays/required/transformers.yaml 는 마지막에 와야 한다. 사이트 변환기가 먼저 적용된 뒤 필수 변환기가 붙는 순서를 SAS 가 전제하고 있다.
Error: accumulation err='merging resources from
'site-config/cas-server/cas-sssd-example.yaml' ...
must build at directory: '.../cas-sssd-example.yaml': file is not directory
bases: 또는 resources: 에 파일을 넣었을 때 나온다. 이 둘은 디렉터리(또는 리소스 매니페스트)를 기대한다. 변환기 파일이라면 transformers: 로 옮긴다.
may not add resource with an already registered id:
PatchTransformer.builtin.[noGrp]/cas-sssd-sidecar-no-tls.[noNs]
같은 metadata.name 을 가진 변환기가 두 번 등록됐다는 뜻이다. 예제 파일과 복사본이 동시에 포함돼 있거나, 복사본의 이름을 바꾸지 않은 경우다.
grep -R "cas-sssd-sidecar-no-tls" -n $deploy
중복을 확인한 뒤 예제 파일 참조를 지우거나 복사본의 metadata.name 을 바꾼다.
Error: add operation does not apply:
doc is missing path: "/template/spec/containers/2/volumeMounts/-": missing value
JSON Patch 의 path 가 실제 리소스 구조와 맞지 않는다는 뜻이다. 원인은 둘 중 하나다.
첫째, 루트가 틀렸다. kind: PodTemplate 은 최상위에 template 이 있으므로 /template/spec/... 가 맞지만, Deployment·StatefulSet 은 /spec/template/spec/... 로 시작해야 한다.
둘째, 컨테이너 인덱스가 실제와 다르다. 예제는 과거 릴리스 기준이라 containers/2 를 가리키는데 현재 파드에는 컨테이너가 두 개뿐인 경우가 흔하다. 실제 인덱스를 먼저 확인한다.
kubectl -n <namespace> get podtemplate sas-compute-job-config -o json \
| jq '.template.spec.containers[].name'
volumeMounts 배열 자체가 없는 컨테이너라면 배열을 먼저 만들고 append 한다.
patch: |-
- op: add
path: /template/spec/containers/0/volumeMounts
value: []
- op: add
path: /template/spec/containers/0/volumeMounts/-
value:
name: sas-sssd-custom-config
mountPath: /sssd
sas-bases 는 주문 번호(site number)와 릴리스에 묶여 있다. 같은 2509 표기라도 다른 주문의 배포 자산은 패치 레벨과 클라이언트·스코프 정의가 다를 수 있다. 특히 examples/security 아래 파일은 OAuth 클라이언트와 스코프를 건드리므로, 다른 자산에서 가져다 쓰면 서비스 간 인증이 어긋난다.
kustomize build -o site.yaml
kubectl apply -f site.yaml
vars, bases, commonLabels, patchesStrategicMerge 가 deprecated 라는 경고는 kustomize 신버전이 구 문법을 알려 주는 것으로, 그 자체는 실패가 아니다.
ConfigMap 만 바꾼 경우 이미 떠 있는 파드에는 반영되지 않는다. 해당 워크로드를 다시 띄워야 한다.
kubectl -n <namespace> rollout restart deployment sas-compute