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 을 제거하는 것이 자체 개발 차트 출처 원칙에 맞다.
2.1 KiB
Longhorn
Longhorn is a lightweight, reliable and easy to use distributed block storage system for Kubernetes. Once deployed, users can leverage persistent volumes provided by Longhorn.
Longhorn creates a dedicated storage controller for each volume and synchronously replicates the volume across multiple replicas stored on multiple nodes. The storage controller and replicas are themselves orchestrated using Kubernetes. Longhorn supports snapshots, backups and even allows you to schedule recurring snapshots and backups!
Important: Please install Longhorn chart in longhorn-system namespace only.
Warning: Longhorn doesn't support downgrading from a higher version to a lower version.
Upgrading to Kubernetes v1.25+
Starting in Kubernetes v1.25, Pod Security Policies have been removed from the Kubernetes API.
As a result, before upgrading to Kubernetes v1.25 (or on a fresh install in a Kubernetes v1.25+ cluster), users are expected to perform an in-place upgrade of this chart with enablePSP set to false if it has been previously set to true.
Note: If you upgrade your cluster to Kubernetes v1.25+ before removing PSPs via a
helm upgrade(even if you manually clean up resources), it will leave the Helm release in a broken state within the cluster such that further Helm operations will not work (helm uninstall,helm upgrade, etc.).If your charts get stuck in this state, please consult the Rancher docs on how to clean up your Helm release secrets.
Upon setting enablePSP to false, the chart will remove any PSP resources deployed on its behalf from the cluster. This is the default setting for this chart.
As a replacement for PSPs, Pod Security Admission should be used. Please consult the Rancher docs for more details on how to configure your chart release namespaces to work with the new Pod Security Admission and apply Pod Security Standards.