안녕하세요! 이번시간에는 Argo Event 의 개념과 아키텍처에 대해서 알아보고자 합니다.

ArgoWorkflow 를 이용하고 있는 개발자라면, Argo Event 탭에 대해대해서 궁금증을 가지고 있을텐데요 (그게 제이야기 입니다.) 이번 시간에 한번 Argo Event 에 대한 개념을 잡고 가는 것도 좋을 것같습니다.

이미지 원본 출처: https://blog.argoproj.io/argo-workflows-v3-0-4d0b69f15a6e

출처는 공식문서입니다.

https://github.com/argoproj/argo-events
https://argoproj.github.io/argo-events/
요약: Argo Events - Kubernetes를 위한 event dependency 트리거 관리자.
- 외부 event → 이해할 수 있는 Kubernetes용 이벤트로 전환하고 (event Source)→ 해당 event 에 대해 subscribe 하고 있던 매핑된 트리거가 있는 경우(Eventbus,Sensor ) →sensor 가 트리거를 수행한다(Trigger)
다양한 이벤트가 있겠지만, 제 관심사는 hdfs 이벤트를 듣고 argo workflow 를 트리거하는 것이여서, hdfs, argo workflow 예시를 차용했습니다.

Argo Event란?

Argo Events 는 Webhook, S3, 일정, 메시징 대기열, gcp pubsub, sns, sqs와 같은 다양한 소스의 이벤트에서 K8s 개체, Argo Workflows, Serverless 워크로드 등을 트리거하는 데 도움이 되는 Kubernetes용 이벤트 기반 워크플로 자동화 프레임워크입니다.

특징

20개 이상의 이벤트 소스에서 이벤트를 지원합니다.
워크플로 자동화를 위한 비즈니스 수준 제약 논리를 사용자 지정하는 기능이있습니다.
단순한 선형 실시간 이벤트부터 복잡한 다중 소스 이벤트까지 모든 것을 관리합니다.
Kubernetes Objects, Argo Workflow, AWS Lambda, Serverless 등을 트리거로 지원합니다.
CloudEvents에 호환됩니다..

아키텍처

argo event 의 메인 컴포넌트는 총 4가지로 구성되어있습니다.( 사실상 sensor 에서 trigger하는 것이기 때문에, 3가지로 보는 경우도 있습니다.)

1. Event Source

“이벤트소스"는 외부 소스의 이벤트(예.AWS SNS, SQS, GCP PubSub, Webhooks, etc)를 consume하는데 필요한 configuration을 정의합니다.
이것은 더 나아가 이벤트를 클라우드이벤트(cloudevents)로 바꾸고, EventBus에 클라우드이벤트를 가져옵니다.(dispatching)

1.1. Available event-sources

HDFS, Slack , GitHub, minio, kafka, AMQP, AWS SNS, AWS SQS, Azure Events Hub, Bitbucket, Bitbucket ServerCalendar, Emitter, File Based Events, GCP PubSub, Generic EventSource, GitHub, GitLab, K8s Resources, Kafka, Minio, NATS, NetApp StorageGrid, MQTT, NSQ, Pulsar, Redis, Stripe, Webhooks

1.2. Specification

특징은 각 Resource Type에 따라 필드가 다릅니다.
다른 이벤트 소스의 필드가 궁금하다면, https://github.com/argoproj/argo-events/blob/master/api/event-source.md 여기에서 참고해주세요.

EventSource

EventSource는 이벤트 소스 리소스의 정의입니다.

metadata
spec
1. eventBusName
  1. EventBusName은 EventBus 이름에 대한 참조입니다. 기본적으로 값은 "default"입니다.
2. template
  1. (optional) 템플릿은 이벤트 소스의 pod 사양입니다.
3. service
  1. (optional) 서비스는 이벤트 소스를 노출하는 service의 사양입니다.
4. hdfs
  1. 맵\[문자열\]github.com/argoproj/argo-events/pkg/apis/eventsource/v1alpha1.HDFSEventSource
  2. HDFS 이벤트 소스
status
1. 이벤트 소스 상태
  1. EventSourceStatus는 이벤트 소스 리소스의 상태를 보유합니다.

1.3. example

다른 예시는 모두 아래 링크에서 확인가능합니다. : https://github.com/argoproj/argo-events/tree/master/examples/event-sources

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: hdfs
spec:
  hdfs:
    example:
      directory: "/tmp/"
      type: CREATE
      path: x.txt
      addresses:
        - my-hdfs-namenode-0.my-hdfs-namenode.default.svc.cluster.local:8020
        - my-hdfs-namenode-1.my-hdfs-namenode.default.svc.cluster.local:8020
      hdfsUser: root
#  template:
      # krbCCacheSecret:
      #   name: krb
      #   key: krb5cc_0
      # krbKeytabSecret:
      #   name: krb
      #   key: user1.keytab
      # krbUsername: "user1"
      # krbRealm: "MYCOMPANY.COM"
      # krbConfigConfigMap:
      #   name: my-hdfs-krb5-config
      #   key: krb5.conf
      # krbServicePrincipalName: hdfs/_HOST

2. EventBus

https://argoproj.github.io/argo-events/eventbus/eventbus/
https://github.com/argoproj/argo-events/blob/stable/api/event-bus.md
EventBus는 이벤트소스와 센서를 연결하여 argo events 의 전송계층 역할을 하는 Kubernetes Custom Resource입니다.
EventBus는 namespace입니다. EventSource 및 Sensor가 작동하도록 하려면 네임스페이스에 EventBus 개체가 필요합니다.
일반적인 방법은 default네임스페이스에 명명된 EventBus를 만드는 것입니다. 다른 이름을 사용하거나 하나의 네임스페이스에 여러 EventBus를 사용하려면 eventBusNameEventSource 및 Sensor의 사양에서 해당 항목을 지정해야 올바른 이름을 찾을 수 있습니다.
eventbus에는 2가지 구현 방법이 있습니다. : NATS streaming(will be deprecated) and now NATS Jetstream

2.1. specification

https://github.com/argoproj/argo-events/blob/stable/api/event-bus.md#eventbus

metadata
spec
1. nats
2. jetstream
status

2.2. examples

https://github.com/argoproj/argo-events/blob/stable/examples/eventbus/native.yaml

apiVersion: argoproj.io/v1alpha1
kind: EventBus
metadata:
  name: default
spec:
  nats:
    native:
      # Optional, defaults to 3. If it is < 3, set it to 3, that is the minimal requirement.
      replicas: 3
      # Optional, authen strategy, "none" or "token", defaults to "none"
      auth: token
#      containerTemplate:
#        resources:
#          requests:
#            cpu: "10m"
#      metricsContainerTemplate:
#        resources:
#          requests:
#            cpu: "10m"
#      antiAffinity: false
#      persistence:
#        storageClassName: standard
#        accessMode: ReadWriteOnce
#        volumeSize: 10Gi

3. Sensor

Sensor는 event dependency(inputs)들과 trigger(outputs)들의 set 를 정의합니다(binding을 관리하는 관리자역할로 보입니다). Sensor는 Eventbus 에서 event를 듣고, trigger를 수행하는 이벤트 관리자 역할을 수행합니다.(실질적으로 행동대장)
event dependency란?: dependency는 Sensor가 발생하길 대기하고 있는중인 이벤트입니다.

3.1. specification

https://github.com/argoproj/argo-events/blob/master/api/sensor.md#argoproj.io/v1alpha1.Sensor

https://github.com/argoproj/argo-events/blob/master/api/sensor.md#template

metadata
spec
1. dependencies : EventDependency
  - sensor 가 의존하고있는 이벤트들의 리스트
  - - name: dep01 eventSourceName: webhook-a eventName: example01
2. triggers
  1. condition 에 따라 다르게 trigger 가능하다.
3. template
  1. (Optional)
4. errorOnFailedRound
  1. ErrorOnFailedRound가 true로 설정되면, error되면 이전 트리거 라운드가 실패한 것처럼 센서 상태를 표시합니다.
5. eventBusName
  1. EventBus name을 지정한다. 기본값은 “default”이다.
6. replicas
  1. sensor deployment replica 개수를 씁니다.(int32)
status: sensor status

3.2. examples

example: https://github.com/argoproj/argo-events/tree/master/examples/sensors

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: hdfs
spec:
  template:
    serviceAccountName: operate-workflow-sa
  dependencies:
    - name: test-dep
      eventSourceName: hdfs
      eventName: example
  triggers:
    - template:
        name: hdfs-workflow-trigger
        k8s:
          operation: create
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: hello-world-
              spec:
                entrypoint: whalesay
                templates:
                  - name: whalesay
                    container:
                      args:
                        - "hello "
                      command:
                        - cowsay
                      image: "docker/whalesay:latest"
          parameters:
            - src:
                dependencyName: test-dep
                dataKey: body
              dest: spec.templates.0.container.args.1

4. Trigger

trigger는 event dependencies가 resolved되면 센서가 실행하는 resource/workload이다.
사실상 sensor 가 해당 작업을 수행하므로 예시가 같게 넣어져있습니다.

4.1.Trigger Types

AWS Lambda, Apache OpenWhisk, Argo Rollouts, Argo Workflows, Custom - Build Your Own, HTTP Requests - Serverless Workloads (OpenFaaS, Kubeless, KNative etc.), Kafka Messages, NATS Messages, Slack Notifications, Azure Event Hubs Messages, Create any Kubernetes Objects, Log (for debugging event bus messages)

4.2. Trigger Condition

https://argoproj.github.io/argo-events/sensors/trigger-conditions/

trigger 는 condition 에 따라 다르게 수행할 수 있습니다.
and 연산 : && , or 연산 : || 을 이용해, 복수개의 condition 을 이용할 수 있습니다.
트리거에 대해 여러 종속성이 정의된 경우 조건식이 true로 확인될 때까지 트리거가 실행되지 않습니다.
만약에 A,B 데이터를 가지고 있는데, A 라는 데이터가 잘 생성됐지만, B 데이터의 문제가 생겨 내일자 B 데이터만 받는 경우 날짜 싱크에 문제가 생길 수 있고, 원하는 방향이 아닐 수 있습니다. 이 때, Conditions Reset 을 이용하면 됩니다.
1. https://argoproj.github.io/argo-events/sensors/trigger-conditions/#conditions-reset

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: example
spec:
  dependencies:
    - name: dep01
      eventSourceName: webhook-a
      eventName: example01
    - name: dep02
      eventSourceName: webhook-a
      eventName: example02
   - name: dep03
     eventSourceName: webhook-b
     eventName: example03
  triggers:
    - template:
        conditions: "dep02"
        name: trigger01
        http:
          url: <http://abc.com/hello1>
          method: GET
    - template:
        conditions: "dep02 && dep03"
        name: trigger02
        http:
          url: <http://abc.com/hello2>
          method: GET
    - template:
        conditions: "(dep01 || dep02) && dep03"
        name: trigger03
        http:
          url: <http://abc.com/hello3>
          method: GET

4.3. Filter

https://argoproj.github.io/argo-events/sensors/filters/intro/

Filter는 유효성을 결정하기 위해 이벤트에 제약 조건을 적용하는 강력한 메커니즘을 제공합니다.
- Filter가 이벤트가 유효하다고 판단하면 센서에서 정의한 작업이 트리거됩니다.
- 반대로, 유효하지 않다고 판단하면 아무 작업도 트리거하지 않습니다.
유형

Argo Events는 5가지 유형의 필터를 제공합니다.

Expr필터 : https://argoproj.github.io/argo-events/sensors/filters/expr/
Data필터 : https://argoproj.github.io/argo-events/sensors/filters/data/
Script필터 : https://argoproj.github.io/argo-events/sensors/filters/script/
Context필터 : https://argoproj.github.io/argo-events/sensors/filters/ctx/
Time필터: https://argoproj.github.io/argo-events/sensors/filters/time/

논리연산자
- and, or 을 이용해, 필터 복수개를 조합해 이용할 수 있습니다.

이렇게 단순하게 Argo Event 의 개념과 아키텍처에 대해 알아보았는데요, 더 다양하고 자세한 내용이 공식문서

에 나와있으니, 더 궁금한 점이 있으신분들은 위에 링크를 참고해주세요!

개인적인 의견으로는 역시 공식문서가 세세하고 친절합니다. 생각하면 argo 제품군 이용하면서 따로 stackoverflow 나 다른 블로그 참고한 경우가 없는거같네요. 다만 아쉬운점, argo workflow 설명보다는 깃허브와 공식문서에 은근 혼재된 내용도 있고, 링크 매핑 오류도 조금 보이네요…

다음 글에서는 “Argo Event 직접 써보기!” 를 주제로 다시 찾아오겠습니다🙂

그럼 좋은 하루 되세요 🧚

저작자표시

'argo' 카테고리의 다른 글

use Airflow vs Argo workflow (with k8s?) (2)	2022.07.10

일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

killog

티스토리 뷰

Argo Event 의 개념과 아키텍처