[4주차] AEWS Amazon EKS 워크숍 스터디 (23.05.14)

AEWS(AWS EKS WOrkshop Study) #4

들어가며

이번 주차에는 EKS Observability에 대해 학습했다. 지난 PKOS 스터디에서 kOps 클러스터에서 Prometheus + Grafana 기반의 로깅 모니터링에 대해서 학습했었고, 이번 스터디도 EKS 클러스터 환경에서 비슷한 내용을 배웠고, AWSManagement Console의 사용법에 대해서도 배울 수 있었다.

 

세미나에서 배운 내용은 주로 애플리케이션의 실행 상태나 오류, 경고등을 모니터링할 수 있는 Log trace 관련 내용이었다. 요즘은 더 나아가서 코드의 실행경로와 이벤트 흐름을 추적하여 성능 분석 및 개선을 할 수 있는 Application trace도 많이 사용한다고 한다.

 

---

EKS 콘솔

AWS Management Console을 사용하여 Kubernetes API를 통해 클러스터에 배포된 리소스 및 정보를 확인할 수 있다.

 

AWS Management Console과 연동되어 정보들을 확인할 수 있도록 클러스터에는 아래와 같은 eks 관련 ClusterRole들이 생성되어 있다.

kubectl get ClusterRole | grep eks

 

 

EKS > 클러스터 > myeks(스터디를 통해 생성한 클러스터) >리소스 탭을 보면 워크로드, 클러스터 등의 전체 리소스를 확인할 수 있다.

 

 

리소스 유형에서 워크로드를 선택한 다음 Pod 리스트에서 특정 파드를 클릭하면 다음과 같이 kubectl에서 확인할 수 있었던 Pod들의 정보를 간편하게 확인할 수 있어서 편했다.

 

 

Pod에서 실행되고 있는 컨테이너들의 정보와 Pod에서 발생하는 이벤트 로그까지 디테일하게 확인할 수 있었는 간편성을 제공한다.

 

---

 

EKS에서 로깅하기

실습 1 -  Cloud Watch를 이용한 로깅

클라우드 와치를 통해서 EKS 클러스터 로그를 확인할 수 있었다. 이를 활성화하려면 다음과 같이 eks 클러스터의 로깅을 활성화해주는 과정이 필요하다.

 

# 모든 로깅 활성화
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

# 로그 그룹 확인
aws logs describe-log-groups | jq

 

/aws/eks/myeks/cluster라는 로그 그룹이 생기고, 로그 스트림 안에 5가지의 로그들이 생성된다. 잠시 기다리면 로그 그룹이 생성된다.

 

 

로그는 위에서 생성한 로그 그룹 경로에 차곡차곡 쌓이게 된다. 다음의 명령어로 로그 그룹에 쌓인 로그 정보들을 확인할 수 있다.

 

# 로그 tail 확인 : aws logs tail help
aws logs tail /aws/eks/$CLUSTER_NAME/cluster | more

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

# 필터 패턴
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --filter-pattern <필터 패턴>

 

 

# 로그 스트림이름
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-controller-manager --follow

 

 

aws logs tail /aws/eks/$CLUSTER_NAME/cluster --filter-pattern "error” 과 같이 특정 필터패턴에 대한 정보도 확인할 수 있다.

이렇게 수집한 로그는 클라우드 와치 > 로그 그룹에서 확인할 수 있다.

 

콘솔에서 제공하는Logs Insights라는 툴을 이용해서 쿼리를 이용하면 원하는 정보를 확인할 수 있다. 만약 실무에서 API 서버나 스케줄러의 로그 정보를 확인하고 싶을 때 간편하게 사용할 수 있다.

 

아래의 그림은 kube-apiserver-audit 로그에서userAgent를 정렬하여 4가지의 필드(userAgent, requestURI, timestamp, message)의 정보를 검색하는 쿼리를 실행한 결과다.

 

 

이러한 형태로 컨트롤 플래인의 로그나 follow node의 etcd의 데이터 사이즈 같은 것들을 간편하게 확인할 수 있다.

 

활성화된 로깅을 중지하려면 다음과 같이 로깅 기능을 끄고 이전에 수집한 정보인 로드 그룹을 삭제하면 된다.

 

# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region $AWS_DEFAULT_REGION --disable-types all --approve

# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster

 

---

 

실습 2 - Nginx 웹서버 컨테이너(Pod) 로깅

Nginx 웹서버를 실행시키고 컨테이너 내부의 로그를 확인하고, 로그를 남기는 표준 로그 출력 권고사항에 대해 이해했다.

 

실습을 위해 다음과 같이 Nginx 웹서버를 헬름차트로 배포했다.

 

# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami

# 사용 리전의 인증서 ARN(리소스 이름) 확인
CERT_ARN=$(aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text)
echo $CERT_ARN

# 도메인 확인 (필자의 경우: devlos.click)
echo $MyDomain

# 파라미터 파일 생성
cat <<EOT > nginx-values.yaml
service:
    type: NodePort

ingress:
  enabled: true
  ingressClassName: alb
  hostname: nginx.$MyDomain
  path: /*
  annotations: 
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat nginx-values.yaml | yh

 

 

 

LB 버전업이 되면서 annotation에서 지정한 LB 이름이 나오고, Listener 80의 리다이렉션에 따라서 443으로 보내는 형태로 설정이 가능하게 되었다고 한다.

 

 

PKOS 스터디에서 배웠던 내용이지만, 한 번 더 복습한 내용으로 컨테이너 로그 환경의 표준 로그는 표준 출력(stdout)과 표준 에러(stderr)로 보내는 것을 권고하고 있는데, 이 권고사항을 따르면 kubectl logs를 통해서 컨테이너(Pod)의 로그를 확인할 수 있다.

출처 - 링크

View container logs

 

kubectl logs deploy/nginx -f를 실행했을 때 kubectl로 확인할 수 있는 로그다.

 

 

Pod에 들어가서 살펴보면 로그 출력 경로에 보면 다음과 같이 stdout, stderr가 설정되어 있다.

 

 

Bitnami Nginx 이미지를 확인해보면 심볼릭 링크를 통해 /dev 디렉터리에 access log와 error log를 기록하는 것을 확인할 수 있다. 이 경로를 통해 kubectl logs 명령을 실행했을 때 애플리케이션의 로그를 확인할 수 있다.

참고 자료 - 링크

GitHub - bitnami/containers: Bitnami container images

 

이와 같이 표준 로그 출력 가이드라인을 따를 경우 kubectl logs를 통해 로그를 출력할 수 있기 때문에, 애플리케이션 개발시 권고 사항을 따르는 것이 운영하는 면에 있어서 좋다고 할 수 있다.

 

kubectl logs는 Pod의 로그를 간단히 조회하기 퍈리하지만 다음과 같은 이유로 인해 실무에 적용하기 불편한 부분이 있다.

• 종료된 파드의 로그는 kubectl logs로 조회 할 수 없음
• kubelet 기본 설정은 로그 파일의 최대 크기가 10Mi로 10Mi를 초과하는 로그는 전체 로그 조회가 불가능

그렇기 때문에 Kubernetes Pod의 로그를 중앙에서 수집하는 로깅 환경이 필요하다.

 

---

 

CCI(CloudWatch Container Insight)

CCI(CloudWatch Container Insight)는 컨테이너형 애플리케이션 및 마이크로 서비스에 대한 모니터링, 트러블 슈팅 및 알람을 위한 완전 관리형 관측 서비스다.

 

노드마다 CloudWatch Agent 파드와 Fluent Bit 파드가 데몬 셋으로 배치되어 Metrics과 Log를 수집할 수 있다.

 

출처 - 링크

Fluent Bit Integration in CloudWatch Container Insights for EKS | Amazon Web Services

 

실제로 CloudWatch가 로그와 매트릭을 수집하는지 실습을 통해서 확인해 보았다. 먼저 노드의 로그를 확인해보았다.

 

# 로그 위치 확인
ssh ec2-user@$N1 sudo tree /var/log/containers
ssh ec2-user@$N1 sudo ls -al /var/log/containers

 

위와 같이 노드의 /var/log/ 경로에 다양한 로그들이 존재한다. 그중에서 containers 디렉터리를 살펴보면 아래와 같이 컨테이너/pod의 로그 파일을 확인할 수 있다.

 

 

cat 명령을 통해 로그 파일을 살펴보면 다음과 같이 컨테이너의 실행 로그를 확인할 수 있다.

 

 

다음과 같이 host의 로그도 확인할 수 있다.

 

# 로그 위치 확인
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo tree /var/log/ -L 1; echo; done

# 호스트 로그 확인
for log in dmesg secure messages; do echo ">>>>> Node1: /var/log/$log <<<<<"; ssh ec2-user@$N1 sudo tail /var/log/$log; echo; done

 

 

 

데이터 플레인의 로그도 확인할 수 있다.

 

# 로그 위치 확인
#ssh ec2-user@$N1 sudo tree /var/log/journal -L 1
#ssh ec2-user@$N1 sudo ls -la /var/log/journal
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo tree /var/log/journal -L 1; echo; done

# 저널 로그 확인 - 링크
ssh ec2-user@$N3 sudo journalctl -x -n 200
ssh ec2-user@$N3 sudo journalctl -f

 

 

---

 

실습 3 - CloudWatch Container Insight

이제 다음과 같이 CCI를 설치해 보도록 한다.

 

# 설치
FluentBitHttpServer='On'
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
FluentBitReadFromTail='On'
curl -s https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${CLUSTER_NAME}'/;s/{{region_name}}/'${AWS_DEFAULT_REGION}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -

# 설치 확인
kubectl get-all -n amazon-cloudwatch
kubectl get ds,pod,cm,sa -n amazon-cloudwatch
kubectl describe clusterrole cloudwatch-agent-role fluent-bit-role                          # 클러스터롤 확인
kubectl describe clusterrolebindings cloudwatch-agent-role-binding fluent-bit-role-binding  # 클러스터롤 바인딩 확인
kubectl -n amazon-cloudwatch logs -l name=cloudwatch-agent -f # 파드 로그 확인
kubectl -n amazon-cloudwatch logs -l k8s-app=fluent-bit -f    # 파드 로그 확인

 

CCI 가 설치되면 각 노드가 fluent-bit를 통해 2020 포트로 데이터를 수집할 수 있도록 포트가 열려잇는지 확인한다.

 

for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo ss -tnlp | grep fluent-bit; echo; done

 

 

다음으로는 CW Agent의 설정정보를 확인해 본다.

 

 

다음으로 CW Agent가 수집하는 대상을 확인해 본다.

 

 

AWS 콘솔 > CloudWatch > Container Insights > 리소스 확인

 

 

Container Insights에서 맵 보기를 통해 리소스맵 맵 확인도 가능하다.

 

 

대시보드 보기를 통해 해당 Pod에 대한 전체 매트릭 정보와 컨테이너 별 세부 로그를 확인할 수 있다.

 

 

선택 후 쿼리를 통해 해당하는 로그 역시 확인할 수 있다.

 

 

Metrics-server & Kwatch & Botkube

실습 4 - Metrics-server

Metrics-server는 kubelet으로부터 수집한 리소스의 매트릭을 수집/집계하는 클러스터 Add-on 구성 요소다.

kubernetes Cluster 환경의 메트릭 수집 흐름(Resource Metrics Pipeline)은 다음과 같다.

 

참조 - 링크

Metrics-server는 cAdvisor를 통해 kubelet에 포함된 매트릭을 수집 집계할 수 있다.

 

이전 포스팅에서도 언급했지만, 각각의 요소들이 하는 역할은 다음과 같다.

[5주차] PKOS 쿠버네티스 실무 실습 스터디 (23.02.12)

• cAdvisor: kubelet에 포함된 컨테이너 메트릭을 수집, 집계, 노출하는 데몬
• kubelet: 컨테이너 리소스 관리를 위한 노드 에이전트. 리소스 메트릭은 kubelet API 엔드포인트 /metrics/resource 및 /stats를 사용하여 접근 가능하다.
• 요약 API: /stats 엔드포인트를 통해 사용할 수 있는 노드 별 요약된 정보를 탐색 및 수집할 수 있도록 kubelet이 제공하는 API
• metrics-server: 각 kubelet으로부터 수집한 리소스 메트릭을 수집 및 집계하는 클러스터 애드온 구성 요소. API 서버는 HPA, VPA 및 kubectl top 명령어가 사용할 수 있도록 메트릭 API를 제공한다. metrics-server는 메트릭 API에 대한 기준 구현(reference implementation) 중 하나이다. 또한 API의 HPA를 이용해 노드의 상태 정보를 통해 오토스케일링 솔루션과 연동하여 스케일링 기준을 잡을 수 있다고 한다.
• 메트릭 API: 워크로드 오토스케일링에 사용되는 CPU 및 메모리 정보로의 접근을 지원하는 쿠버네티스 API. 이를 클러스터에서 사용하려면, 메트릭 API를 제공하는 API 확장(extension) 서버가 필요하다.

metrics-server를 배포하면 kubectl top 명령어를 통해 매트릭을 확인할 수 있다.

 

# 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl get pod -n kube-system -l k8s-app=metrics-server
kubectl api-resources | grep metrics
kubectl get apiservices |egrep '(AVAILABLE|metrics)'

# 노드 메트릭 확인
kubectl top node

# 파드 메트릭 확인
kubectl top pod -A
kubectl top pod -n kube-system --sort-by='cpu'
kubectl top pod -n kube-system --sort-by='memory'

 

 

---

 

실습 5 - Kwatch

쿠버네티스 클러스터를 모니터링하고 디버깅하기 위한 툴인 kwatch를 세미나를 통해 배웠다.

 

kwatch에서 제공하는 기능은 다음과 같다.

1. 웹 대시보드: 쿠버네티스 클러스터의 모든 네임스페이스, 리소스 및 이벤트에 대한 시각적인 인터페이스를 제공
2. 실시간 모니터링: 쿠버네티스 클러스터에서 실행 중인 리소스의 상태를 실시간으로 감시하고, CPU, 메모리, 네트워크 등의 성능 메트릭을 확인할 수 있음
3. 로그 뷰어: 클러스터 내의 컨테이너 로그를 검색하고 확인할 수 있음
4. 이벤트 표시: 클러스터의 이벤트 기록을 조회할 수 있음
5. 포트 포워딩: 특정 서비스 또는 팟의 포트를 로컬로 포워딩하여 개발 및 디버깅을 용이하게 함

출처 - 링크

GitHub - abahmed/kwatch: monitor & detect crashes in your Kubernetes(K8s) cluster instantly

 

아래와 같이 슬랙채널을 kwatch와 연결하게 되면 Slack에서 매트릭 기반 문제 상황에 대한 알림을 확인할 수 있다.

 

# configmap 생성
cat <<EOT > ~/kwatch-config.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: kwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kwatch
  namespace: kwatch
data:
  config.yaml: |
    alert:
      slack:
        webhook: '슬랙 체널 주소'
        title: $NICK-EKS
        #text:
    pvcMonitor:
      enabled: true
      interval: 5
      threshold: 70
EOT
kubectl apply -f kwatch-config.yaml

# 배포
kubectl apply -f https://raw.githubusercontent.com/abahmed/kwatch/v0.8.3/deploy/deploy.yaml

 

 

설치 이후 클러스터에 문제가 발생하면 다음과 같이 Slack 채널에 문제상황에 대한 알림이 나온다.

 

 

실습 - PVC 저장공간 70% 채운 후 테스트 (실패 ㅠㅠ 용량을 채웠는데 알림이 안 오는 것 같네요.. ) 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-persistent-storage
              mountPath: /usr/share/nginx/html
      volumes:
        - name: nginx-persistent-storage
          persistentVolumeClaim:
            claimName: my-pvc

#1G PVC에 23Gi를 채운다.
# 잘 안되네요..
kubectl exec -it nginx-pod -- bash -c "dd if=/ of=dumy bs=1000M count=23 && sync"

 

PVC에 용량을 1G로 설정하고, 실제로 생성된 Pod의 용량을 확인해 보니 overlay가 30G 로 잡혀있었다. Chat GPT에 확인해보니 Storage Class의 용량이 우선적으로 적용될 수도 있다고 한다.. 그래서 생성된 30G의 90%를 채웠는데도 알림이 안 오는 것 같다.. 다른 스터디 멤버가 성공한다면 내용을 참고해 봐야 할 것 같다..

 

---

 

실습 6 - Botkube

Botkube에 대해서도 배웠다. 이 툴은 신기하게도 알람 기능 외 슬랙 채널을 이용한 kubectl 명령어를 기반으로 한 조회 기능도 제공한다.

 

다음과 같이 슬랙을 통해 kubectl을 사용할 수 있는 점이 신기했다!!

 

참고 - 링크

Slack | Botkube

 

 

kube-Prometheus-stack

Prometheus Stack

kube-prometheus-stack은 Kubernetes 클러스터를 모니터링하기 위한 Prometheus 관련 도구와 리소스를 helm chats로 설치할 수 있게 제공한다. kube-prometheus-stack에는 아래의 리소스가 포함되어 있다.

 

 

kube-prometheus-stack은 Kubernetes 클러스터를 모니터링하기 위한 Prometheus 관련 도구와 리소스를 helm chats로 설치할 수 있게 제공한다. kube-prometheus-stack에는 아래의 리소스가 포함되어 있다.

1. Prometheus: 쿠버네티스 및 노드의 메트릭을 수집하여 저장하는 역할
2. Alertmanager: Prometheus로부터 수신한 알림을 처리하고, 그룹화, 중복 제거 및 이러한 알림을 이메일, PagerDuty 또는 Slack과 같은 다양한 수신자로 라우팅 하는 기능을 제공(이번 스터디에서는 비활성화하여 진행했다.)
3. Grafana: 다양한 기능을 갖춘 오픈 소스 분석 및 시각화 플랫폼으로, Prometheus의 TSDB에 저장된 리소스를 시각적으로 모니터링할 수 있도록 사용자 정의 대시보드와 그래프 형태로 제공
4. Prometheus Operator: Kubernetes 클러스터에서 Prometheus와 관련 구성 요소의 배포 및 관리를 간소화하는 오퍼레이터

Prometheus target들이 exporter를 이용해 정보를 가져갈 수 있도록 세팅하면 Prometheus server가 매트릭을 Pull 방식으로 수집하여 TSDB에 저장한다.

 

실습 7 - kube-prometheus-stack 설치

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

defaultRules:
  create: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 45.27.2 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

kubectl get prometheus,servicemonitors -n monitoring
kubectl get pod,svc,ingress -n monitoring
kubectl get-all -n monitoring
kubectl get crd | grep monitoring

 

서비스 모니터를 조회하면 Prometheus가 각 서비스의 지표를 수집하기 위해 어떤 서비스를 찾아야 하는지, 어떤 경로로 접근해야 하는지 확인할 수 있다.

 

 

 

두 가지 ALB의 address가 같은 이유는 ingress 쓸 때 alb annotation의 그룹을 썼기 때문이다. 인입 요청의 헤더가 다를 때 Pod로 바이패스시킨다.

 

 

이제 프로메테우스 웹에 접속해서 여러 가지 정보를 확인해 보도록 한다.

 

먼저 TSDB의 상태를 확인해 본다. TSDB에 저장된 매트릭 개수와 같은 것들을 확인할 수 있다.

 

Service Discovery를 확인해 보면 수집 대상을 자동으로 발견하고 관련 정보를 수집하는 것을 확인할 수 있다.

 

 

다음으로 Status/Target탭을 확인해보면 node-exporter의 정보를 수집하는 것도 확인할 수 있다.

 

 

다음과 같이 노드 매트릭과 같은 것들을 그래프 형태로도 확인할 수 있다.

 

 

PromQL을 이용하면 더욱 다양한 정보를 확인할 수 있다.

 

---

 

실습 8 - Grafana 사용

그라파나는 Prometheus의 TSDB를 시각화하여 볼 수 있도록 기능들을 제공한다.

 

kube-prometheus-stack을 설치하면 다음과 같이 9.5.1 버전의 그라파나가 설치되어 있는 것을 확인할 수 있다.

 

 

또한 LB와 연동되어 외부에서 접속이 가능하다.

 

 

Prometheus stack을 설치했기 때문에 Grafana가 자동으로 Prometeus 정보를 읽어온다.

 

 

스택을 통해 설치하면 다음과 같이 기본적으로 설치되어 있는 대시보드들을 확인할 수 있다.

 

 

또한 여러 가지 공식 대시보드를 통해 필요한 매트릭들을 확인할 수 있다. 공식 대시보드는 아래의 경로에서 확인할 수 있다.

참고 - 링크

Dashboards | Grafana Labs

 

Kubernetes / Views / Global - 15757

전체 CPU 사용량, 노드, 네임스페이스 수 등을 확인할 수 있음

 

kube-state-metrics-v2 - 13332

 

Amazon EKS - 16032

AWS CNI Metrics을 확인할 수 있는 Amazon EKS 대시보드는 아래와 같이 Pod Monitor를 배포하면 사용할 수 있다.

 

 

 

Nginx 모니터링 - 12708 

Nginx 모니터링 대시보드를 이용라면 다음과 같이 nginx 헬름 차트의 메트릭 기능을 활성화해줘야 한다.

# 파라미터 파일 생성 : 서비스 모니터 방식으로 nginx 모니터링 대상을 등록하고, export 는 9113 포트 사용, nginx 웹서버 노출은 AWS CLB 기본 사용
cat <<EOT > ~/nginx_metric-values.yaml
metrics:
  enabled: true

  service:
    port: 9113

  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 10s
EOT

# 배포
helm upgrade nginx bitnami/nginx --reuse-values -f nginx_metric-values.yaml

# 확인
kubectl get pod,svc,ep
kubectl get servicemonitor -n monitoring nginx
kubectl get servicemonitor -n monitoring nginx -o json | jq

 

Nginx의 현재 커넥션 정보, 누적 접속정보 등의 메트릭을 수집하는 방법이다.

 

 

이 익스포터를 설치하게 되면 하나의 파드에 익스포터 컨테이너가 하나 더 뜨게 된다.

 

 

그러면 프로메테우스에도 자동을 nginx exporter가 서비스디스커버리에 의해 확인된다.

 

 

여기까지 세팅이 되면 12708 대시보드를 이용하여 Nginx의 매트릭 정보를 확인할 수 있다.

 

 

---

 

Cost Manager

이전 PKOS 스터디에서 Jerry 님이 발표하신 것을 보고 한번 적용해보고 싶었는데, 이번에 가시다님께서 Helm charts를 이용해서 Cost manager를 쉽게 설치하는 방법을 공유해 주셔서 설치해 봤다.

 

 

여러 쿠버네티스 리소스들의 사용금액을 쉽게 확인할 수 있는 점이 좋았고, 나중에 AWS 기반으로 서비스를 운영하는 실무환경에서 사용해 보고 싶다.

 

어려웠던 점 (간만!!)

로드밸런서를 연결하는 과정에서 다음과 같은 에러가 발생했다. 클러스터를 아무리 다시 만들어도 ALB의 주소가 나오지 않았다.

 

 

원인을 몰라 클러스터를 4~5번 재생성했지만 동일한 문제가 발생했다. Ingress를 describe 명령어를 이용해서 확인해 보니 ARN 인증 관련 오류들이 떠있었다. 

 

 

이 ARN들은 각기 다른 도메인들과 연결된 ACM이었고, 이것 때문에 인증과정에서 문제가 발생한 것이었다. 그래서 모든 ACM 정보를 지우고 새롭게 인증서를 발급받아 연결했더니 정상동작되었다. 문제 해결과정에서 ACM 개념에 대해서 한번 더 정리할 수 있었던 계기가 되었다. (스크린 숏의 ARN들은 모두 지운 것들이에요 :.) )

 

짐작만 하고 있던 문제점을 여러 분들께서 함께 고민해 주셔서 헤쳐나갈 수 있었던 것 같다. 새벽에 저 오류가 나는 시점에 생존의 위협을 느꼈었는데.. 그룹 스터디에 친절하신 분들이 많아서 포기하지 않고, 다음날 계속 진행을 할 수 있었다. (너무 감사합니다ㅠ_ ㅠ..)

---

 

마치며

이번 글에서는 EKS Observability에 관한 세미나 내용과 실습한 내용에 대해서 정리했다. Kubernetes 클러스터의 로깅과 모니터링 환경을 helm을 통해 설치하는 것이 이전 스터디보다 훨씬 익숙하게 느껴진다. 그리고 EKS 콘솔을 이용한 리소스 모니터링도 간단한 정보를 확인하기 좋은 것 같았다.

 

PS. 회사에서 진행하는 해외 신규사업에 드디어 AWS 환경을 도입하게 되었다. 스터디에서 내용을 실무에 적용해 보고, 프로젝트 과정에서의 트러블슈팅 내용들을 공유하고 싶다.