서론

해당 글은 일프로 님의 인프런 강의 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2의 내용을 정리한 글입니다.

해당 글에 사용된 내용, 사진 및 그림은 모두 강의와 강의 자료에 포함된 내용입니다.

쿠버네티스 표준 생태계로 편해진 IT 인프라 구축

• IT에 관련된 대부분의 기업이 쿠버네티스와 컨테이너에 진입을 했다고 과언이 아닐 정도

• CNCF 분류
  • CNCF 프로젝트
    • CNCF에 기여된 프로젝트
    • 다음과 같은 성숙도 단계 존재
      • Graduated Projects : 완전히 성숙된 상태
      • Incubating Projects : 안정적이며, Graduated로 이동하고 있는 단계
      • Sandbox Projects : 실험 단계
      • Archived Projects : 프로젝트가 비활성화된 상태, 더 이상의 기술 지원이 없음
  • CNCF 멤버
  • 비 CNCF 멤버
    • 비용은 지불하지 않지만 생태계에 영향을 주는 경우가 있음
    • github stars 수로 판단
• 개발
  • 기존 애플리케이션 개발 시 사용했던 기술
• 오케스트레이션 / 매니징
  • 애플리케이션을 마이크로서비스로 만들 때 권장되는 기술
• 플랫폼 & 런타임
  • 애플리케이션을 클라우드에서 실행시킬 때 권장되는 기술
• 프로비저닝 & 분석
  • 실제 프로젝트에서 사용해야 하는 기술

실제 프로젝트를 할 때 구조적인 문제

1. 개발과 모니터링 시스템이 서로 엮일 수 밖에 없는 구조
   1-1. 쿠버네티스와 모니터링을 통해 개발과 모니터링 시스템을 분리
2. 개발에서는 한 번도 사용하지 않은 개발 시스템을 위한 모니터링 시스템을 만드는 구조
   2-1. 이미 존재하는 오픈 소스를 통해 개발 초기부터 모니터링 시스템 사용 가능
3. 애플리케이션 오픈 시 개발 프로젝트와 서로 다른 범위의 애플리케이션들을 모니터링 하게 되는 구조
   3-1. 개발 도중 기능이 추가/삭제되면서 발생하는 애플리케이션의 변경 사항을 자동으로 반영

모니터링 도구 설치

• [Sprint1] 실무에서 느껴 본 쿠버네티스가 정말 편한 이유 > 모니터링 설치 - Loki-Stack를 토대로 진행

쿠버네티스 대표 기능

• 테스트 애플리케이션은 [Sprint1] 실무에서 느껴 본 쿠버네티스가 정말 편한 이유 > 쿠버네티스 대표 기능를 토대로 진행

• 파드를 이중화한 상태
• 서비스는 자체적으로 파드가 두 개 있으면 트래픽을 두 pod로 분산
• 오토 스케일링의 경우 최소 2, 최대 4이며 CPU를 기준으로 평균 40%가 넘으면 적용

Traffic Routing

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

• 2초 간격으로 꾸준히 트래픽을 발생시키는 명령어

• 각 파드가 트래픽을 고르게 가져가고 있음

• 파드를 하나 강제로 삭제한다고 하더라도 자동으로 이를 복구함

Self-Healing

curl 192.168.56.30:31221/memory-leak

• 강제로 메모리 릭 발생

• 쿠버네티스에서 메모리 릭이 발생한 파드를 재시작(1)한 것을 확인할 수 있음

• 그라파나에서 CPU 사용량이 폭증한 시간대 확인

• 발생한 파드와 시간대를 토대로 문제 로그 확인 가능
• 로그를 통해 OOM 발생 이후 쿠버네티스가 자동으로 재시작하는 것을 확인할 수 있음

AutoScaling

curl 192.168.56.30:31221/cpu-load

• 기존 상태

• 증가한 트래픽에 따라 Auto Scaling이 적용되어 파드 수가 2 -> 4개로 증가

• 트래픽이 감소하면 다시 파드 수가 4 -> 2로 감소

RollingUpdate

성공 시

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

• 트래픽이 계속 발생하고 있는 환경에서 이미지 업데이트 수행

• 이미지 버전을 변경하면서 아직 기동되지 않은 새 버전이 아닌 이전 버전 파드에 트래픽 분산

• 새 버전이 기동된 이후 이전 버전에 대한 파드 삭제

• 새 버전 파드에 트래픽 분산
  • 이 모든 과정 중 트래픽은 꾸준히 들어오고, 모든 트래픽은 정상적으로 처리됨

실패 시

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

• 새 이미지가 정상적인지 확인한 뒤 기존 이미지를 바꾸기 때문에 실패하더라도 쿠버네티스가 이를 처리해줌
  • 문제가 발생한 이미지 버전은 정상적으로 동작하지 않기 때문에 이전 이미지 파드에서 트래픽 처리

kubectl rollout undo -n default deployment/app-1-2-2-1

• 이미지 업데이트를 취소시키면 문제가 되는 파드를 삭제
  • 이 모든 과정 중 트래픽은 꾸준히 들어오고, 모든 트래픽은 정상적으로 처리됨

쿠버네티스 서비스 안정화

• 서비스 오픈 당일
  • 오픈 이전 사용자 트래픽을 예상하고 성능 테스트를 해 애플리케이션의 자원 할당을 결정
    • 모든 기능에 대한 성능 테스트는 현실적으로 불가능
    • 오픈 전후로 주요 로직이 변경될 수도 있음
    • 오픈 당일에는 사용자가 예측 불가능하게 서비스를 호출하므로 성능 테스트처럼 정상적인 케이스만 요청되지 않음
    • 이를 대비하기 위해 여유 자원을 미리 준비한 상황이라고 가정
• 수동 설정 시
  1. 서버 증설이 필요한 경우 VM 관리자가 네트워크, 스토리지 등을 준비해 트래픽을 분산할 수 있도록 준비
  2. 웹 관리자가 트래픽이 분산될 수 있도록 새로운 애플리케이션의 IP 세팅
     2-1. 기존 웹 서버에 영향을 주는 작업은 해당 작업으로 인해 문제가 발생할 수 있으므로 진행하기 까다로움
     2-2. 수동으로 작업하다 보니 설정 과정에서 문제가 생길 수 있음
  3. 새로운 애플리케이션 IP 세팅 완료
  4. 모니터링 담당자가 새로운 애플리케이션의 메트릭을
• 자동 설정 시
  1. 서버 증설이 필요한 경우 쿠버네티스 관리자가 쿠버네티스에게 증설 요청
  2. VM에서 수행했던 작업들을 모두 자동으으로 안전하게 적용
     2-1. 개발 기간 ~ 성능 테스트를 하면서 자동화된 동작에 문제가 없음을 확인
     2-2. 파드 안에 설정이 모두 있기 때문에 스케일링된 파드 중 단 하나만 문제가 생기는 경우는 존재하지 않음
• 이러한 차이점으로 인해 쿠버네티스 환경이 관리자 입장에서 빠른 의사결정과 실행을 할 수 있도록 지원해준다고 볼 수 있음

쿠버네티스 인프라 환경 관리 코드화

• 인프라 형상 관리
  • Dockerfile과 같은 컨테이너 런타임에서 어떤 컨테이너를 생성할지 설정 파일로 명시
  • 쿠버네티스 파드 관리를 yaml로 처리할 수 있음
  • 이를 통해 History 관리가 편해짐
• 인프라 작업 추적 가능
  • 인프라 환경 관리를 코드로 수행하면서 형상 관리가 가능해졌으므로 이 작업을 수행한 시점 및 인원을 추적할 수 있음
• 인프라 환경별 파일 생성
  • 실제 배포 환경이 세팅되지 않더라도 인프라 환경 파일 처리 가능
  • 코드를 복붙해 간편하게 처리 가능
  • 단순 반복이 줄어듦
• 새 인프라 작업시 이전 경험을 녹인 코드를 활용할 수 있음