EKS Fargate Logging with Fluent Bit

 

Kubernetes의 CoreDNS와 Logging Architecture을 알아봤으니 실제 Application Pod에서 발생하는 로그를 EKS Cluster 외부로 빼보자.

먼저, Kubernetes 클러스터 내에서 핵심 역할을 수행하는 CoreDNS와 로깅 기능의 핵심인 Fluent Bit에 대해 간략히 살펴본다.

그리고 EKS Fargate 환경에서 로그가 어떻게 처리되는지, 그 과정에서 사용되는 ConfigMap의 역할과 설정 방법에 대해 알아본다.

마지막으로, 로깅을 활성화하기 위한 ConfigMap을 생성하는 방법과 주의할 점들을 알아본다.

이를 통해 AWS의 관리하는 환경에서 안정적이고 효율적인 로깅을 설정하는 방법을 살펴보도록 한다.

 

 

EKS Fargate CoreDNS 와 Logging Architecture

 

EKS Fargate Logging Flow

 

 

Application 에서 발생한 로그가 Fluent Bit SideCar 를 거쳐 외부로 나오는 과정은 다음과 같다.

1. Application 로그 발생
2. 사용자가 명시적으로 사이드카를 실행하진 않지만 AWS가 대신 실행해 주는 Fluent Bit 기반 로그 라우터를 통해 ENI를 거쳐 로그 전송
3. Application을 구동시키는 NameSpace에 이름의 ConfigMap 이 있는지 자동으로 감지 후 모두 정상적으로 있다면 해당 Pod 에 LoggingEnabled 라는 주석 생성

AWS Console에서 Application Pod를 보면 Logging 에 LoggingEnabled 로 Logging이 활성화된 것을 볼 수 있다.

해당 Pod 를 describe 해보면 동일하게 Annotations에 Logging이 활성화된 것을 확인할 수 있다.

 

Logging Flow 3번 과 같은 조건을 충족하지 못하면 Logging 기능을 켤 수 없다.

하지만 Logging을 활성화하지 않는다고 Application에 영향을 주는 것은 아니기 때문에 Pod는 정상적으로 뜬다. Logging이 활성화되지 않은 Pod를 describe 해보면 아래와 같은 message를 볼 수 있다.

 

[...]
Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB
                      Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND
                      kubernetes.io/psp: eks.privileged
[...]
Events:
  Type     Reason           Age        From                Message
  ----     ------           ----       ----                -------
  Warning  LoggingDisabled  <unknown>  fargate-scheduler   Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found

 

 

fargate-scheduler 가 Logging을 활성화할 수 있는 configmap 을 찾지 못했기 때문이다.

따라서, Logging 을 활성화하기 위해선 해당 configmap 을 생성해줘야 한다.

Logging 을 활성화하기 위한 ConfigMap을 알아본다.

---

ConfigMap

 

로그 라우터를 ConfigMap 과 SiderCar 중 어느 패턴으로 가져갈 지에 대한 고민이 있었다.

이전에 Datadog Agent 버전 관리에 대한 이슈가 있었기에 우리가 철저하게 관리할 수 있는 SiderCar 를 생각했지만

ConfigMap 은 AWS 가 관리하는 Fluent Bit를 사용하고 해당 Fargate를 사용하더라도 AWS 공동 책임 모델에서 제외되지 않는다는 답변을 받아 ConfigMap 을 사용하는 쪽으로 결정하게 됐다.

Fluent Bit에 대해서 버전 확인은 할 수 없지만 이미지를 dockerhub, github 등에서 관리를 하고 있다.

 

Docker

 

ConfigMap 은 기밀이 아닌 데이터를 키-값 형태로 저장하는 데 사용되는 API 개체이다.

암호화를 제공하지 않기 때문에 주의해야 하고 필요시 3rd Party Secret ConfigMap 사용해야 한다고 한다.

Application 코드와 별도로 구성 데이터를 설정하는 용도 (AWS Parameter Store 하위 호환 느낌)

모든 값들을 AWS Parameter Store에 등록하기보다 운영 영향도가 낮고 개발 쪽에서 관리 가능한 값들은 따로 빼도 나쁘지 않을 것 같다는 생각이 들었다.

주의 사항으로는 아래와 같다.

1 MiB를 초과할 순 없다.

Amazon EKS Fargate 로깅은 ConfigMaps의 동적 구성을 지원하지 않고 ConfigMaps의 모든 변경 사항은 새 Pods에만 적용된다.

기존 Pods에는 변경 사항이 적용되지 않는다.

---

Fluent Bit 로그 라우터용 ConfigMap

Fluent Bit를 사용하기 전에 각 Application 특성에 맞게 구성 파일을 수정해야 한다.

Service, Input, Filter, Output. conf 파일을 사용하여 Application 특성에 맞게 커스텀할 수 있다.

Service.conf 에 대한 정보는 없고 Client는 filter.conf, output.conf 만 관리하면 된다.

parser.conf 는 Optional이라고 한다.

 

input.conf

• 로그를 수집하기 위한 입력 설정 정의
• input.conf 는 사용자가 수정할 수 없지만 해당 conf 파일로 메모리 버퍼 한도, 로그에 적용된 태그 등의 정보를 알 수 있다.

[INPUT]
    Name tail
    Buffer_Max_Size 66KB
    DB /var/log/flb_kube.db
    Mem_Buf_Limit 45MB
    Path /var/log/containers/*.log
    Read_From_Head On
    Refresh_Interval 10
    Rotate_Wait 30
    Skip_Long_Lines On
    Tag kube.*

 

ConfigMap_For_FluentBit.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: wow2
data:
  flb_log_cw: "true"

# Fluent Bit 프로세스 로그를 처리하기 위한 필터를 정의
  filters.conf: |
    [FILTER]
        Name parser
        Match *
        Key_name log
        Parser crio
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        Buffer_Size 0
        Kube_Meta_Cache_TTL 300s

# 어디로 출력할까? (Cloudwatch, OpenSearch, Firehose 등)
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match   kube.*
        region ap-northeast-2
        log_group_name foofoo
        log_stream_prefix from-fluent-bit-
        log_retention_days 60
        auto_create_group true

# 로그 파싱을 위한 구문 분석기
  parsers.conf: |
    [PARSER]
        Name crio
        Format Regex
        Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
        Time_Key    time
        Time_Format %Y-%m-%dT%H:%M:%S.%L%z

이렇게 ConfigMap을 먼저 구성한 후 Application Pod를 apply 하면 처음에 나온 것처럼 Logging 이 활성화된 것을 볼 수 있다.

 

 

aws-observability 전용 네임스페이스라는 말이 있지만 Namespace를 구분해서 ConfigMap 생성 가능하다.

Fargate 별로 로그 포맷을 다르게 가져갈 수 있다.

이런 간단한 문제는 대부분 Docs에 나와있지만..  아직도 설렁설렁 읽는 경향이 있다. 꼼꼼하게 읽자