본문 바로가기
클라우드(Cloud)

쿠버네티스 네이티브 CI/CD 프레임워크, Tekton 에 대해 알아보겠습니다.

by forward error correction Circle 2026. 8. 25.
반응형

Ⅰ. Tekton 기술이란?

ⅰ. 쿠버네티스 네이티브 빌드 프레임워크

  1. 빌드, 테스트, 배포 같은 CI/CD 작업을 쿠버네티스 위에서 직접 실행할 수 있도록 돕는 오픈소스 프레임워크입니다.
  2. 별도의 CI 서버(Jenkins 등)를 두지 않고 클러스터 자체가 빌드 엔진이 되며, 파이프라인을 쿠버네티스 리소스(CRD)로 정의하여 실행합니다.

ⅱ. 기존 CI 시스템의 한계 극복

  1. 플러그인과 스크립트를 지속해서 관리해야 하고 재현이 어려운 전통적인 CI 서버의 운영 부담을 해소합니다.
  2. 플랫폼에 러너(Runner) 환경이 종속되어 온프레미스나 타 클라우드로의 이식이 까다로운 매니지드 CI(GitHub Actions 등)의 한계를 넘어 완벽한 벤더 중립성을 제공합니다.

Ⅱ. Tekton 기술 특징

ⅰ. 컨테이너 단위 실행 및 쿠버네티스 네이티브

  1. 파이프라인의 모든 구성 요소가 CRD로 선언되므로 kubectl로 관리할 수 있으며, Git에 YAML로 보관해 GitOps와 자연스럽게 어울립니다.
  2. 각 작업 단계(Step)가 독립된 컨테이너로 실행되어, 시스템에 별도 빌드 도구를 설치할 필요 없이 이미지만으로 격리된 환경을 보장합니다.

ⅱ. 재사용 가능한 Task 및 선언형 파이프라인

  1. 자주 쓰는 작업(git clone, 이미지 빌드 등)을 Task로 정의하여 여러 파이프라인이 공유하거나, Artifact Hub 카탈로그에서 검증된 Task를 즉시 가져다 쓸 수 있습니다.
  2. Task들의 실행 순서를 그래프로 정의하며, 조건 실행(when), 마무리 작업(finally), 병렬 확장(matrix) 등을 선언형으로 완벽히 지원합니다.

ⅲ. 이식성 및 강력한 공급망 보안

  1. 특정 CI 벤더 플랫폼에 묶이지 않고 쿠버네티스 표준을 따르므로, 어느 클러스터에서나 동일한 파이프라인이 동작합니다.
  2. 확장 컴포넌트인 Tekton Chains가 SLSA 프로비넌스를 생성하고 Sigstore로 서명하여, 빌드 산출물(Artifact)의 출처를 안전하게 증명합니다.

Ⅲ. Tekton 기술 동작방식

ⅰ. 핵심 구성 요소

  1. Step: 컨테이너 하나에서 실행되는 빌드의 가장 작은 명령 단위입니다.
  2. Task: 순서가 있는 Step의 묶음입니다. 하나의 Task는 하나의 Pod로 실행되며, 내부의 Step들은 컨테이너 형태로 동작합니다.
  3. Pipeline: 여러 Task의 실행 순서와 데이터 의존성을 정의한 그래프 템플릿입니다.
  4. TaskRun / PipelineRun: 정의된 틀(Task/Pipeline)에 실제 입력값을 넣어 실행한 일회성 인스턴스(실행 결과)입니다.
  5. Workspace: Task와 Step이 데이터를 공유하는 저장 공간(주로 PVC 연동)입니다.

ⅱ. 데이터 및 실행 흐름

  1. 사용자가 PipelineRun 리소스를 클러스터에 생성(요청)하면, 웹훅이 리소스를 검증하고 기본값을 채워 넣습니다.
  2. 컨트롤러가 Pipeline의 그래프를 해석하여 순차적 또는 병렬로 TaskRun을 생성하며, 각 TaskRun은 Pod로 실행되어 Step을 돌리고 Workspace를 통해 단계별 데이터를 전달합니다.

Ⅳ. Tekton 기술 구성 및 흐름도

 

ⅰ. 파이프라인 실행 로직 구성

  1. 사용자나 Triggers를 통해 PipelineRun이 생성되면, 웹훅과 컨트롤러가 리소스를 검증하고 그래프를 해석합니다.
  2. Task 단위로 TaskRun을 생성하여 각각을 Pod로 동작시키고, 내부 컨테이너(Step)를 순차 실행합니다.

ⅱ. 리소스 공유 및 후처리

  1. Workspace(PVC 등)를 통해 이전 단계의 빌드 소스나 산출물을 다음 단계로 원활하게 공유합니다.
  2. 최종 finally Task가 종료되면 파이프라인 전체 상태가 기록되고, Tekton Chains가 결과를 안전하게 서명합니다.

Ⅴ. Tekton 기술 설치 방법

ⅰ. 핵심 컴포넌트(Pipelines) 설치

  1. 쿠버네티스 1.28 이상 환경과 cluster-admin 권한이 필요하며, 공식 릴리즈 매니페스트를 통해 설치합니다.
  2. kubectl get pods --namespace tekton-pipelines --watch 명령어를 사용해 모든 컨트롤러와 웹훅 Pod가 READY(1/1) 상태가 되는지 확인합니다. (운영 환경에서는 Tekton Operator 활용 권장)

ⅱ. 전용 CLI(tkn) 및 추가 모듈 설치

  1. 운영체제 패키지 매니저를 통해 명령행 도구를 설치합니다. (macOS: brew install tektoncd-cli, Windows: choco install tektoncd-cli)
  2. Git 이벤트 연동 자동화를 원하면 Tekton Triggers를, 웹 브라우저 기반 GUI 관제가 필요하면 Tekton Dashboard를 추가 설치합니다.

Ⅵ. Tekton 기술 사용 방법

ⅰ. 기본 Task 정의 및 실행

  1. YAML 파일에 apiVersion: tekton.dev/v1, kind: Task를 선언하고, 내부 steps에 실행할 이미지와 스크립트를 작성하여 클러스터에 배포합니다.
  2. 정의된 Task 리소스는 틀에 불과하므로, 이를 실제로 동작시키려면 tkn task start [태스크명] 커맨드를 통해 TaskRun을 생성해야 합니다.

ⅱ. 운영 시 자원 및 스토리지 관리

  1. LimitRange가 설정된 네임스페이스에서는 각 Step 컨테이너의 리소스 요청값이 합산이 아닌 '최댓값'으로 계산됨을 고려하여 자원을 할당해야 합니다.
  2. TaskRun과 PipelineRun 데이터(완료된 Pod, PVC 포함)가 계속 방치되면 etcd를 압박하므로, 보존 정책이나 Tekton Pruner를 통해 오래된 실행 이력을 주기적으로 정리합니다.

Ⅶ. Tekton 기술 자주 쓰는 명령어

ⅰ. 리소스 조회 및 실행 제어

  1. tkn task list: 현재 네임스페이스에 선언된 Task 정의 목록을 조회합니다.
  2. tkn pipelinerun list: 파이프라인의 실행 이력과 성공, 실패 등 현재 상태를 목록으로 확인합니다.
  3. tkn pipeline start [이름]: 지정한 파이프라인을 실행하여 새로운 PipelineRun 인스턴스를 즉각 생성합니다.

ⅱ. 상태 추적 및 트러블슈팅 진단

  1. tkn task start [이름] --showlog: 단일 Task를 트리거함과 동시에 터미널에서 로그를 실시간으로 스트리밍하여 출력합니다.
  2. tkn pipelinerun logs -f [실행명]: 현재 돌고 있는 파이프라인의 전체 실행 로그를 꼬리 물기(-f) 방식으로 추적합니다.
  3. tkn taskrun describe [실행명]: 실패한 TaskRun의 상세 정보를 덤프하여 어느 Step에서 멈췄는지 디버깅합니다.

Ⅷ. Tekton 기술 활용방안

ⅰ. 차세대 클라우드 네이티브 CI 인프라

  1. 사내 여러 개발팀이 검증된 Task 카탈로그(예: 이미지 빌드용 Kaniko, 보안 스캔용 Trivy)를 공유하여 표준화된 CI 빌드 엔진을 구축합니다.
  2. 온프레미스와 퍼블릭 클라우드, 에지(Edge) 등 쿠버네티스가 구동되는 어떤 환경이든 동일한 파이프라인 명세(YAML)를 그대로 이식하여 사용합니다.

ⅱ. GitOps 및 공급망 보안(SLSA)의 완성

  1. Tekton이 이미지 빌드와 푸시를 담당하고, 배포(CD)는 Argo CD가 담당하도록 아키텍처 역할을 분리해 강력한 GitOps 환경을 셋업합니다.
  2. 소프트웨어 공급망 보안 기준(SLSA) 충족을 위해 Tekton Chains와 연동해, 빌드 결과물에 대한 프로비넌스 생성 및 증명을 자동화합니다.

Ⅸ. Tekton 기술 트러블 슈팅

ⅰ. 스토리지(Workspace) 바인딩 및 스케줄링 오류

  1. 다수의 Task가 하나의 ReadWriteOnce(RWO) PVC를 공유할 때, Tekton의 Affinity Assistant가 모든 TaskRun을 같은 노드에 강제로 묶어 Pending 상태가 유발될 수 있습니다.
  2. 위와 같은 노드 자원 부족 현상 시, 스토리지 클래스를 ReadWriteMany(RWX)로 변경하거나 disable-affinity-assistant 옵션을 켭니다.

ⅱ. 권한 부족(RBAC) 및 결과 데이터 크기 한계

  1. 사설 레지스트리에 이미지를 푸시하거나 사설 Git을 클론할 때 인증 실패가 발생하면, 기본 ServiceAccount 대신 자격 증명(시크릿)이 바인딩된 전용 ServiceAccount를 연결합니다.
  2. Step 간 전달하는 Result 값이 쿠버네티스 종료 메시지 한계인 4KB를 초과해 잘리거나 실패하는 경우, 데이터를 Result 변수 대신 Workspace(PVC)를 통해 파일 형태로 전달하도록 수정합니다.
반응형