Tekton이란?

Overview

작년에 Knative를 다루면서 잠깐 Tekton에 대한 얘기를 언급한 적이 있는데요, 이번에 Tekton을 다뤄볼 기회가 생겨 블로그에도 간단히 정리를 해두려 합니다.

Kubernetes가 Container Orchestration계의 de-facto가 되고나서 여러 툴들이 각자 영역의 de-facto로 자리잡았지만, 아직 CI/CD쪽은 뚜렷한 강자가 없는 것으로 알고 있습니다.

그런데 왜 Tekton을 골라서 공부를 시작했느냐!
beta로 올라온지는 얼마 안된 신생 프로젝트이지만, 여러 곳에서 Tekton을 사용하고 있습니다.
예를들어 전통의 강자 Jenkins의 후예 Jenkins X에서도 pipeline으로 tekton을 사용하고 있고, Openshift에서도 4.7버전부터 자체 pipeline서비스로 Tekton을 추가하였습니다.

다른 pipeline툴들에 비해 어느정도 성능이 나오고 어떤 기능이 좋은가는 아직 모르겠지만 일단 여러 메이저 툴들이 Tekton을 쓰고있고 쿠버네티스를 위해 처음부터 설계된 툴이니만큼 앞으로도 더 발전할 툴이라고 생각합니다.
(그리고 로고가 귀여워요ㅎㅎ)

(21.06.09) 해당 문서는 Tekton Pipeline v0.24.1 을 기준으로 제작되었습니다.

Tekton?

Tekton 이란?

Tekton은 CI/CD 파이프라인을 빠르게 구축하기 위한 프레임워크를 제공하는 Cloud-native 오픈소스 프로젝트입니다.(CD foundation Project)

Tekton의 구성 요소들은 Kubernetes의 CRD(Custom Resource Definitions)로 정의되어 다른 pod이나 resource와 같이 Kubernetes CLI와 API call로 사용할 수 있습니다.

Tekton의 특징

• 재사용 : tekton의 모든 task들은 다른 pipeline과 완전히 독립적으로 사용할 수 있습니다. 즉 모듈화가 잘 되어있어 여러 pipeline에서 필요한 task들을 갖다 쓸 수 있습니다.
• 표준화 : Tekton은 Kubernetes의 Custom Resource를 사용해 정의됩니다.
• 기능의 확장성 : Tekton Hub를 통해 Tekton커뮤니티에서 제작한 여러 종류의 task들을 사용할 수 있습니다.

구조

Tekton파이프라인은 크게 4가지 Component들로 구성되며 Kubernetes의 Custom Resource로 정의됩니다.

• Task
• TaskRun
• Pipeline
• PipelineRun

Step

Step하나는 작업하나라고 생각하시면 됩니다.
예를들어 Python app의 유닛테스트라던지, Java app의 compile작업, Git Clone 등 하나의 작업 모듈을 Step이라고 합니다.

Task

Task는 Step들의 모음입니다. Task하나당 하나의 Pod으로 동작합니다.

Pipeline

Pipeline은 task들의 모음입니다. Pipeline 속 task들은 순차적으로 실행되게 됩니다.
task의 RunAfter구문을 통해 이전 task가 끝난 뒤 다음 task가 실행되게 할 수 있습니다.

TaskRun

단일 Task를 실행시키는 역할을 합니다.
Task를 실행시킬 때의 서비스어카운트, 사용할 리소스 정의, task들의 pod설정 등을 할 수 있습니다.

PipelineRun

마찬가지로 이름에서 알 수 있듯이 Pipeline을 실행시키는 역할을 합니다.
Pipeline이 실행될 때 Pipeline 내 task들은 workspace라는 이름의 볼륨을 공유하게 할 수 있습니다.

TaskRun과 마찬가지로 각 Task가 실행될 때의 서비스어카운트, workspace정의, 파라미터, pod설정 등을 할 수 있습니다.

PipelineRun을 실행시키면 각 Task에 해당하는 TaskRun을 자동으로 생성시켜 실행하기 때문에 별도로 TaskRun을 정의해주지 않아도 됩니다.

Workspace

Workspace는 Task들의 볼륨으로 사용됩니다.
Task별로 사용할 workspace를 지정할 수 있으며, Task를 실행시키는 TaskRun이나 PipelineRun에서 실제 볼륨을 workspace에 붙여줄 수 있습니다. (PVC또는 EmptyDir)

예를 들어, 다음과 같은 task들을 정의해둔 Pipeline이 있다고 합시다.

task 1. clone git repository
task 2. build repository

깃 레포를 클론해서 -> 빌드하는 간단한 파이프라인입니다.

Task별로 Pod을 따로 생성하게 될거고,
클론한 레포를 빌드해야하니 이 두개의 Pod은 리소스를 공유하고 있어야 합니다.
이때 별개의 Task간의 공유 스토리지가 Workspace가 됩니다.

Workspace는 PVC를 붙여줄 수도 있고 EmptyDir을 붙여줄 수도 있습니다.
Task하나를 실행시킬 시에는 딱히 다른 pod과 공유할 필요가 없기때문에 EmptyDir로 붙여줘도 되지만,
Task가 여러개이고 위 예시와 같이 선행 task의 output을 가지고 작업을 해야하는 경우 공유되는 스토리지가 필요하기때문에 물리적인 리소스(PVC)를 붙여주어야 합니다.

그래서 위 예시는 다음과 같은 flow로 진행될 것입니다:
PV-PVC간 Bound -> PVC를 Workspace로 사용하겠다고 PipelineRun에 선언 (Task에서도 어떤 workspace를 사용할 건지 지정) -> Task 1번 pod이 workspace(pvc)와 Bind -> 깃 레포를 Workspace에 클론 -> Task1번 pod unbound -> Task 2번 pod과 workspace(pvc) Bind -> Workspace에 접근해서 빌드 작업 수행 -> Task 2번 pod unbound

조금 복잡하긴 하지만 이 뒤의 포스팅에서 직접 Hands-On을 해보면 쉽게 이해하실 수 있을겁니다.

그 런 데 !!!!

여기까지 읽으신 분들은 하나 궁금증이 드실겁니다.(왜냐면 제가 궁금했기 때문^^)

“PV와 PVC가 RWO(Read-Write-Once) Accessmode로 설정될 경우 어떻게 여러 Pod에서 PVC에 Bound가 될 수 있지???”

기본적으로 Kubernetes는 “Automatic Bin-packing” 기능을 탑재하고 있어 Pod이 생성될 때 특별히 NodeSelector나 Affinity를 지정하지 않는 이상, 그때그때마다 적절한 Node에 배포되게 됩니다.
그래서 Pod이 어디에 배포될지는 Kube-Scheduler만 아는 내용인거죠.

그런데! PV/PVC의 볼륨 AccessMode에는 세가지 옵션이 있습니다.

• ReadWriteOnce(RWO) : 하나의 노드에만 마운트되고 하나의 노드에서만 읽고쓰기 가능.
• ReadOnlyMany(ROX) : 여러개의 노드에 마운트가능, 여러개의 노드에서 동시에 읽기 가능, 쓰기는못함.
• ReadWriteMany(RWX) : 여러개의 노드에 마운트가능, 여러개의 노드에서 읽고쓰기 가능.

ROX나 RWX모드같은경우 여러 노드에서 접근할 수 있지만 RWO같은경우 하나의 노드에서만 볼륨에 접근할 수 있습니다.

즉, RWO모드의 볼륨같은 경우 PipelineRun에서 생성하는 Task(Pod)가 모두 같은 노드에 생성되어야만 정상적으로 볼륨 Binding이 가능하게 되는 겁니다.

그래서 Tekton에서는 RWO모드의 볼륨을 Workspace로 사용하는 경우를 대비하여 Affinity Assistants라는 기능을 제공하고 있습니다.

Affinity Assistants는 Pipeline 내 모든 Task를 같은 Node에 배치하게 하는 역할을 합니다.
Pipeline에 PVC가 Workspace로써 선언되게 되면, Affinity Assistants가 생성되어 각 Task들이 동일한 Workspace를 공유할 수 있게 동일한 node에 pod들을 배치하게 됩니다.
즉, 타 Affinity rule과는 양립할 수 없으며 PodTemplate을 따로 만들어 NodeSelector나 Tolerations를 설정했다고 해도 Affinity Assistant가 그 설정들을 바꿔버리게 됩니다.

참고 : tekton.dev/Workspaces - Specifying Workspace order in a Pipeline and Affinity Assistants

RWO모드를 사용하는 Pipeline의 경우 Affinity Assistant의 도움이 필수적으로 필요하지만 사실 다른 모드의 볼륨을 사용할 경우 Affinity Assistant가 필요하지 않을 수 있습니다.
이럴 경우, tekton pipeline controller의 Configmap에서 disable-affinity-assistant를 True로 수정하면 됩니다.

참고 : disable-affinity-assistant

정리!
tekton pipeline을 실행시키면 Affinity Assistant가 각 Task들을 동일한 노드에 배치하는 역할을 한다!

한줄정리

• Tekton : CI/CD 파이프라인을 빠르게 구축하기 위한 프레임워크를 제공
• Task : 작업을 정의
• Pipeline : Task들의 모음집
• TaskRun/PipelineRun : 이름그대로 실행시키는 역할
• Workspace : task들간 공유 스토리지
• Affinity Assistant : task들을 동일한 Node에서 실행시키는 것을 보장하는 Tekton의 기능

---

여담으로 Tekton을 공부하면서 Ansible과 굉장히 유사하다는 생각을 받았습니다.
Task라는 단어를 동일하게 사용하는 면도 그렇고 내부 작업들이 철저하게 모듈화되어 돌아가는 부분들이 비슷하다고 느껴져서 좀 친숙하게 다가갈 수 있었던 것 같습니다.
(하는 역할도 비슷한 것 같음…ㅋㅋ)

다음 포스팅부터는 Tekton을 설치해보고 각 요소들이 어떤식으로 구성되는지 알아보도록 하겠습니다.

---