Kubernetes 환경에서 Fluent Bit의 신뢰성 (tail input, s3 output)

 

Fluent Bit를 테스트하고 로그 수집을 할 때 진작 이 수준으로 깊게 알았어야 했는데... 오늘에야 알게 된 내용 정리

 

1. Fluent Bit가 롤링 업데이트 되어도 Input 과정에서 로그 손실이 없을까? 
    - Tail Input을 사용할 경우

• fluent bit을 배포하기 위해 사용한 Daemonset은 기본적으로 노드별로 pod를 rolling update
  ** 현재 daemonset은 먼저 기존 pod를 삭제하고 새 pod를 생성함에 유의 **
  
  
• fluent-bit-configmap.yaml

[INPUT]
    Name              tail
    Tag               test.*
    Path              /var/log/containers/test*.log
    DB                /var/log/flb_test.db

fluent bit는 input 플러그인에서 DB를 사용해 파일을 어디까지 읽어왔는지를 기록하는데, 

• fluent-bit-daemonset.yaml

  volumeMounts:
  - name: varlog
    mountPath: /var/log
volumes:
- name: varlog
  hostPath:
    path: /var/log

fluent-bit와 워커노드의 /var/log 디렉토리가 마운트되기 때문에 DB 파일이 워커노드에 남아있게 됨
→ 새 fluent-bit 파드가 DB를 이어받아 데이터 손실 없이 로그를 수집할 수 있다.

 

2. Fluent Bit S3 Output 플러그인 사용 시, 롤링 업데이트 혹은 파드가 갑자기 종료되는 상황에서 데이터 유실이 없을까?

[OUTPUT]
    Name                         s3
    Match                        *
    bucket                       my-bucket
    region                       us-west-2
    total_file_size              250M
    store_dir			 /var/log/s3/temp/
    s3_key_format                /$TAG[2]/$TAG[0]/%Y/%m/%d/%H/%M/%S/$UUID.gz
    s3_key_format_tag_delimiters .-

store_dir 옵션을 사용하면 fluent bit가 s3에 데이터를 업로드 하기 전에 데이터를 임시로 해당 디렉토리에 저장한다. 

fluent bit가 갑자기 멈춘다면 종료 전에 store_dir의 모든 데이터를 전송하고 업로드를 마치려 한다.
전송하지 못한 데이터가 있다면, fluent-bit가 재시작할 때 store_dir에 남아있는 데이터가 있는지 찾아보고 다시 전송을 시작하려 한다.

-> store_dir 옵션이 없어도 fluent bit는 종료 시 모든 데이터를 s3에 전송하려 시도하지만 그러지 못할 수도 있다.
그러니 store_dir 옵션을 사용하도록 하자!

 

3. Kubernetes 환경에서 Fluent Bit pod 안에 컨테이너가 2개라면, 롤링 업데이트가 안 된다? 

ArgoCD에서 fluent bit 설정 소스코드를 수정 후 sync를 했더니 원래 rolling update 시에는 각 노드마다 하나씩 pod가 생성되고 종료되는데, 컨테이너가 2개인 fluent bit pod를 배포하려니 갑자기 모든 노드의 pod가 한 번에 없어지는 것처럼 보여(실제로는 rolling update일지라도) 엄청 놀랐다. 

그런데 알게 된 흥미로운 사실은, Daemonset을 사용해 fluent bit 같은 로그 수집 프로그램을 rolling update로 배포할 때는 원래
- 먼저 지우고 
- 그 다음 새로 생성하는 rolling update였다. 
> 관련 깃허브 이슈

Kubernetes 1.21 알파 버전부터는 add first, then delete 방식으로 daemonset도 rolling update가 이뤄진다고 한다... 고 깃헙 이슈에 써 있는데, 1.25 버전의 공식 문서에는 아직

With RollingUpdate update strategy, after you update a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods will be created automatically

이렇게 써 있다. 어떻게 되는 건지 궁금하군...