| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- 클라우드 엔지니어
- 국비지원교육
- aws outposts
- 외부 모듈
- Jenkins
- observability
- VPA
- POD
- EKS
- AWS
- aews
- 합격 후기
- aews ci/cd
- outposts local cluster
- 단기 합격
- 도커
- karpenter
- kubernetes
- Python
- 클라우드 국비지원교육 후기
- Terraform
- 클라우드 국비지원교육
- storageclass
- k8s
- prometheus
- grafana
- eks endpoint access
- keda
- docker
- aews vault
- Today
- Total
모험가
AEWS 4주차 - Observability(Monitoring, EKS 컨트롤 플레인, 파드 로깅) 본문
| 본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다. 모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다! |
Observability와 Monitoring
| 구분 | 옵저빌리티 | 모니터링 |
| 정의 | 시스템의 내부 상태와 동작을 관찰하고 이해하는 것 | 시스템의 성능, 가용성, 상태 등을 지속적으로 관찰하고 데이터를 수집하는 것 |
| 목적 | 시스템 문제 해결, 성능 향상, 복잡성 관리 | 시스템 상태 파악, 이상 징후 감지 |
| 방법 | 로그 분석, 트레이싱, 디버깅 등 | 지표 수집, 알람 설정, 대시보드 구축 등 |
| 활용 | 개발자, 운영팀 | 운영팀, 관리자 |
옵저빌리티와 모니터링은 차이가 있지만 정말 연관이 있는 관계입니다.
관련해서 가시다님의 글이 너무 정리가 잘 되어있어서 그대로 첨부하겠습니다.
|
|
|
EKS 컨트롤 플레인 로깅 활성화

EKS를 아무 설정없이 설치할 경우 Control Plane의 로깅은 비활성화입니다.

컨트롤 플레인 로그를 모두 활성화합니다.
# 모든 로깅 활성화
aws eks update-cluster-config --region ap-northeast-2 --name $CLUSTER_NAME \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

# 신규 로그를 바로 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --follow

# 로그 스트림이름
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-apiserver --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-apiserver-audit --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-scheduler --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix authenticator --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-controller-manager --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix cloud-controller-manager --follow
해당 로그들은 CLI에서도 아래와 같은 명령어로 검색이 가능하지만 콘솔에서도 가시성있게 확인이 가능합니다.

추가로 Log Insight를 통해 쿼리를 날려서 얻고자 하는 로그를 찾아서 문제를 해결해 나갈 수 있습니다.
* 즉 적절히 섞어서 이용하면 운영자 입장에서는 매우 큰 이점이 됩니다.

실제 쿼리 예시
fields @timestamp, @message
| filter @logStream = "<로그 스트림 이름>"
| sort @timestamp desc

이렇게 Cloudwatch Log Group에 Control Plane의 해당 로그들을 쌓고 있었습니다.
하지만 현재 이렇게 활성화된 로그 그룹은 데이터 만기 일정도 없고 계속해서 쌓입니다.
이러면 비용이 증가하기 때문에 삭제까지 진행하겠습니다.
로깅 끄기
# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region ap-northeast-2 --disable-types all --approve
# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster
컨테이너 로깅
사전 구성
1. Load Balance Controller 설치
2. Routing 53 도메인 등록, ACM 등록
3. externalDNS 설치
4. gp3 Storageclass 등록
# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
# 변수 등록
CERT_ARN=<aws CERT ARN>
MyDomain=<도메인명>
# 파라미터 파일 생성
cat <<EOT > nginx-values.yaml
service:
type: NodePort
networkPolicy:
enabled: false
resourcesPreset: "nano"
ingress:
enabled: true
ingressClassName: alb
hostname: nginx.$MyDomain
pathType: Prefix
path: /
annotations:
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/ssl-redirect: "443"
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/target-type: ip
EOT
cat nginx-values.yaml
# 배포
helm install nginx bitnami/nginx --version 19.0.0 -f nginx-values.yaml
# 확인
kubectl get ingress,deploy,svc,ep nginx

# 접속 로그 확인
kubectl stern deploy/nginx
혹은
kubectl logs deploy/nginx -f

참고 사항
컨테이너 로그 환경의 로그는 표준 출력 stdout과 표준 에러 stderr로 보내는 것을 권고 - 링크
Logs and metrics
Learn how to write to, view, and configure a container's logs
docs.docker.com
실제 로그 파일이 컨테이너 안의 어느 경로에 쌓이는지 확인합니다.
# 컨테이너 로그 파일 위치 확인
kubectl exec -it deploy/nginx -- ls -l /opt/bitnami/nginx/logs/
total 0
lrwxrwxrwx 1 root root 11 Feb 18 13:35 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Feb 18 13:35 error.log -> /dev/stderr

* 종료된 파드는 kubectl logs로 확인이 불가합니다.
-> 로그 전용 컨테이너를 생성하여 pv를 붙인다거나 다른 방법을 찾아볼 수 있을것 같습니다.
kubelet 기본 설정은 로그 파일의 최대 크기가 10Mi로 10Mi를 초과하는 로그는 전체 로그 조회가 불가능함 (파일 갯수 5개)
--> 오래된것부터 삭제됩니다
--> 설정 파일을 변경함으로써 용량을 변경할 수 있습니다.
# AL2 경우
cat /etc/kubernetes/kubelet-config.yaml
...
containerLogMaxSize: 10Mi
Amazon Linux 2023의 경우는 AL2의 위치와 다릅니다.
/etc/kubernetes/kubelet/config.json.d/00-nodeadm.conf
으로 파악되는데 설정을 나중에 한번 변경해보겠습니다.
AL2023에서는 설정 방법 변경 - Docs
- [추천 정보] EKS AMI에 user data 설정하는 방법
- https://www.youtube.com/watch?v=5Ah7g7u5UzQ
'쿠버네티스 > AEWS' 카테고리의 다른 글
| AEWS 4주차 - Observability(Prometheus & Grafana) (0) | 2025.02.28 |
|---|---|
| AEWS 4주차 - Observability(Cloudwatch Observability, Metrics-server & kwatch) (0) | 2025.02.28 |
| AEWS 3주차 - Storage(EFS, Spot Node Group) (1) | 2025.02.21 |
| AEWS 3주차 - Storage(PV, PVC, EBS) (0) | 2025.02.21 |
| AEWS 2주차 - Networking(네트워크 분석 툴 Kubeskoop 설치) (0) | 2025.02.13 |