쿠버네티스 doc을 살펴보면 여러가지 로깅 아키텍쳐가 존재한다.
- 모든 노드에서 실행되는 노드-레벨 로깅 에이전트를 사용한다.
- 애플리케이션 파드에 로깅을 위한 전용 사이드카 컨테이너를 포함한다.
- 애플리케이션 내에서 로그를 백엔드로 직접 푸시한다.
해당 게시글은 방법 1을 활용한 내용이다.
https://kubernetes.io/ko/docs/concepts/cluster-administration/logging/
Elastic 8.x버전부터 보안이 기본적으로 활성화되어 있으며, 클러스터 간 통신 및 사용자 요청에 TLS가 기본으로 적용된다. 사용자 인증도 기본 설정이 필요하여 설치가 간편한 7.x 버전에 대해 기록한다.
1. helm 설치
wget https://get.helm.sh/helm-v3.9.4-linux-amd64.tar.gz
tar xvfz helm-v3.9.4-linux-amd64.tar.gz
mv linux-amd64/helm /usr/bin/
helm version
2. elastic, kibana 패키지로 만들어진 helm repo를 추가한다.
helm repo add elastic https://helm.elastic.co
helm repo update
3. elastic 7.17.3의 values.yaml을 다운로드한다. 이유는 위 설명과 같이 8.x 버전부터의 변화로 인해 간편했기 때문이다.
helm search repo elastic
helm search repo elastic/elasticsearch --versions
helm show values elastic/elasticsearch --version 7.17.3 > elastic-value.yaml
4. 환경에 맞도록 필요한 값을 찾아 수정하자. 필자의 경우 replicas, minimumMasterNodes, resources를 제거하였고 추후 디스크로 인해 애플리케이션에 문제가 가지 않도록 노드를 분리하기 위해 nodeSelector를 수정하였다.
마지막으로 EKS 환경에서 default로 사용 중인 SC인 gp2를 volumeClaimTemplate에 넣어주었다.
volumeClaimTemplate:
storageClassName: gp2
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 150Gi
nodeSelector:
nodetype: monitor
5. Elastic 설치
설치할 때 show로 빼놓은 values.yaml version 과 맞게 옵션으로 넣어주자. 필자는 이 부분을 빼먹어서 꽤 고생했다.
helm install elastic elastic/elasticsearch -f elastic-value.yaml -n monitoring --version 7.17.3
6. Kibana도 동일하게 설치하면 된다. elasticsearch와 동일한 버전을 받도록 하자.
helm show values elastic/kibana --version 7.17.3 > kibana-value.yaml
7. Kibana를 외부에 노출하기 위해 svc type을 변경하거나 ingress를 환경에 맞게 붙이도록 하자. 리소스 또한 마찬가지이다.
service:
type: LoadBalancer
8. Kibana 설치
helm install kibana elastic/kibana -f kibana-value.yaml -n monitoring --version 7.17.3
9. 이제 로그를 보낼 Fluent-bit를 설치하도록 하자.
helm repo add fluent https://fluent.github.io/helm-charts
helm show values fluent/fluent-bit > fluent-bit-values.yaml
10. Daemont Set으로 배포가 될 것이다. 필요한 log 경로를 INPUT에서 제어해주자.
multiline parser를 활용해 멀티라인을 파싱할 수 있는데 이 부분은 따로 다뤄보도록 하자.
inputs: |
[INPUT]
Name tail
Path /var/log/containers/수집로그*.log
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/*argo*
multiline.parser docker, cri
Tag kube.*
read_from_head true
Buffer_Max_Size 5M
Buffer_Chunk_size 5M
Mem_Buf_Limit 100MB
Skip_Long_Lines On
Refresh_Interval 10
필자의 경우는 커스텀한 로그가 다양한 환경이기에 FluentD를 구축하여 애플리케이션에서 로그를 발송하는 아키텍쳐로 로깅 아키텍쳐를 추가로 구축하였다.
https://sh970901.tistory.com/148
만약 FluentD를 helm chart로 설치하고 로깅을 직접 애플리케이션에서 보낼 경우에는 values 값을 수정이 몇가지 필요한데, 기본적인 것만 기록하겠다.
kind: "Deployment"
replicaCount: 3 (상황에 맞게)
service:
enabled: true
type: "ClusterIP"
annotations: {}
# loadBalancerIP:
# externalTrafficPolicy: Local
ports:
- name: "forwarder"
protocol: TCP
port: 24224
containerPort: 24224
01_sources.conf: |-
<source>
@type forward
@label @OUTPUT
port 24224
bind 0.0.0.0
</source>
04_outputs.conf: |-
<label @OUTPUT>
<match **>
@type elasticsearch
host "elasticsearch-master"
port 9200
path ""
verify_es_version_at_startup false
logstash_format true
logstash_prefix ${tag}
logstash_dateformat %Y%m%d
include_timestamp true
include_tag_key true
time_key timestamp
reload_connections true
reconnect_on_error true
reload_on_failure true
</match>
</label>
만약 FluentD나 Fluent-bit에서 자동으로 날짜 별 index를 생성하였는데, Elastic에서 롤 오버 설정이 필요할 경우 Alias에 커스텀이 필요할 것이다. 이 부분은 따로 포스팅하도록 하겠다. 만약 로깅을 구축하는 경우 Rollover가 필요없다면 설정하지 않는 것이 가장 편리하겠지만 샤드를 나누고 Rollover가 필요한 경우는 인덱스 생성의 주체를 Fluentd가 아닌 Elastic에서 인덱스 생성을 관리하도록 하는 것이 편리했던 것 같다. 관련해서는 따로 포스팅하도록 하겠다.
https://sh970901.tistory.com/159
'IT' 카테고리의 다른 글
쿠버네티스[EKS] argo rollout을 이용한 Blue/Green, Canary 배포 (3) | 2024.10.09 |
---|---|
쿠버네티스[EKS] argocd 설치 및 AWS ALB 외부 노출, Slack 설정 (0) | 2024.10.09 |
쿠버네티스[EKS] 프로메테우스, 그라파나 helm 설치 (0) | 2024.10.08 |
Helm, Helm chart (0) | 2024.08.26 |
Pinpoint-docker 설치하고 적용하기 [ agent 분리 ] (0) | 2024.08.25 |