wbsong111
16321b52c7
dipup 이 go:embed 로 직접 보관·관리하던 Helm 차트를 카탈로그로 옮기는 첫 단계다.
두 저장소가 각자 CVE/SBOM 파이프라인을 운영하는 이중화를 해소하려면, 먼저 카탈로그가
dipup 과 같은 차트·같은 이미지를 보게 만들어야 한다.
배경: CVE 파이프라인 구성 이전에 두 곳에서 같은 차트를 유지하기 어려워 dipup 이 별도로
차트를 관리해 왔고, 그 결과 버전이 갈라졌다. 겹치는 10개 중 버전까지 일치하는 것은
postgresql-ha·dnsup 2개뿐이었다.
## 버전 갱신 (7개) — 신규 버전 디렉토리 추가, 구버전은 보존
| 차트 | 기존 | 신규 | appVersion |
|---|---|---|---|
| apisix | 2.14.0 | 2.16.0 | 3.16.0 → 3.17.0 |
| argo-cd | 7.7.0 | 7.8.11 | v2.13.0 → v2.14.5 |
| cert-manager | v1.16.1 | v1.21.0 | 동일 |
| gitea | 12.4.0 | 12.6.0 | 1.24.6 → 1.26.1 |
| harbor | 1.16.2 | 1.19.1 | 2.12.2 → 2.15.1 |
| kyverno | 3.4.1 | 3.8.2 | v1.14.1 → v1.18.2 |
| rancher | 2.10.1 | 2.14.3 | v2.10.1 → v2.14.3 |
차트 본문은 dipup 이 임베딩한 .tgz 를 그대로 전개했다(네트워크 pull 이 아니라 dipup 이
실제 배포하는 바이트와 동일함을 보장하기 위함). BUILD-README/CUSTOM-README/custom-values
3개 파일은 구버전에서 승계했다.
## 신규 추가 (5개)
infisical-standalone 1.9.0, longhorn 109.3.1+up1.11.2, longhorn-crd 109.3.1+up1.11.2,
metallb 0.16.1, secrets-operator v0.10.33.
longhorn/longhorn-crd 는 업스트림이 아니라 Rancher 패키징 차트(109.x 라인, Rancher 2.14
계열과 짝)다. BUILD-README 의 `helm repo add` 라인은 chart_version_detector 가 파싱하는
계약이라 실제 업스트림 repo 를 검증해 기재했고, 감지기로 현재/최신 버전이 정상 조회되는
것을 확인했다.
## custom-values — 버전과 결합된 이미지 핀 정리
카탈로그 스캐너가 dipup 의 effective image 를 보게 하려면 이미지 핀이 맞아야 한다.
- **kyverno: 승계본이 3.8.2 에서 깨져 재작성.** 3.4.1 은 정리 훅이
`registry: ~ / repository: bitnami/kubectl` 이라 bitnamilegacy 오버라이드가 맞았지만,
3.8.2 는 `registry: ghcr.io / repository: kyverno/readiness-checker` 로 바뀌었다.
그대로 옮기면 ghcr.io/bitnamilegacy/kubectl 이라는 없는 좌표가 된다. 해당 오버라이드를
제거하고, 3.8.2 에서 삭제된 policyReportsCleanup 키도 함께 뺐다. 남는 조치는 tag 고정뿐
(기본 tag 가 비어 latest 로 떨어짐 → v1.18.2 로 고정).
- apisix: 3.16.0-keycloak-authz → 3.17.0-keycloak-authz (차트 appVersion 과 함께 이동)
- gitea: image.tag 1.26.4 핀 추가 — 차트 기본 1.26.1 대비 CRITICAL 2→0, HIGH 44→12
- infisical: image.tag v0.162.7 핀 — 기본 v0.158.x 는 stale Debian base 로 OS 기인 CVE
다수(fixable CRITICAL 53→5, HIGH 491→55). redis/postgresql 은 bitnamilegacy 좌표로.
- longhorn: 실측 기반 리소스 튜닝(manager request, guaranteedInstanceManagerCPU,
systemManagedCSIComponentsResourceLimits). replica 수처럼 노드 수에 의존하는 값은
넣지 않았다 — 소비 측에서 주입한다.
## 검증
12개 차트 전부 `helm template --kube-version 1.34.1` 렌더 성공. 렌더 결과 이미지가
dipup 배포 이미지와 일치함을 확인(paasup/apisix:3.17.0-keycloak-authz,
gitea:1.26.4-rootless, readiness-checker:v1.18.2, infisical:v0.162.7).
## 범위에서 뺀 것
- **keycloak**: 카탈로그는 codecentric(app 17.0.1-legacy), dipup 은 bitnami(app 26.2.4)로
계보가 다르다. 이슈 #1(bitnami 대체 방안 검토)의 결론이 나온 뒤 처리한다.
- **rancher-monitoring(-crd)**: 14c05f1 에서 불필요 판단으로 제거된 차트이고
victoria-metrics 스택으로 대체 예정이라 추가하지 않는다.
- **dip-api/dip-console**: 자체 개발 차트로 각 앱 저장소가 출처다. 대조 결과 앱 저장소와
dipup 사본이 일치해 카탈로그가 개입할 이유가 없다.
- **postgresql-ha/dnsup**: 이미 버전이 일치해 작업 대상이 아니었다.
## 후속 과제
dnsup 은 카탈로그·dipup 사본(1.0.1)이 원본(dip-console-api helm/dnsup 1.0.0)보다 앞서
있다. 1.0.1 에만 있는 service.LoadBalancerIP·service.annotations 지원을 원본으로 백포트한
뒤, 카탈로그에서 dnsup 을 제거하는 것이 자체 개발 차트 출처 원칙에 맞다.
64 lines
4.4 KiB
YAML
64 lines
4.4 KiB
YAML
# PaaSup custom-values — longhorn
|
|
#
|
|
# 실측 기반 리소스 튜닝만 담는다. replica 수는 노드 수에 따라 [1,3] 으로 클램프해야 하므로
|
|
# 소비 측(dipup 의 longhorn-values.yaml.tpl)에서 주입한다 — 여기에 고정값을 두지 않는다.
|
|
|
|
# longhorn-manager 는 차트 기본값이 resources: ~ 이라 QoS 가 BestEffort 가 된다.
|
|
# 스토리지 컨트롤 플레인이 노드 압박 시 가장 먼저 밀려나므로 request 를 명시한다.
|
|
#
|
|
# limit 은 CPU·메모리 모두 두지 않는다:
|
|
# - CPU: 볼륨 attach/detach·리빌드 구간에서 throttling 되면 상태 전이가 지연된다.
|
|
# - 메모리: manager 메모리는 전체 Longhorn CR 의 informer 캐시라 볼륨·replica 수에
|
|
# 거의 선형 증가한다(38 replica 기준 ~260Mi 실측). 규모를 모르는 클러스터에 고정 limit 을
|
|
# 걸면 OOM 루프 위험이 있고, admission webhook 이 manager 안에 있어 OOM 루프는
|
|
# 곧 모든 Longhorn CR 쓰기 차단 = 볼륨 작업 전면 중단이다.
|
|
# request 만으로도 목적(스케줄 보장·eviction 보호)은 달성된다.
|
|
# priorityClass 는 차트 기본값 longhorn-critical 이 이미 적용된다.
|
|
longhornManager:
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 384Mi
|
|
|
|
defaultSettings:
|
|
# instance-manager 파드가 노드 allocatable CPU 중 예약하는 비율(%).
|
|
# 차트 기본값 12 는 8~16 코어 노드(≈1~2 코어)를 가정한 값이라 코어 수가 큰 노드에서는
|
|
# 과다 예약이 된다(32 코어 → 3840m, 실측 사용량은 ~100m).
|
|
# 5% 로 낮춘다: 32 코어 → 1600m, replica 38 개 기준 실사용 대비 약 16 배 여유.
|
|
# v2(SPDK)는 폴링 방식이라 코어를 상시 점유하므로 기본값 12 를 유지한다.
|
|
#
|
|
# 주의 1: 비율이라 저코어 노드에서는 절대값이 작아진다(8 코어 → 400m). 코어 수가 작은
|
|
# 노드에 배포할 때는 상향을 검토할 것.
|
|
# 주의 2: running engine instance 가 있으면 Longhorn 이 즉시 적용을 거부하고
|
|
# applied=false 로 staged 한다 — 해당 노드 볼륨이 전부 detach 될 때 실현된다.
|
|
#
|
|
# instance-manager 메모리는 의도적으로 무제한이다(Longhorn 이 v1 IM 에 메모리 limit 설정을
|
|
# 노출하지 않는다). IM 메모리는 호스팅 인스턴스 수에 비례하며(replica 당 ~40Mi,
|
|
# engine 18 + replica 26 → 1062Mi 실측), IM 이 OOMKill 되면 해당 노드의 모든
|
|
# engine/replica 프로세스가 동시에 죽어 볼륨 전체가 내려가고 리빌드가 필요하다.
|
|
guaranteedInstanceManagerCPU:
|
|
v1: "5"
|
|
v2: "12"
|
|
|
|
# CSI 사이드카·플러그인도 차트 기본값이 무설정이라 BestEffort 가 된다.
|
|
# 실측(attacher/provisioner/resizer/snapshotter 각 1~2m·13~16Mi, csi-plugin 2m·42Mi)
|
|
# 기준으로 여유를 둔 request 를 부여한다.
|
|
# Longhorn 이 JSON 문자열로 파싱하므로 반드시 문자열로 전달해야 한다
|
|
# (차트가 이 값을 toJson 없이 quote 만 하므로 map 으로 주면 깨진다).
|
|
#
|
|
# 이쪽은 limit 을 유지한다 — 재시작 내성이 있어서(프로비저닝/attach 가 잠깐 멈출 뿐
|
|
# 데이터 경로 영향 없음) 누수 백스톱의 이득이 손실보다 크다. 다만 사이드카 캐시도
|
|
# PVC/VolumeAttachment 수에 따라 증가하므로 실측의 약 16 배로 여유를 크게 잡는다.
|
|
#
|
|
# ⚠️ 운영 주의: 이 값을 바꾸면 csi-provisioner 가 재시작하고, 재시작 직후 resync 에서
|
|
# 보류 중이던 PV 삭제가 flush 된다(dev 실측: 재시작 4분 뒤 reclaimPolicy=Delete 인
|
|
# Released PV 12개 삭제). 변경 전 Released/Failed PV 목록을 먼저 확인할 것.
|
|
systemManagedCSIComponentsResourceLimits: >-
|
|
{"csi-attacher":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
|
|
"csi-provisioner":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
|
|
"csi-resizer":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
|
|
"csi-snapshotter":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
|
|
"longhorn-csi-plugin":{"requests":{"cpu":"20m","memory":"64Mi"},"limits":{"memory":"512Mi"}},
|
|
"node-driver-registrar":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
|
|
"longhorn-liveness-probe":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}}}
|