Knative의 Eventing Prometheus 고쳐서 동작하게 만들었던 히스토리

 

Knative Eventing을 활용해서 CloudEvent 기반 event-driven 구조를 도입해 서비스 간 결합도를 낮추는 작업을 하고 있던 중

knative 진영에서 개발 중단된, prometheus query를 주기적으로 호출해서 CloudEvent를 생성하는 프로덕트를 찾았다.

조금만 고쳐쓰면 사용할 수 있을 것 같아서 수정했고, 지금은 잘 사용 중이다.

 

 

무얼 고쳐서 어떻게 동작하도록 만들었고, 쓰려면 어떻게 해야 하는지를 기록으로 남기기 위한 포스트.

 

원본

https://github.com/knative-extensions/eventing-prometheus

GitHub - knative-extensions/eventing-prometheus: Prometheus integration with Knative Eventing.

 

 

수정한 repo

https://github.com/inspirit941/eventing-prometheus

GitHub - inspirit941/eventing-prometheus: Prometheus integration with Knative Eventing.

 

---

 

 

 

이 프로젝트는 미완성 상태로, 핵심 로직이 빠진 채 Deprecated 되어 있었다.

• Knative EventSource는 이벤트를 어디로 전달할 것인지를 sink에 설정할 수 있다.
  Addressable interface이므로 k8s resource (service, deployment, knative service 등..) 뿐만 아니라
  http endpoint만 명시해도 된다.
• 그런데 이 프로덕트는 sink로 cloudevent 전달하는 로직이 빠져 있다.
  이러면 동작을 안하지..

그리고 eventing prometheus를 써서 monitoring 시스템을 구현하려 한 거 같은데..

prometheus 자체가 Metric 수집 -> storage에 전달하는 구조가 아주 잘 만들어져 있다.

굳이 monitoring stack을 위해 eventsource를 만들 필요는 없었다. 그래서 deprecated된 듯.

 

단, sink를 쓰면 elasticsearch와 같은 storage뿐만 아니라

다른 외부 endpoint에도 쉽게 metric을 http로 전달할 수 있다는 점에서는 활용가치가 있었다.

 

보통은 grafana로 시각화해서 보기 때문에 일반적인 usecase는 아니지만..

 

 

https://github.com/inspirit941/eventing-prometheus/commit/d8c031a8b0da6bfa0bdd69a631efb9b773a2b365

fix: cloudEvent를 sink로 전달하는 로직 추가, sink 환경변수 이름 다른 부분 수정 · inspirit941/eventing-pro

 

미완성 로직 수정해서 동작하도록 만들어주었다.

 

 

go 버전이 1.15로 너무 낮기도 하고,

cloudevent go SDK에 memory leak 버그가 있는 버전을 쓰고 있었다.

https://github.com/inspirit941/eventing-prometheus/commit/45e2c816772800021dacc42099bbab478491bffe

fix: 모듈명 변경, go 버전업. · inspirit941/eventing-prometheus@45e2c81

 

go 버전과 cloudevent go SDK 버전을 올려준다.

 

cf. cloudevent go SDK의 retry 로직에서 발생하는 memory Leak 

https://github.com/cloudevents/sdk-go/pull/916

fix: Close response body between retries by taehwoi · Pull Request #916 · cloudevents/sdk-go

-> response Body를 close하지 않고 retry해서 발생한다는 듯.

 

 

 

https://github.com/inspirit941/eventing-prometheus/commit/8e0a4c1d1cc4f246c1e6fcad3432307e7a818c1e

fix: vendor & third party update · inspirit941/eventing-prometheus@8e0a4c1

이러면 go vendor에도 패키지 버전업을 해줘야 하므로, go mod vendor 명령어로 전부 업데이트해준다.

 

 

 

https://github.com/inspirit941/eventing-prometheus/commit/e573630b5f258e298ed63579bec4df7521a539fb

fix: 패키지명 변경사항 반영 · inspirit941/eventing-prometheus@e573630

이걸 동작하게 만드려면 knative.dev/eventing-prometheus 패키지도 바꿔줘야 한다.

github.com/inspirit941/eventing-prometheus로 전부 바꿔주었다.

 

 

 

https://github.com/inspirit941/eventing-prometheus/commit/3ab92f2ebfb5ceb62409d6d35164300e653e15a1

feat: 변경사항 반영해서 client generate 수행 · inspirit941/eventing-prometheus@3ab92f2

패키지명이 바뀌었으니, kubernetes go client도 다시 만들어줘야 한다.

• knative 진영에서는 client generation을 쉽게 할 수 있도록 codegen 실행해주는 shell script를 제공해주고 있다. 실행한다.
  https://github.com/inspirit941/eventing-prometheus/blob/main/hack/update-codegen.sh

 

 

로직이 바뀌었으니, Custom Resource도 다시 만들어줘야 한다.

일반적으로 custom resource definition을 만들어주는 도구는 kubeBuilder인데,

knative 진영은 꽤 오랫동안 kubebuilder를 안 쓰고 CRD를 만들고 있었다.

 

 

https://github.com/knative/serving/pull/11244

Add complete schemas to all CRDs by markusthoemmes · Pull Request #11244 · knative/serving

https://github.com/knative/pkg/pull/2431

Make URL compatible with controller-gen by ChunyiLyu · Pull Request #2431 · knative/pkg

그마저도 kubebuilder보다 한 단계 low level인 controller-gen 형태로 쓰는 걸 2021년에야 조금씩 도입했는데

내 로컬에서는 동작을 안 했다.

 

그래서 controller-gen 공부해서, 동작하는 코드를 만들었다.

 

#!/usr/bin/env bash

controller-gen object:headerFile=./hack/boilerplate.go.txt paths=./pkg/apis/... +crd:crdVersions=v1 +output:crd:artifacts:config=manifests

 

이걸 실행하면 manifests 디렉토리에 CRD yaml 파일이 만들어진다.

 

https://github.com/inspirit941/eventing-prometheus/commit/f830c5565b3196174e524a489596391d9172ff20

feat: controller-gen 추가, CRD yaml · inspirit941/eventing-prometheus@f830c55

 

 

---

 

배포 방법?

 

./hack/release.sh를 실행하면 된다. 

 

ko build로 go file을 docker image로 변환하고

변환된 docker image를 registry에 push한 뒤

registry image를 controller / webhook / adapter 의 image path에 넣어준 yaml 파일을 생성해준다.

 

 

ko build 세팅하는 것까지는 이 글의 주제에 벗어나는 것 같아서, 여기까지만 쓰고 마무리.