쿠버네티스[EKS] Strimzi Kafka 구축 (Kafka-Exporter, Metrics, Kafka-UI)

Strimzi Kafka Operator를 활용하여 설치한 카프카에 대한 기록을 남겨보려고 한다. 

 

Strimzi Github을 참고하여  처음 설치할 때는 단발성의 (볼륨이 잡히지 않은) 카프카 클러스터를 생성하여 동작 과정을 확인하였고 바로 다음 볼륨(PVC)이 정의되고 메트릭 설정까지 정의된 예제 파일을 활용하여 클러스터를 설치하고 메트릭까지 확인하였다.

 

Kafka pod안에서 Kafka CLI 간단한 명령어를 통해 토픽에 메시지를 보내고 컨슈머, 컨슈머 그룹을 통해 메시지를 받는 과정을 통해 상태를 확인했고 Kafka-ui를 통해 좀 더 직관적으로 토픽과 브로커에 대해 확인했다.

 

마지막으로 Kafka-exporter를 활용해 Consumer Lag을 포함한 정보를 프로메테우스에서 수집하고 그라파나에 보여지기까지 과정을 겪었다. 프로메테우스는 기존에 설치되어있던 프로메테우스를 활용하였기에 필요한 부분만 커스텀하였다.

 

Kafka Lag 모니터링으로 burrow를 많이 사용한다고 하는데 Strimzi를 통해 metrics 예제 파일을 통해 설치하면 Kafka-Exporter Pod가 생성되기에 이를 그대로 활용했다. burrow는 슬라이딩 윈도우를 활용한다는데 Kafka-Exporter를 활용하면 어떻게 장애를 판단할 수 있는 Rule을 만들지 궁금하기도 했다. 근데 github에 보면 예제 파일 중 rule에 대한 것도 모두 있었다.

 

구축해놓고 보니 그냥 github에 있는 예제 파일들을 모두 Ctrl + C, Ctrl + V 한 거 밖에 없는 거 같다. 그래도 열심히 Ctrl + C, Ctrl + V 했던 과정을 기록하고 다음에 이를 활용할 때 참고해보면 좋을 거 같다.

 

helm repo에 strimzi 저장소를 등록한다. 

helm repo add strimzi https://strimzi.io/charts/
helm repo update

 

strimzi helm chart를 다운로드 후 압축 해제하고 설치한다.

# values.yaml 수정을 위해 설치
helm pull strimzi/strimzi-kafka-operator

#압축해제
tar -zxvf strimzi-kafka-operator-helm-3-chart-0.43.0.tgz

#디렉토리 이동
cd strimzi-kafka-operator

 

strimzi 버전은 공식 문서를 확인하자. 해당 버전에 따라 Kafka Client 버전이 바뀔 수 있다. 

필자는 24.10.30 기준 가장 최신버전인 0.43.0v을 다운로드하였다.

 

helm install kafka-operator strimzi/strimzi-kafka-operator --version 0.43.0 --namespace kafka

 

Strimzi Kafka를 검색하면 가장 많이 볼 수 있는 구성도이다.

• 공식 link: https://strimzi.io/

Strimzi - Apache Kafka on Kubernetes

Strimzi Kafka Architecture

• Cluster Operator : Deploys and manages Apache Kafka clusters, Kafka Connect, Kafka MirrorMaker, Kafka Bridge, Kafka Exporter, Cruise Control, and the Entity Operator
• Entity Operator : Comprises the Topic Operator and User Operator
• Topic Operator : Manages Kafka topics
• User Operator : Manages Kafka user

Cluster Operator

Cluster Operator 는 카프카/주키퍼 클러스터를 생성/배포 및 관리한다. Entity Operator는 Topic Operator와 User Operator를 관리하는데 필자처럼 설치한다면 Cluster Operator, Entity Operator를 deploy 조회 시 확인할 수 있다.

 

각 컴포넌트에 대해서는 공식 문서에서 확인할 수 있다.

https://strimzi.io/docs/operators/latest/overview#overview-components_str

Strimzi Overview (0.44.0)

자세한 컴포넌트에 역할은 잠시 뒤로 미뤄두고 Kafka Cluster & ZooKeeper Cluster를 배포하고 동작을 확인해보도록 하자.

 

strimzi-kafka github에 다양한 예제 파일들을 볼 수 있다. Kafka 클러스터를 배포하기 위해 Kafka 폴더로 들어가서 어떤 예제가 있는지 확인할 수 있다.

https://github.com/strimzi/strimzi-kafka-operator/tree/main/examples

strimzi-kafka-operator/examples at main · strimzi/strimzi-kafka-operator

Kafka Cluster yaml

볼륨지정유무 구분

• epehemeral : 볼륨을 지정하지 않음(파드의 기본 볼륨만 사용)
• persistent : 볼륨을 지정함(PV, PVC를 사용)

브로커 구성 구분

• single : 단일파드(1개) 로 지정
• (없음) : 다중파드(여러개) 로 지정

필자는 동작 과정을 확인하기 위해 kafka-epehemeral.yaml 파일을 선택하였고 해당 값을 복사하여 새 파일을 만들었다.

 

서론에서 말한 것 처럼 동작 과정을 확인하기에 가장 빠르게 확인할 수 있었다.

kubectl apply -f kafka-epehemeral.yaml

외부로 노출하기 위해 plain listener를 internal -> loadbalancer로 변경하였다.

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: kafka-cluster
  namespace: kafka
spec:
  kafka:
    version: 3.8.0
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: loadbalancer
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      default.replication.factor: 3
      min.insync.replicas: 2
      inter.broker.protocol.version: "3.8"
    storage:
      type: ephemeral
  zookeeper:
    replicas: 3
    storage:
      type: ephemeral
  entityOperator:
    topicOperator: {}
    userOperator: {}

이렇게되면 총 4개의 NLB가 생성된다.

NLB broker 주소

각각의 브로커 주소도 사용 가능하고 kafka-cluster-kafka-plain-bootstrap의 NLB 주소를 브로커 주소 대신 사용하면 모든 브로커 목록을 얻을 수 있다.

 

Metrics을 구축하기 위해서 다양한 방법이 있겠지만 Strimzi를 사용하니 여기서 권장하는 방법을 사용하여 구축하였다.

 

https://github.com/strimzi/strimzi-kafka-operator/blob/main/examples/metrics/kafka-metrics.yaml

strimzi-kafka-operator/examples/metrics/kafka-metrics.yaml at main · strimzi/strimzi-kafka-operator

이 파일을 그대로 적용하면 StorageClass 관련하여 찾지 못해 PVC 생성에 실패할 수 있다.

storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 200Gi
        deleteClaim: false
        class: gp2

따라서 storage에 class를 명시적으로 지정해주었다. kubectl describe, events 명령어를 활용하여 생성 실패 원인을 추적하여 해결하면 된다.

kafka-exporter

kafka-exporter pod가 정상적으로 실행된다면 설치가 잘 되었다. /metrics 에 노출된 메트릭을 수집하자.

 

PodMonitor를 활용하여 해당 kafka-exporter를 포함한 메트릭을 스크랩 할 수 있도록 생성이 필요하다.

https://github.com/strimzi/strimzi-kafka-operator/blob/main/examples/metrics/prometheus-install/strimzi-pod-monitor.yaml

strimzi-kafka-operator/examples/metrics/prometheus-install/strimzi-pod-monitor.yaml at main · strimzi/strimzi-kafka-operator

그대로 복사하여 apply 하였다.

 

바로 적용하면 PodMonitor가 정상적으로 동작하지 않는 것 처럼 보였다. 예제 파일에서 prometheus.yml의 특이점을 확인해보니 podMonitorSelector 옵션이 눈에 띄었다.

podMonitorSelector:
      matchLabels:
        app: strimzi

이 부분이 꼭 활성화되어 있어야 한다. 필자처럼 기존 프로메테우스를 활용하는 경우 이를 활성화 해주어야한다.

podMonitor Prometheus Target

프로메테우스에 접속해보니 PodMonitor가 Target으로 추가된 것을 확인할 수 있었다.

 

그라파나 대시보드 import Json 파일인데, 필자는 strimzi-kafka-exporter.json, strimzi-operators.json 두 가지 대시보드 JSON을 Import 하여 활용했다.

https://github.com/strimzi/strimzi-kafka-operator/tree/main/examples/metrics/grafana-dashboards

strimzi-kafka-operator/examples/metrics/grafana-dashboards at main · strimzi/strimzi-kafka-operator

다음 처럼 정상적으로 수집되는 것을 확인할 수 있었다.

strimzi-kafka-exporter.json

 

strimzi-kafka-exporter

strimzi-operators.json

strimzi-operators

카프카 Lag을 확인하기 위해 토픽에 메시지를 발행하고 수신하는 기능을 직접 만들기보다 Kafka CLI를 활용하여 간단히 테스트 할 수 있었다.

# 토픽 조회
/kafka-topics.sh \
--bootstrap-server [k8s-kafka-broker 주소]:9092 \
--list
# 수신 1
./kafka-console-consumer.sh \
--bootstrap-server [k8s-kafka-broker 주소]:9092 \
--topic topic-a \
--from-beginning
# 수신 2(group)
./kafka-console-consumer.sh \
--bootstrap-server [k8s-kafka-broker 주소]:9092 \
--topic topic-a \
--group group-a
# 발행
./kafka-console-producer.sh \
--broker-list [k8s-kafka-broker 주소]:9092 \
--topic topic-a

토픽을 조회, 메시지 발행 및 수신에 대한 CLI를 기록하였고 추가적인 기능은 필요할 때 따로 찾아서 활용하면 될 것 같다.

https://github.com/strimzi/strimzi-kafka-operator/blob/main/examples/topic/kafka-topic.yaml

strimzi-kafka-operator/examples/topic/kafka-topic.yaml at main · strimzi/strimzi-kafka-operator

 

추가로 좀 더 직관적인 콘솔 화면을 원한다면 오픈 소스로 제공하는 Apach Kafka UI 도구 활용해보자.

마찬가지로 Helm Charts을 활용하였다.

helm repo add kafka-ui https://provectus.github.io/kafka-ui-charts

위 strimzi를 설치할 때와 마찬가지로 pull 후 tgz를 푸는 과정이 필요하다.

 

이번엔 values.yaml에서 bootstrapServer를 수정해야하기 때문이다.

현재 브로커노드의 주소가 필요한데 모든 브로커노드를 불러올 수 있는 bootstrap 경로를 넣어주었다.

yamlApplicationConfig:
  kafka:
    clusters:
      - name: yaml
        bootstrapServers: kafka-cluster-kafka-plain-bootstrap.kafka.svc:9092
  auth:
    type: disabled
  management:
    health:
      ldap:
        enabled: false

 

또한 외부로 부터 접근 가능하도록 Ingress 설정을 True로 하여 구축을 진행하였다. AWS EKS 환경이기 때문에 ALB에 맞는 속성을 활용하였다.

# Ingress configuration
ingress:
  # Enable ingress resource
  enabled: true

  # Annotations for the Ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: alb group name
    alb.ingress.kubernetes.io/load-balancer-name: alb name
    alb.ingress.kubernetes.io/certificate-arn: "acm arn"
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/healthcheck-path: "/healthz"
  
  # ingressClassName for the Ingress
  ingressClassName: "alb"
 
  # The path for the Ingress
  path: "/"

  # The path type for the Ingress
  pathType: "Prefix"

  # The hostname for the Ingress
  host: "Domain"

 

이어서 설치를 진행하고 정상적인 Apach Kafka-UI를 확인해보자.

helm install kafka-ui kafka-ui/kafka-ui -f kafkaui-values.yml

Apach Kafka-UI

 

Kafka UI에서 브로커 정보나 토픽 관리, 메시지, 파티션 등의 정보를 관찰할 수 있었고 생각보다 꽤 유용한 정보를 포함하고 있었다. 

 

Strimzi Kafka를 구축하였고 Metrics 까지 확인할 수 있도록 구성하였다. 추가로 Helm Charts를 활용하여 Kafka-Ui를 간단히 붙였고 Kafka-CLI를 활용하여 테스트하는 과정을 가졌다.

 

Exporter의 개념과 이를 프로메테우스가 Scrape 할 수 있도록 설정하면 금방 구축할 수 있을 것이라 생각했지만 생각보다 구축 시간이 걸렸다. 프로메테우스를 기존에 설치한 operator를 활용했기에 예제를 꼼꼼히 보는 시간과 불필요한 것들을 덜어내는데 필요한 시간이 들었던 것 같다.

Apach Kafka 환경을 구축하면서 이를 어떻게 운영하고 이슈를 트래킹 하는지가 중요할 것 같고 꽤 재밌는 경험이 될 것 같다고 느꼈다. 필요한 지표가 무엇인지, Lag를 어떻게 모니터링하고 해소할 수 있을지 등 Kafka에 대해 학습할 수록 다양한 운영 경험을 쌓아보고 싶어졌다. 하지만 반대로 필요하지 못한 환경에서 오버 엔지니어링을 경험할 수 있을 것 같다고 생각했다. https://aws.amazon.com/ko/msk/pricing/

생각보다 클러스터로 구성된 경우 요금이 비싸게 다가왔고 적절한 환경에서 설치하거나 또는 운영 인력에 따라 매니지 서비스(MSK & Confluent)를 활용하는 방안도 고려해볼만 한 거 같다.