Kubernetes 기반 CI/CD 구성 요소 정리

Kubernetes 기반 CI/CD 플랫폼은 단순히 Jenkins 대체 도구를 모아 둔 구조가 아닙니다. Git 저장소, Tekton, Argo CD, Argo Rollouts, Harbor, SonarQube, Trivy, OAuth2 Proxy 같은 구성 요소가 역할을 나누고, 이 조합은 Kubernetes-native pipeline, GitOps, supply-chain provenance, SBOM, progressive delivery, SSO 보호 운영 콘솔과 맞닿아 있습니다.

목표는 도구 이름을 많이 늘어놓는 것이 아니라, 이 조합이 왜 요즘 플랫폼 엔지니어링 흐름과 맞는지 보는 것입니다. CI는 Tekton 쪽으로, CD는 Argo CD와 Rollouts 쪽으로, registry는 Harbor 기반 trust hub 쪽으로 역할이 나뉘고 있습니다.

1. Kubernetes 기반 CI/CD에서 자주 조합되는 구성

2. 오픈소스 기준으로 보는 각 컴포넌트

이 조합을 볼 때 중요한 것은 "이름이 유명한가"보다 "오픈소스 생태계에서 어떤 문제를 맡고 있는가"입니다. 같은 CI/CD라는 말 안에서도 Git forge, pipeline runtime, GitOps controller, registry, policy gate, 접근 제어가 맡는 계층은 서로 다릅니다.

3. 대체와 보완 트렌드도 같이 봐야 합니다

대체재는 "무엇이 더 좋다"보다 운영 모델의 차이로 보는 편이 낫습니다. Kubernetes-native로 갈수록 선언형 리소스, controller, GitOps, policy-as-code 쪽이 강해지고, forge-integrated CI로 갈수록 개발자 경험과 초기 도입 속도가 강해집니다.

4. 가장 트렌드성이 큰 축은 Tekton + GitOps입니다

이 조합의 핵심은 Tekton을 CI 실행면으로 두고 Argo CD를 CD/GitOps 면으로 둔 점입니다. Tekton은 Pipeline과 Task를 Kubernetes CRD로 다루기 때문에 pipeline 실행 자체가 클러스터 리소스가 됩니다. Argo CD는 Git 저장소의 desired state와 클러스터 live state를 비교하고, drift를 보여주며, sync를 통해 상태를 맞춥니다.

이 구조가 중요한 이유는 CI/CD가 더 이상 별도 서버 하나에서 shell script를 돌리는 방식으로만 남지 않는다는 점입니다. PipelineRun, TaskRun, Application, Rollout 같은 리소스가 모두 Kubernetes API로 관찰되고, 권한/RBAC/namespace/storage/logging 정책을 같은 운영 모델 안에서 다룰 수 있습니다.

Git commit
  -> Tekton PipelineRun
  -> build / test / scan / image push
  -> Harbor image digest
  -> GitOps manifest update
  -> Argo CD sync
  -> Kubernetes rollout
  -> route or health endpoint verification

5. Tekton Resolvers는 pipeline catalog 운영의 다음 단계입니다

Tekton 기반 pipeline을 운영하다 보면 Maven, Gradle, npm, pnpm, Kaniko, ArgoCD sync, SonarQube scanner, Trivy, Polaris, ZAP 같은 task/pipeline 자산이 늘어납니다. 여기서 최신 방향은 모든 Task를 클러스터 안에 복사해 두는 방식보다, Git 또는 OCI registry에 둔 표준 Task를 resolver로 참조하는 쪽입니다.

Tekton 공식 문서도 Remote Resolution을 통해 클러스터 밖 원격 소스의 Task와 Pipeline을 가져올 수 있다고 설명합니다. 이런 환경에서는 공통 보안 스캔, 이미지 빌드, ArgoCD sync, ingress 검증 같은 task를 공용 Git repo나 OCI artifact로 관리하면, 애플리케이션별 pipeline은 공통 task version만 고정해서 참조할 수 있습니다.

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: app-release-
spec:
  pipelineRef:
    resolver: git
    params:
      - name: url
        value: https://git.example.com/platform/pipeline-catalog.git
      - name: revision
        value: main
      - name: pathInRepo
        value: pipelines/build-scan-gitops.yaml

6. Tekton Chains와 Results는 증거 중심 CI/CD로 가는 길입니다

앞으로 CI/CD에서 중요한 것은 "빌드가 성공했다"가 아니라 "무슨 소스, 어떤 의존성, 어떤 runner, 어떤 task, 어떤 이미지 digest로 만들어졌는가"입니다. Tekton Chains는 TaskRun/PipelineRun 실행을 관찰해 provenance와 attestation을 만들고, 서명한 뒤 저장하는 방향의 컴포넌트입니다. SLSA provenance는 산출물이 어떤 과정으로 만들어졌는지 설명하는 표준 메타데이터입니다.

Tekton Results는 실행 이력과 로그를 Pipeline controller 수명과 분리해 장기 보관하고 검색하는 축입니다. 이 둘을 강화하면 장애 분석, 릴리스 감사, 이미지 출처 검증이 "사람이 기억하는 운영 기록"에서 "query 가능한 실행 증거"로 이동합니다.

PipelineRun evidence model
- source repository and revision
- Pipeline / Task version
- input artifacts and dependencies
- output image digest
- vulnerability and quality gate result
- Argo CD application revision
- rollout and health check result

7. Harbor는 이미지 저장소에서 artifact trust hub로 이동 중입니다

Harbor는 private registry와 mirror 역할을 합니다. 최신 흐름에서는 여기서 한 단계 더 나아가 이미지, SBOM, signature, vulnerability scan 결과를 함께 관리하는 artifact trust hub가 됩니다. Harbor 공식 문서에는 SBOM 생성/복제, Cosign 또는 Notation 기반 artifact signing, vulnerability scan, tag immutability, robot account 같은 기능이 분리되어 있습니다.

예를 들어 release 이미지는 tag보다 digest 기준으로 배포하고, 이미지와 함께 SBOM과 signature를 붙이는 식으로 운영할 수 있습니다. 그러면 단순히 "이미지가 registry에 있다"가 아니라 "이 이미지는 어떤 pipeline에서 만들었고, 어떤 취약점 상태였고, 어떤 정책으로 배포 허용됐는지"를 설명할 수 있습니다.

Recommended Harbor policy direction
- immutable release tags
- digest-based deployment
- robot account per pipeline scope
- scan on push and scheduled rescan
- SBOM attached to image artifact
- signature attached to image artifact
- temporary allowlist with expiry only

8. Argo Rollouts는 "배포 완료"를 "점진적 검증"으로 바꿉니다

Kubernetes Deployment의 rolling update는 기본 안전장치로 충분한 경우가 많지만, 점진적 트래픽 전환과 metric 기반 자동 판단에는 한계가 있습니다. Argo Rollouts는 blue-green, canary, canary analysis, progressive delivery를 Kubernetes CRD로 제공하고, 배포 과정을 더 작게 나눠 검증할 수 있게 합니다.

트렌드 관점에서 Rollouts의 핵심은 배포가 한 번에 끝나는 이벤트가 아니라, 작은 트래픽 단위로 검증하고 문제가 있으면 자동 중단하거나 rollback하는 과정이라는 점입니다. Prometheus, Grafana, Kiali 같은 관찰 계층과 연결하면 배포 품질을 사람이 눈으로만 판단하지 않아도 됩니다.

9. SonarQube와 Trivy는 "나중에 검사"가 아니라 pipeline gate입니다

SonarQube는 전체 legacy code를 한 번에 다 고치자는 도구로 쓰면 금방 병목이 됩니다. 공식 문서의 Clean as You Code 방향처럼 새 코드 기준 quality gate를 우선 적용해야 합니다. PR 또는 main merge 시점에 new code의 bug, vulnerability, security hotspot, duplication, coverage 기준을 fail-fast gate로 두는 것이 현실적입니다.

Trivy는 이미지 취약점만 보는 도구가 아니라 SBOM, filesystem, Git repository, Kubernetes까지 폭넓게 스캔할 수 있는 scanner입니다. Trivy/Polaris/ZAP task를 pipeline catalog에 넣으면 보안 검사를 별도 프로젝트가 아니라 delivery flow 안에서 실행할 수 있습니다.

Pipeline gate order
1. source structure check
2. unit or smoke test
3. SonarQube new-code quality gate
4. image build with fixed tag and digest capture
5. Trivy vulnerability / SBOM scan
6. Polaris or policy check for Kubernetes manifests
7. Argo CD sync
8. rollout and route health verification

10. OAuth2 Proxy와 OIDC는 운영 UI 보호의 현실적인 축입니다

Tekton Dashboard, Prometheus, Alertmanager 같은 운영 UI를 OAuth2 Proxy와 OIDC provider로 보호하는 방향은 현실적입니다. 다만 reverse proxy 구성에서는 trusted proxy IP와 forwarded header 신뢰 경계를 정확히 잡아야 합니다. OAuth2 Proxy 공식 문서도 reverse proxy 사용 시 trusted proxy IP 설정을 주의하라고 경고합니다.

운영 트렌드는 모든 도구가 각자 계정을 들고 있는 구조에서, 중앙 IdP 중심으로 로그인과 그룹/RBAC를 맞추는 구조로 이동합니다. 최소한 CI/CD UI 표면은 같은 SSO 경계 안으로 묶는 것이 좋습니다.

11. 기반 컴포넌트와 트렌드 컴포넌트를 구분해야 합니다

모든 구성요소가 "트렌드 컴포넌트"는 아닙니다. Git forge, artifact repository, ingress controller, load balancer, storage, DNS는 트렌드라기보다 플랫폼을 굴러가게 하는 기반입니다. 반대로 Tekton Chains/Results, Resolvers, Argo CD, Argo Rollouts, Harbor SBOM/signing, SonarQube new-code gate, Trivy SBOM/Kubernetes scanning, OAuth2 Proxy SSO는 앞으로 운영 성숙도를 올리는 방향성과 직접 연결됩니다.

12. 추천하는 이동 순서

1. 이미지 태그 기준 정리: 개발, 검증, 운영 배포에서 tag와 digest를 어떤 기준으로 쓸지 먼저 정합니다.
2. Pipeline catalog를 resolver 기반으로 정리: 공통 Task/Pipeline을 Git repo 또는 OCI artifact 기준으로 version pinning합니다.
3. Results를 기본 증거 저장소로 둠: PipelineRun 성공/실패, 로그, artifact digest, 배포 결과를 장기 조회 가능하게 둡니다.
4. Chains + Harbor signature/SBOM 연결: build provenance, image digest, SBOM, signature를 릴리스 증거로 묶습니다.
5. GitOps sync와 Rollouts를 표준 CD로 둠: kubectl apply 중심 배포는 smoke나 긴급 lane으로 좁히고, 운영 배포는 Argo CD와 Rollouts로 보냅니다.
6. 품질/보안 gate를 fail-fast로 만듦: SonarQube new-code gate, Trivy/SBOM scan, Polaris manifest check를 통과 기준으로 둡니다.
7. SSO와 credential 주입 경계 정리: UI 표면은 OIDC/RBAC로 묶고, pipeline credential은 Secret manager나 Kubernetes Secret을 통해 주입합니다.

정리

Kubernetes 기반 CI/CD에서 중요한 구성 요소는 "새 도구를 더 설치하는 것"보다 "각 도구의 운영 역할을 명확히 나누는 것"에 가깝습니다. Tekton은 Kubernetes-native CI 실행면, Argo CD는 GitOps desired state, Argo Rollouts는 progressive delivery, Harbor는 SBOM/signature/vulnerability 중심 trust hub, SonarQube와 Trivy는 quality/security gate, OAuth2 Proxy와 OIDC는 운영 UI 보호면으로 보면 됩니다.

따라서 다음 개선 방향은 단순 기능 추가가 아니라 증거 중심 배포입니다. 어떤 commit이 어떤 PipelineRun으로 어떤 digest를 만들었고, 어떤 SBOM과 scan 결과를 통과했으며, 어떤 Argo CD revision으로 어떤 health check를 확인했는지 남기는 구조가 Kubernetes 기반 CI/CD의 다음 단계입니다.

공식 문서 링크

• Gitea documentation
• Forgejo and forge comparison
• Tekton overview
• Tekton Chains SLSA provenance
• Tekton Results API
• Tekton Pipeline Remote Resolution
• Jenkins documentation
• Argo CD GitOps overview
• Flux documentation
• Argo Rollouts progressive delivery
• Flagger progressive delivery
• Harbor overview
• Harbor SBOM integration
• Harbor artifact signing
• Sigstore Cosign keyless signing
• SonarQube Community Build
• SonarQube Clean as You Code
• Trivy SBOM scanning
• Anchore Syft and Grype
• Semgrep documentation
• CodeQL documentation
• Kyverno introduction
• OPA Gatekeeper introduction
• OAuth2 Proxy reverse proxy configuration