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

본 글은 인프런 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2을 직접 정리한 내용입니다:)

 

본 섹션은 쿠버네티스가 실무에 꼭 필요한 이유에 대해 다룬다.
또한 직접 실습해보며 쿠버네티스의 장점을 알아본다.

◼️ 쿠버네티스 선택 기준

쿠버네티스 생태계는 끝이없다.

따라서, 쿠버네티스 생태계에서 함께 사용하는 앱들 중, 어떤 것을 포함하고 제외할지 결정하는 과정이 필요하다.

 

🟢 제외 기준

• 쿠버 관련 교육 파트너 업체는 제외.
• 카오스 엔지니어링은 핵심 영역이 아니므로 제외.
• CNCF 멤버 여부는 제품의 품질과는 무관하므로 비멤버라도 영향력 있는 제품이 존재.
• Graduated: 성숙한 프로젝트.
• Incubating: 성숙해가는 프로젝트.
• Archived: 비활성화되어 기술 지원이 없는 프로젝트는 제외.
• SandBox: 실험 단계의 프로젝트는 제외.

그 중에서 Github Star가 적은 Graduated 프로젝트는 제외하고, Github Star가 많은 Incubating 프로젝트를 포함하는 것이 좋다.

 

부가 기술 제외 후:)

🟢 모니터링/로깅에서의 프로젝트 구조적 문제와 해결

• 개발과 모니터링 시스템이 서로 엮일 수 밖에 없는 구조 → 엮이지 않는 구조로.
• 개발에서는 한 번도 사용하지 않은 개발 시스템을 위한 모니터링 시스템을 만드는 구조 → 개발 초기부터 모니터링 시스템 사용 가능
• 애플리케이션 오픈 시 개발 프로젝트와 서로 다른 범위의 애플리케이션들을 모니터링 하게 되는 구조 → 개발 도중 기능이 추가/삭제되면서 발생하는 애플리케이션의 변경 사항을 자동 반영

◼️ 테스트 앱 배포

먼저 테스트 앱을 만들어보자. 실습은 카페 자료 글을 참고했다.

쿠버네티스 대시보드에서 아래처럼 yaml 파일을 붙여넣는다.

 

🔶 실습 애플리케이션 app-1-2-2-1 yaml 설정

• Deployment: app-1-2-2-1 애플리케이션을 쿠버네티스에 2개의 복제본(Pod)으로 배포하고, 롤링 업데이트 전략을 사용해 점진적으로 업데이트한다. 컨테이너의 상태를 확인하기 위해 startupProbe, livenessProbe, readinessProbe를 설정하며, 리소스 제한과 요청을 지정했다.
• Service: NodePort 타입의 서비스로, 외부에서 31221 포트를 통해 8080 포트로 접근 가능하다.
• HorizontalPodAutoscaler (HPA): CPU 사용률이 40% 이상일 때 최소 2개에서 최대 4개의 Pod로 자동 확장하는 설정을 포함했다.

파드 생성 완료:)

 

◼️ 모니터링 설치

모니터링 설치와 간단한 실습을 진행해보자. Prometheus와 Grafana, Loki-Stack을 사용하여 쿠버네티스 환경에서 모니터링을 설정하고, Grafana에서 Loki-Stack을 연동하는 과정을 다룬다.

실습을 카페 자료 글을 참고했다.

 

💻 실습 내용

1. GitHub에서 Prometheus 및 Loki-Stack YAML 파일 다운로드

2. Prometheus 및 Grafana 설치

3. Loki-Stack 설치

4. Grafana 접속

• Grafana 웹 인터페이스에 접속하여 모니터링 대시보드를 설정
• 웹 브라우저에서 http://192.168.56.30:30001로 접속하여 Grafana에 로그인
• 기본 ID와 비밀번호(admin/admin)를 사용하여 로그인

5. Grafana에서 Loki-Stack 연결

• Grafana에 Loki-Stack을 데이터 소스로 연결하여 로그 데이터를 시각화할 수 있도록 설정
• 주요 과정:
  • Grafana의 Connect Data 메뉴에서 Loki를 검색하여 선택
  • Loki의 URL을 입력: http://loki-stack.loki-stack:3100
  • Save & Test를 클릭하여 연결 상태를 확인하고, Loki가 제대로 연결되었는지 테스트

explore탭에서는 앱의 로그도 확인가능하다.:)

◼️ 쿠버네티스 대표 기능 - Traffic Routing, Self-Healing, AutoScaling, RollingUpdate

🔶 Traffic Routing 테스트 (App에 지속적 트래픽 보내기)

앱에 지속적으로 트래픽을 보내보자. 

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

터미널 로그-트래픽을 받는 앱의 이름을 출력한다.:)

여기서, 하나의 파드를 삭제하면 쿠버네티스는 죽은 파드에 트래픽을 보내지 않고 있다가 파드 복구생성이 완료되면 트래픽을 분배시킨다.

파드 복구 예시

🔶 Self-Healing 테스트 (memory leak 복구)

curl 192.168.56.30:31221/cpu-load

앱이 죽자마자 restart를 시켜 살아난다...! (재시작+1)

메모리릭이나면 자동 재시작:)

원인을 찾고 싶으면 해당 파드를 조회해 해당 시간대 Loki 로그를 확인할 수 있다.:)

🔶 AutoScaling 테스트 (App에 부하주기)

cpu 평균 40% 가 넘으면 쿠버네티스는 이를 감지해 파드를 늘려준다.

그리고 시간이 지나 부하가 떨어지면 파드를 다시 감소시킨다.

curl 192.168.56.30:31221/cpu-load

 

CPU 40%를 넘었을 때 자동생성된 파드:)

CPU 40%를 넘었을때, 2개의 파드가 생성되는 모습:)

부하 감소시 파드 수도 자동 감소:)

 

🔶 RollingUpdate 테스트 (App 이미지 업데이트)

아래에서 파드 하나를 업데이트해보자. 파드가 업데이트 되는 동안에도 트래픽은 끊기지 않는다.

이미지 업데이트:)

 

◼️ 쿠버네티스의 편리함

1. 기존 방식:
   • VM 담당자가 인프라 OS 및 애플리케이션 설정을 한다.
   • 웹서버 관리자는 IP 설정과 앱을 시작하지만, 이 작업은 운영 상황에서 바로 수행하기 어려워 야간이나 주말에 진행한다.
   • 모니터링 담당자는 앱이 실행되었는지 모를 수 있으며, 배포 통보를 받은 후에야 모니터링 설정을 한다.
2. 쿠버네티스 방식:
   • Pod 증설 요청을 하면 쿠버네티스 담당자가 증설 명령을 입력하여 자동으로 새로운 Pod를 생성한다.
   • Pod가 생성되면 자동으로 IP 할당 및 모니터링 설정이 완료된다.
3. 쿠버네티스의 장점:
   • 코드로 인프라 관리: 작업 기록이 남아 추적이 쉽고, 인프라 환경에 대한 파일을 사전에 준비할 수 있어 반복 작업을 줄이고, 퀄리티 향상에 집중할 수 있다.
   • 경험 기반 코드 활용: 인프라 작업 시 축적된 경험을 코드로 활용하여 효율을 높일 수 있다.