(3) 실무에서 느껴 본 쿠버네티스가 정말 편한 이유

⚓ 쿠버네티스 어나더 클래스 (지상편) - Spring 1, 2 을 듣고 작성하는 복습 블로그 입니다.

 

1. IT 인프라 구축

출처URL : https://inf.run/k7mF

개발	App 개발에서 배포까지 써야하는 기술들
오케스트레이션 / 매니징	App 을 마이크로 서비스로 만들 때 쓰면 좋은 기술들
플랫폼, 런타임	App 을 클라우드로 올릴 때 주로 사용되는 기술들
프로비저닝, 분석	App 을 마이크로 서비스로 개발하고, 클라우드까지 올린다면 알아야 하는 기술들

 

실제 여기서 모니터링, 로깅을 기반으로 쿠버네티스를 사용해야 하는 이유를 알아보면

기존에는

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

였지만, 쿠버네티스 생태계에 있는 모니터링과 로깅 툴을 사용하면

1. 개발과 모니터링 시스템이 서로 엮이지 않는 구조
2. 개발에서는  초기부터 바로 쓸 수 있는 모니터링 시스템을 만드는 구조
3. 오픈시 개발 프로젝트와 자동으로 같아지는 범위의 App 들을 모니터링 하게 되는 구조

로 굉장히 간단하게 사용할 수 있다.

---

2. 모니터링 설치 (Loki-Stack)

https://cafe.naver.com/kubeops/30 를 통해 설치 가능

Prometheus, Grafana, Loki-Stack 을 설치하게 되는데 각각은 아래와 같은 역할을 한다.

	역할	기능
Prometheus	메트릭 수집	- 시계열 데이터 수집 및 저장 - 애플리케이션이나 시스템의 메트릭 수집
Grafana	시각화	- Prometheus 와 연결하여 데이터를 대시보드로 시각화 - 커스터마이징 가능한 그래프, 차트, 테이블
Loki	로그 저장/분석	- 로그 데이터를 저장하지만, 메트릭처럼 인덱싱은 최소화해서 효율적 - Grafana 와 잘 통합되어 로그를 시각화하고, 메트릭과 로그를 연계 분석 가능
Loki-stack	통합 배포 스택	- Loki + Grafana + Promtail (Loki 에 로그를 보내는 로그 수집기) 을 묶은 스택

 

실제로 설치한 후 Grafana 대시보드에 들어가면 다양한 대시보드들을 확인할 수 있다.

pod 대시보드

• 하나의 대시보드를 복사해서 나만의 대시보드를 만들 수 있다.
• https://grafana.com/grafana/dashboards/ 에서 다양한 대시보드들을 받아서 사용할 수 있다.
• 정말 다양한 대시보드들을 지원한다.

그리고 Explore 에서 Loki 를 통해 

 

각 파드들의 Log 도 확인가능하다.

---

3. 쿠버네티스 대표 기능 - Traffic Routing, Self-Handling, AutoScaling, RollingUpdate

 

현재 떠있는 Pod 는 두개

App 을 호출하면 두 Pod 에 트래픽이 골고루 들어간다

 

[3-1] App 에 지속적으로 트래픽 보내기 (Traffic Routing 테스트)

while true; do curl http://192.168.56.30:31221/hostname; sleep 2; echo '';  done;

 

→ App 에 지속적으로 트래픽을 보내서 골고루 트래픽이 두 Pod 로 가는지 확인하기 위한 코드

→ 두 Pod 에 트래픽을 골고루 분산한다

 

 

→ 만약 실수로 하나의 Pod 가 삭제되어도 새로운 Pod 가 다시 뜨고, 뜰 동안은 해당 Pod 로 트래픽을 보내지 않는다. 

 

[3-2] App에 Memory Leak 나게 하기 (Self-Healing 테스트)

curl 192.168.56.30:31221/memory-leak

 

→ 트래픽을 받은 파드 하나가 죽고, 재시작이 1로 올라감

→ 쿠버네티스가 App 이 죽자마자 재시작을 시킴

 

[3-3] App에 부하주기 (AutoScaling 테스트)

curl 192.168.56.30:31221/cpu-load

 

→ 부하가 생기면 쿠버네티스가 알아서 새로운 파드들을 띄워준다

→ 그리고 시간이 지나서 부하가 떨어지면, 쿠버네티스가 알아서 파드들을 감소

 

[3-4] 기동되지 않는 App 업데이트 (RollingUpdate 테스트)

kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-error

 

→ App 이 실행되지 않으면 쿠버네티스가 계속 앱을 재시작

→ 새 이미지가 잘 기동이 되는지 확인 후 기존 이미지를 바꾸기 때문에 작업자의 실수가 있어도 보완

---

4. 쿠버네티스로 편해진 서비스 안정화 및 인프라 환경 관리 코드화

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

출처URL : https://inf.run/k7mF

	부하가 심해진 경우
기존 VM 환경	VM 담당자 : 수동으로 was, jdk, os, network, storgae 설정들을 미리 해둔다 Web 담당자 : 웹서버를 관리하는 사람이 IP 를 설정해야 한다 → 어떤 사이드이펙이 발생할지 모르니 밤에 작업 다음날 모니터링 담당자에게 App 이 세 개 보이도록 config 작업
쿠버네티스 환경	쿠버네티스 엔지니어 : 파드를 늘린다 쿠버네티스가 파드 생성과 동시에 수동으로 했던 IP Setting, Config 작업을 자동으로 적용해준다

 

→ 쿠버네티스 환경으로 하는 것이 훨씬 빠르고 관리자의 부담을 덜 수 있다.

 

[4-2] 인프라 환경 관리의 코드화

• 인프라 설정을 수동으로 하는 거랑 파드에 인프라 환경 설정이 코드로 들어가서 자동으로 하는 건 큰 차이다.

👍 쿠버네티스, 인프라 환경 관리의 장점

1. 인프라에 대한 History 관리가 편함
2. 인프라 작업 추적 가능
3. 인프라 환경별 파일 생성
   1. 시간이 있을 때 미리 구성 가능
   2. 작업은 Copy & Paste
4. 인프라 반복 작업 x, 퀄리티 향상에 집중
5. 새 인프라 작업시 이전 경험을 녹인 코드 활용