studybook
  • Introduction
  • 실무 하며 깨닫는 부분 정리
    • 옵션에 대해서
    • 코드 작성의 순서
    • 자바 프로그램에 문제가 생겼다면
    • 장애 대처법
  • Logstash, Beats 정리
  • Zookeeper 정리
  • Message Queue 정리
    • RabbitMQ 삽질
  • Java 관련 정리
    • Java Primitive Wrapper class
    • Java NIO
    • Java8 Double colon operator
    • Effective Java
      • 4장
      • 5장
      • 6장 - Enum, Annotation
      • 7장 - Method
      • 8장 - 프로그래밍 일반
      • 9장 - Exception
    • Java8 Lambda expression
    • JDBC
    • Linux에서 WatchService 이상동작
  • Spring 관련 정리
    • Spring Bean init, destroy 순서
    • Spring Async Controller
    • Spring Executable jar 웹 개발 및 배포
    • Spring Boot Font 배포 에러
    • Spring AOP
      • Spring AOP로 모든 Request 로그 남기기
    • Spring Cache
    • Spring Cloud
      • Consul로 spring 설정 관리하기
    • Spring Test
      • Spring Test DirtiesContext
      • Spring Test MockBean, SpyBean
      • Spring Test Dynamic @Scheduled
    • Spring JDBC
    • Spring Validation
    • Spring Transaction Management
      • Spring with JTA 삽질
    • Spring에서 효율적으로 Static resource 관리하기
    • Zuul을 사용해서 Spring Reverse proxy 만들기
    • Spring Security
    • 스프링 어노테이션이 안 먹힐 때 의심해볼만한 것
    • Spring Data
    • Spring Webflux
      • Tobi 강연
  • 코드 리팩토링
    • 한번에 하나씩
  • 지속적 통합 (CI)
    • Jenkins pipeline 삽질기
  • Log Aggregator 정리
    • Flume 테스트
    • Fluentd 테스트
  • Web Socket 정리
  • Akka
    • Actor 모델
    • Supervision
  • IE 8 대응 정리
  • 함수형 프로그래밍
    • 모나드
  • Netty
    • Netty 기본 예제
    • Netty 주요 특징
    • Netty 부트스트랩
    • Netty 채널 파이프라인, 코덱
    • Netty 이벤트 모델
    • Netty 바이트 버퍼
  • 스칼라 관련 정리
    • Maven으로 컴파일하기
    • Scala def 괄호 여부의 차이
    • 스칼라 function, method 차이점
    • ScalaTest와 Spring 연동하기
    • Programming in Scala
  • J2S 컨퍼런스
  • Android
    • 테스트
    • NDK
  • DDOS
  • HTTP
  • HttpClient
  • Container
    • Image 개요
    • cri-o
    • kata containers
    • Open Container Initiative Image
    • Buildkit
  • Github pages
  • Static Website
  • Webhook
  • Service Discovery Tools
    • Etcd
    • Eureka
    • Consul
      • ACL
    • 비교
  • React
    • JSX
    • React Element
    • Components, Props
    • State, Lifecycle
    • Handling Event
    • Flux
  • Vagrant
    • SSH 접속
  • Linux
    • Systemd
    • Alternatives
  • Messaging protocols
    • XMPP
    • AMQP
  • Windows
    • Windows10 내장 우분투에 ssh 클라이언트로 접속하기
    • Windows10 Hyper-V와 Virtual Box가 충돌을 일으켰을 때
    • Hyper-V 기반 docker에서 Shared Drives 설정 실패할 때
    • 윈도우 개발환경 설정
    • Docker desktop 없이 docker 환경 세팅하기
    • UWP 앱을 항상 관리자권한으로 실행하는 바로가기 만들기
  • Spring camp 2017
    • Project Reactive
    • 이벤트 소싱
    • CQRS
  • Spring webflux
  • 리액티브 프로그래밍
  • Linux Settings
    • 홈서버 백업 및 복구기
    • 홈서버 트러블슈팅
  • Kubernetes
    • k3s 설치 및 삽질
    • pod resources
    • Argo workflow
    • 트러블 슈팅
      • Kubernetes namespace의 phase가 Terminating에서 멈춰있을 때
    • 쿠버네티스 마스터
    • Knative
    • Knative Pipeline
    • Aggrerated API server
    • Accessing the API
      • Authenticating
  • Sonarqube
  • HTTP/2
  • Go
    • Go Module
    • Go dependency injection
    • Go Error handling
    • Go in Action
      • 3장 패키지
      • 4장 배열, 슬라이스, 맵
      • 5장 GO의 타입 시스템
      • 6장 동시성
      • 7장 동시성 패턴
      • 8장 표준 라이브러리
      • 9장 테스트와 벤치마킹
    • Go Channel 사용법
  • Cloud Native
Powered by GitBook
On this page
  • 설치법
  • 기본 용어
  • 기본 개념
  • Variable
  • Template Tag Kinds
  • Inputs
  1. Kubernetes

Argo workflow

쿠버네티스 기반 워크플로우 툴

설치법

$ curl -sSL -o /usr/local/bin/argo <https://github.com/argoproj/argo/releases/download/v3.3.2/argo-linux-amd64>
$ chmod +x /usr/local/bin/argo
$ kubectl apply -f <https://raw.githubusercontent.com/argoproj/argo-cd/master/manifests/namespace-install.yaml>

기본 용어

  • Workflow: 쿠버네티스 리소스. 하나 또는 그 이상의 template을 실행한 것. 별개로 이름을 가짐.

  • Template: 하나의 step 또는 여러 step들의 집합 또는 DAG

  • Step: workflow의 하나의 동작 단계. 보통 input을 넣어 컨테이너를 실행한 다음 output을 획득하는 방식으로 동작

  • Entrypoint: workflow의 첫번째 step

  • Node: step과 동의어

  • Directed Acyclic Graph (DAG): 여러 step(==node)과 dependency(==edge)의 그래프.

  • Workflow Template: 쿠버네티스 리소스. namespace에 재사용 가능한 workflow spec을 정의해둔 것.

  • Cluster Workflow Template: 쿠버네티스 리소스. workflow template과 기본적으로 동일하지만 cluster 전역에서 사용가능.

  • Inputs: step을 실행할 때 전달되는 parameters, artifacts

  • Outputs: step의 실행 결과로 얻을 수 있는 parameters, artifacts

  • Parameters: object, string, boolean, array

  • Artifacts: 컨테이너에 저장된 파일

  • Artifact Repository: artifact들이 저장되는 장소

  • Executor: 컨테이너를 실행하기 위한 수단. Docker 또는 PNS와 같은 것들.

  • Workflow Service Account: workflow를 실행할 때 사용되는 service account

기본 개념

  1. Workflow

    1. 이미 실행된 workflow를 정의하고 있음

    2. workflow의 상태에 대한 정보를 가지고 있음

    3. 따라서, workflow는 static이 아닌 “live” object로 간주해야하고 어떤 정의에 대한 instance로 간주해야함.

  2. Workflow.spec

    1. templates:

      1. container: 가장 일반적. 주어진 이미지로 컨테이너 만들어서 명령어 실행

      2. script: container와 대부분 동일하지만 source 필드를 사용할 수 있음. source 필드는 즉시 작성해서 쓸 수 있는 script라고 보면 됨. source 필드의 결과물은 {{tasks.<NAME>.outputs.result}} 또는 {{steps.<NAME>.outputs.result}} 중 하나에 저장됨.

      3. resource: 클러스터 리소스에 접근하는데 사용됨. get, create, apply, delete, replace, patch 등 일반적인 kubectl와 동일하게 사용 가능

      4. suspend: argo resume 을 실행할 때까지 또는 주어진 시간만큼 대기

    2. entrypoint: 가장 먼저 실행되는 template

    3. template invocators

      1. steps:

        1. template의 리스트. 이중 배열이라고 보면 되는데 바깥 배열의 경우 순차로 하나하나 실행하는 반면 내부 배열은 병렬로 실행함. 따라서 아래 예제의 경우 step1 → step2a, step2b 와 같은 순서로 실행됨

        - name: hello-hello-hello
            steps:
            - - name: step1
                template: prepare-data
            - - name: step2a
                template: run-data-first-half
              - name: step2b
                template: run-data-second-half
        1. 필요하다면 when 과 같은 필드를 사용해서 step의 실행조건을 넣을 수도 있음.

      2. dag:

        1. template들을 dependency graph로 구성할 수 있음. 각각의 template는 task가 됨. dependencies가 존재하지 않는 task는 즉시 실행됨. dependencies에는 하나 또는 여러개의 task를 넣을 수 있는데 이 dependency task가 모두 완료되어야만 실행됨. 따라서 아래 예제의 경우 A → B,C → D 순서로 실행됨.

        - name: diamond
            dag:
              tasks:
              - name: A
                template: echo
              - name: B
                dependencies: [A]
                template: echo
              - name: C
                dependencies: [A]
                template: echo
              - name: D
                dependencies: [B, C]
                template: echo

Variable

workflow spec의 어떤 필드들은 미리 정의된 variable을 사용할 수 있음.

사용법은 simple, expression 두가지가 있음.

Template Tag Kinds

Simple

{{ workflow.name }}

해당 이름을 가진 tag의 값으로 대치됨.

Expression

{{= workflow.name }}

v3.1버전부터 사용 가능

tag의 내용을 연산한 다음 결과물로 대치함.

만약 parameter 이름이나 step 이름에 하이픈이 존재할 경우 에러가 발생하므로 index를 사용하는 방식으로 피해야함 ex) inputs.parameters['my-param'] steps['my-step'].outputs.result

Inputs

Parameter

workflow의 argument는 entrypoint template에 전달됨

template의 inputs는 template caller (steps, dag 등)에 의해 전달됨

DAG의 경우 dependency task에서 output을 받아 input으로 사용하고 싶을 수 있음. 이런 경우에는 artifact, parameter 두가지 방식이 존재. 차이점은 parameters는 value 필드를 쓰고 artifact는 from 필드를 쓴다는 것.

Previouspod resourcesNext트러블 슈팅

Last updated 3 years ago