Demystifying Argo Workflows: Architectural Deep Dive
https://youtu.be/FBRMURQYbgw?si=ThzZoEeIH2HCdVez
CRD, Workflow Controllers, Argo Server 등 Argo Workflows를 구성하는 컴포넌트들 소개 / 설명.
Workflow: Defines a Set of Actions.
- Action을 Sequence / Parallel / Combinations of Both 등 다양한 형태로 실행할 수 있음.
- Workflow가 다른 Workflow를 실행한다거나, task 간 dependency가 걸려 있는 형태의 작업도 수행 가능.
- Argo는 DAG / Graph 형태로 실행.
사용자는 argo Workflow의 yaml 형식만 잘 맞춰서 배포하면 된다.
따라서, 아래와 같은 작업에 최적화되어 있음
- CI / CD 작업
- Compute-intensive Job (ML pipeline / data processing)
CRD
argo 설치할 때 일반적으로 클러스터에 배포되는 리소스들은 위와 같다.
- Deployments: Argo Server, Workflow Controller
- 8 CRDs
역할을 간단하게 정리하면
- Workflows
- CronWorkflows: execute workflow using cron syntax
- WorkflowTemplate, ClusterWorkflowTemplate: define a library of reusable workflows.
- WorkflowTaskSets: exchange data between main workflow controllers / Argo Exec Agent.
- WorkflowTaskResults: workflow의 실행 결과물 저장.
- WorkflowArtifactGCTasks: 안쓰는 workflow 자동으로 GC하는 CR.
- WorkflowEventBindings: workflow 이벤트를 trigger로 특정 workflow를 실행하는 기능.
Workflow Controller
Workflow 관련된 모든 CR 작업을 처리하는 컴포넌트.
- Operator Pattern으로 구현된 k8s Operator.
- configuring / deploying / orchestrating instances of stateful applications.
- k8s API와 통신이 많다는 점에 유의.
- HA mode 또는 namespaced deployment 형태로 사용할 수 있다.
HA Mode / Namespaced Mode로 구분됨.
HA 모드일 경우 Controller가 Active-Standby 방식으로 동작한다.
- leader election으로 선정된 하나만 작업.
Namespaced 모드일 경우, 특정 Namespace에 deployment가 배포
- 본인이 배포된 namespace에 있는 workflow만 관리한다.
Workflow CR을 배포하면, etcd에 정보가 기록된다.
- Controller는 CR 배포 시 발생하는 k8s 이벤트를 informer로 감지해서 동작.
- informer를 써서, 매번 k8s API를 호출하는 방식 대신 only act on change.
- Workflow 정보를 Queue에 기록하면, worker가 queue에서 받아 실행하는 구조.
Worker: Workflow CR 내용을 파싱해서, 적절한 Action 또는 job을 실행하는 컴포넌트.
- creating pods / pod reconciliation / other things.
Argo Server
모든 작업을 kubectl 활용해서 Workflow Controller에 작업 요청할 수도 있으나, Argo Server를 사용할 수도 있다.
- k8s에 익숙하지 않은 외부 사용자의 편의를 위한 서버라고 보면 됨.
- argo cli는 argo server와 통신한다.
- API 제공, Authentication (SSO with Dex) 지원
- Workflow Archive, Offloading Large Workflows, Argo Events 기능을 지원한다.
Pods
거의 대부분의 경우, workflow의 step 하나당 Pod 1개를 의미한다.
- suspend template이거나, Workflow of workflows 방식인 경우는 예외.
따라서, pod를 만들 수 있다면 workflow를 만들 수 있다.
- 즉 pod의 특징이 그대로 반영된다.
- resource request / limits
- RBAC
- Volume Mount / Metrics
- Workspace: 각 step은 own workspace에서 실행됨. 따라서 각 step당 fetching artifacts를 위한 parameter setting도 생각해야 한다.
- wait container, init container와 같은 걸로 대응함.
- short-lived steps인 경우 containerSet이라는 template으로도 대체 가능
- ...
Pod is Step, Step is Pod인 건 알겠는데, Pod 내부에서는 정확히 어떤 동작이 이루어지는가?
- pod 내부엔 총 3가지의 container가 존재할 수 있다.
- init container: main container가 뜨기 전에 실행됨. 필요한 artifact들 미리 fetch해서 사용할 수 있도록 하는 등의 작업
- main container: 사용자가 의도한 action을 수행.
- wait container: wait / perform tasks / cleanup job 수행
main container에서는 Step Template을 어떤 걸 썼냐에 따라 동작이 약간 달라질 수 있다.
- script Template, Container Template, containerSet Template를 쓸 경우: Step이 실행될 container image를 입력받기 때문에 PodSpec과 비슷한 형태가 된다.
- 약간의 추상화가 들어가 있는데, argo exec가 main container의 volume mount 형태로 동작한다. argo exec가 실행되고, 사용자의 로직이 Subprocess 형태로 실행됨.
- container image를 명시하지 않는 HTTP Template, Resource Template
- argo 내부에서 main container를 만들고, Argo Exec image를 사용해서 pod를 실행한다.
killercoda에서 hands on 가능하다