[쿠버네티스 어나더 클래스 (지상편) - Sprint 1] 03. 실무에서 느껴 본 쿠버네티스가 정말 편한 이유 (강의를 보고)

 
* 본 게시물은 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의와 강의 자료를 바탕으로 작성되었습니다.
 

[이번 강의 요약]

• 모니터링(Prometheus with Grafana)과 로깅(Loki Stack)에 관한 내용
• K8s 대표 기능 - Traffic Routing, Self-Healing, AutoScaling, RollingUpdate

 

[들어가기에 앞서]

• 기존의 모니터링 방식은?

개발 패키지에 에이전트를 심거나, 개발 코드를 변경하기도 함
때문에, 성능 상 문제가 발생하면 에이전트를 의심하는 상황도 생겼음

1. 개발과 모니터링 시스템이 서로 엮일 수 밖에 없는 구조
2. 개발에서는 한 번도 써보지 않은 (개발 시스템을 위한) 모니터링을 만드는 구조
3. 오픈 시, 개발 프로젝트와 서로 다른 범위 App들을 모니터링 하게 되는 구조

• Kubernetes 생태계 모니터링과 로깅 툴들을 사용하면?

1. 개발과 모니터링 시스템이 엮이지 않음
2. 초기부터 바로 쓸 수 있는 모니터링
3. 오픈 시, 개발 프로젝트와 자동으로 같아지는 범위를 모니터링하게 됨

[모니터링 설치] Prometheus with Grafana & Loki Stack

* 강의 내 제공되는 github 저장소를 이용해 패키지를 설치했음

[1] Github(k8s-1pro)에서 Prometheus(with Grafana), Loki-Stack yaml 다운로드

# git 설치
yum -y install git

# 로컬 저장소 생성
git init monitoring
git config --global init.defaultBranch main
cd monitoring

# remote 추가
git remote add -f origin https://github.com/k8s-1pro/install.git

# sparse checkout 설정 => 특정 패턴에 해당하는 파일만 작업 디렉터리에 가져오도록 함
git config core.sparseCheckout true
echo "ground/k8s-1.27/prometheus-2.44.0" >> .git/info/sparse-checkout
echo "ground/k8s-1.27/loki-stack-2.6.1" >> .git/info/sparse-checkout

# 다운로드
git pull origin main

> 결과

 
 
[2] Prometheus(with Grafana) 설치

# 설치
kubectl apply --server-side -f ground/k8s-1.27/prometheus-2.44.0/manifests/setup
kubectl wait --for condition=Established --all CustomResourceDefinition --namespace=monitoring
kubectl apply -f ground/k8s-1.27/prometheus-2.44.0/manifests

# 설치 확인
kubectl get pods -n monitoring

> 결과

 
 
[3] Loki-Stack 설치

# 설치
kubectl apply -f ground/k8s-1.27/loki-stack-2.6.1

# 설치 확인
kubectl get pods -n loki-stack

> 결과

 

• Promethus with Grafana(Dashboard)를 통해 자원을 모니터링
• Grafana에서 loki를 통해 작동 중인 App의 log를 모아 볼 수 있음

 

[쿠버네티스 기능으로 편해진 서비스 안정화]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-1-2-2-1
spec:
  selector:
    matchLabels:
      app: '1.2.2.1'
  replicas: 2
  strategy:
    type: RollingUpdate

• 위는 yaml 파일의 일부로, `replicas: 2` 로 Pod를 이중화 시키겠다는 의미

apiVersion: v1
kind: Service
metadata:
  name: app-1-2-2-1
spec:
  selector:
    app: '1.2.2.1'
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 31221
  type: NodePort

• `nodePort: 31221` 은 MasterNode의 Port 번호로, 31221번 포트로 접근하는 트래픽을 지정된 app으로 보내는데, 
  위에서 Pod를 이중화 시켜줬으므로 트래픽을 2개의 Pod에 골고루 보냄

 

• 만약 메모리 누수와 같은 이유로 서버가 죽었을 경우, K8s에서 서버를 자동으로 재시작 해줌
  • K8s에서 재시작에 1이 표시되어 있을 경우, 재시작된 Pod로 Grafana에서 메모리가 높아지게 된 구간을 알 수 있으며,
    Loki로 가서 로그를 찾아보고 에러를 확인하고 원인을 파악할 수 있음

 

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-1-2-2-1
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-1-2-2-1
  minReplicas: 2
  maxReplicas: 4
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 40

• 만약 CPU 사용량이 올라가 yaml에서 정의한 40%가 넘을 경우, 이것을 감지하여 정의된 최대 4개까지 Pod를 늘려줌
  • 부하가 감소하면, 생성된 Pod를 다시 종료시킴

 

• Image 업데이트 시, 트래픽이 끊기지 않고 업데이트된 Pod를 새로 생성해 실행이 완료되면,
  기존에 실행되던 Pod를 종료시킴
• 만약, 새 이미지가 정상적으로 기동되지 않는다면?
  • K8s에서 정상적으로 기동되지 않는 이미지를 계속 재시작을 시킴
    -> K8s에서 새 이미지가 정상적으로 기동되는 것을 확인하고 기존의 Pod를 지우기 때문에 안정적