샤드는 셋인데 파드는 하나만 떴다

목표

앞 단계가 만든 데이터로 뒤 단계의 모양이 정해지는 파이프라인을 Argo Workflows 로 실제로 돌립니다. 스크립트 출력으로 팬아웃하고,
조건으로 가지를 나누고, 흩어진 결과를 모으고, 실패를 흡수하고, 승인을 기다리고, 워크플로 사이에 잠금을 거는 것을 노드 기록으로 확인합니다.

왜 중요한가

데이터 처리 파이프라인은 실행하기 전에는 몇 조각을 처리할지 모릅니다. 입력을 나누는 단계가 돌아야 조각 수가 정해지고,
그 수만큼 병렬 작업이 생겨야 합니다. YAML 에 목록을 미리 적는 방식으로는 이것을 표현할 수 없어서 Argo Workflows 는
한 노드의 출력을 다음 노드의 반복 목록으로 쓰는 withParam, 원소마다 평가되는 when, 팬아웃 출력의 자동 집계를 둡니다.
대신 병렬성이 기본이라 공유 자원을 쓰는 단계에는 상한과 잠금을 직접 걸어야 하고, 조각 하나의 실패를 전체 실패로 볼지도 설계로 정해야 합니다.
시험은 이 템플릿 종류와 spec 필드가 실행에서 무엇을 바꾸는지를 묻습니다.

단계

1. /root/capa-data/split.yaml 에 Workflow 를 작성해 argo 네임스페이스에 제출하고 끝날 때까지 기다리세요. generateName split-, 라벨 capa-data: split, entrypoint DAG main 에서 script 템플릿 split(이미지 alpine:3.20, command [sh])이 표준 출력으로 JSON 목록 [{"id":"a","size":3},{"id":"b","size":12},{"id":"c","size":7}] 한 줄만 내고, 그 뒤 태스크 peek 가 그 결과를 파라미터 shards 로 받아 busybox:1.36 으로 출력합니다.
2. /root/capa-data/fanout.yaml 에 Workflow(generateName fanout-, 라벨 capa-data: fanout)를 작성해 제출하세요. entrypoint DAG main 에서 태스크 split(1단계 script 템플릿) 뒤에 태스크 process 가 split 의 결과 목록을 withParam 으로 받아 원소마다 파라미터 id·size 로 컨테이너 템플릿 process(busybox:1.36)를 실행해야 합니다. 워크플로가 Succeeded 여야 합니다.
3. /root/capa-data/serial.yaml 에 2단계와 같은 팬아웃 Workflow 를 generateName serial-, 라벨 capa-data: serial 로 만들되, process 컨테이너가 sleep 3 을 하고 DAG 템플릿 main 에 parallelism: 1 을 두어 제출하세요. 세 process 파드의 실행 구간이 서로 겹치지 않아야 합니다.
4. /root/capa-data/branch.yaml 에 Workflow(generateName branch-, 라벨 capa-data: branch)를 작성해 제출하세요. split 뒤에 두 태스크 big·small 이 모두 같은 목록을 withParam 으로 받고, big 은 when 으로 size 가 10 초과인 원소만, small 은 10 이하인 원소만 컨테이너 템플릿 work(파라미터 id·lane)를 실행합니다. 조건이 거짓인 원소의 노드는 Skipped 로 남아야 합니다.
5. /root/capa-data/agg.yaml 에 Workflow(generateName agg-, 라벨 capa-data: agg)를 작성해 제출하세요. 팬아웃 태스크 count 는 원소마다 seq 1 <size> 의 줄 수를 파일로 세어 출력 파라미터 lines(valueFrom.path)로 내고, 태스크 total 은 {{tasks.count.outputs.parameters.lines}} 를 파라미터 values 로 받아 script 로 합을 계산해 파일에 쓰고 출력 파라미터 sum 으로 냅니다. total 노드의 출력 파라미터 sum 이 세 size 의 합이어야 합니다.
6. /root/capa-data/tolerate.yaml 에 Workflow(generateName tolerate-, 라벨 capa-data: tolerate)를 작성해 제출하세요. 팬아웃 태스크 check 는 size 가 10 을 넘으면 종료 코드 3 으로 실패하는 컨테이너를 돌리되 continueOn 으로 실패를 흡수하고, 그 뒤 태스크 report 가 실행됩니다. b 조각의 노드는 Failed, 워크플로와 report 는 Succeeded 여야 합니다.
7. /root/capa-data/approve.yaml 에 steps 로 split → suspend 템플릿 approve → 컨테이너 템플릿 publish 순서인 Workflow(generateName approve-, 라벨 capa-data: approve)를 작성해 --wait 없이 제출하세요. 워크플로가 approve 에서 멈춘 것을 확인하고 10초 이상 기다린 뒤 argo resume 으로 재개해 Succeeded 로 끝나게 합니다.
8. argo 네임스페이스에 ConfigMap capa-data-locks(키 warehouse 값 "1")를 만들고, /root/capa-data/locked.yaml 에 spec.synchronization 으로 그 키를 세마포어로 쓰는 Workflow(generateName locked-, 라벨 capa-data: locked, 컨테이너가 sleep 8)를 작성하세요. 같은 파일로 워크플로 두 개를 연달아 제출해 둘 다 Succeeded 로 끝나게 합니다. 두 워크플로의 실행 구간은 겹치지 않아야 합니다.

참고

• VM 안에 k3s 와 Argo Workflows v4.1.3(argo 네임스페이스), argo CLI 가 있습니다. 워크플로는 argo 네임스페이스의 default 계정으로 돕니다. busybox:1.36·alpine:3.20 은 미리 받아 두었습니다.
• 제출과 대기: argo submit -n argo <파일> --wait, 노드 보기: argo get -n argo <이름>, 목록: argo list -n argo -l capa-data=<값>.
• 채점기는 각 단계 라벨의 가장 최근 워크플로를 봅니다. 고쳐서 다시 내면 새 워크플로로 채점됩니다.
• 흔한 실수: withParam 에 {{steps...}} 와 {{tasks...}} 를 섞어 쓰는 것. DAG 안에서는 tasks, steps 안에서는 steps 입니다.
• 흔한 실수: when 식의 문자열을 따옴표 없이 비교하는 것. 숫자 비교는 그대로, 문자열 비교는 작은따옴표로 감쌉니다.
• [Loops(withParam)](https://argo-workflows.readthedocs.io/en/latest/walk-through/loops/) · [Conditionals](https://argo-workflows.readthedocs.io/en/latest/walk-through/conditionals/) · [Suspending](https://argo-workflows.readthedocs.io/en/latest/walk-through/suspending/) · [Synchronization](https://argo-workflows.readthedocs.io/en/latest/synchronization/) · [Field Reference(continueOn)](https://argo-workflows.readthedocs.io/en/latest/fields/)

단계 8개

1. 스크립트의 표준 출력이 데이터가 된다
2. 앞 단계의 목록 길이만큼 파드가 생긴다
3. 팬아웃을 한 번에 하나씩 흘려보낸다
4. 크기에 따라 다른 가지로 보낸다
5. 흩어진 결과를 다시 모아 합친다
6. 한 조각의 실패를 흡수하고 보고까지 간다
7. 사람이 승인할 때까지 멈춰 선다
8. 두 워크플로가 같은 창고에 동시에 쓰지 못하게