K8S

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 Section 5 복습

개발공명 2025. 6. 13. 21:22

 

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

 

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

쿠버네티스 기반 it 생태계가 매우 커지고 쿠버네티스가 굉장히 빠르게 확산되고 있다.

쿠버네티스 나온지 10년 안됐는데 아래 그림과 같이 많은 제품들이 쿠버네티스 생태계 위에서 돌아간다.

 

클라우드 생태계를 영역별로 카테고리화 하고 많은 제품들 중 생태계에 영향력이 있는 제품들을 분류해보면 아래와 같다. 

 

각 카테고리에 대한 설명을 보자.

  • 개발 파트
    • 개발에서 배포까지 사용하는 기술
  • 오케스트레이션 / 매니징 파트
    • 개발한 app을 마이크로 서비스로 만들 때 사용하는 기술
  • 플랫폼 / 런타임 파트
    • app을 클라우드에 올릴 때 사용하는 기술
  • 프로비저닝 / 분석 파트
    • 실제 프로젝트에서 사용하는 기술

 

프로젝트에서 app을 마이크로 서비스로 개발하고 클라우드에 올리려면 위의 카테고리를 다 알아야 한다. 

요즘은 이런 형태의 프로젝트가 대부분이기에 다 알아야 한다.

 

많은 오픈 소스가 나오는데 다 공부해야 하나 싶을 수 있다. 

이것들이 지금까지는 대표이기에 이 제품들에 집중해도 충분하다.

 

 

모니터링 인프라 구축으로 보는 쿠버네티스가 편한 이유

 

큰 규모의 개발 프로젝트를 하면 장애 요소가 많으니 프로젝트에 적합한 모니터링 시스템 같이 개발하는 경우 많다.

하지만 쿠버네티스를 사용하지 않고 모니터링 시스템 개발하는 경우 아래와 같은 문제가 생긴다.

 

쿠버네티스를 사용하지 않고 모니터링 시스템 개발하는 경우 

  • 모니터링 시스템과 개발 시스템 구조적 문제
    • app 모니터링, 로깅 하려면 개발 패키지에 에이전트 심거나 개발 코드 변경 필요
    • ex : spring 프로젝트의 build.gradle에 모니터링 툴 추가
    • 결국 모니터링 시스템과 개발 시스템이 엮일 수 밖에 없는 구조가 됨 (의존성 존재)
  • 모니터링 시스템 개발 초기 사용 불가 문제
    • 모니터링 시스템, 개발 시스템 동시에 시작됨
    • 이러면 개발 시스템에서 처음에 모니터링 하며 문제점 확인 불가능
    • 따라서 로그 등 찾아보며 장애 분석
    • 모니터링 시스템 완성되어도 익숙한 로그 찾아봄
    • 결국 개발 도중에는 사용하지 않는 모니터링 시스템 만드는 구조가 됨
  • 개발 후기에 모니터링 시스템에서 app 제외 문제
    • 개발 후기에 요구사항 달라져 app 추가, 제외 빈번
    • 모니터링 시스템에 app 자동 인식 기능 없을 수 있음
    • 또는 추가된 app에 모니터링 관련 에이전트 심는 것 까먹을 수 있음
    • 또는 모니터링 시스템 완성되어 관련 개발자 없을 수 있음
    • 결국 오픈 시 app의 추가, 제외 반영되지 않은 개발 시스템과 서로 다른 범위의 app 모니터링 하는 구조가 됨

 

쿠버네티스를 사용하고 모니터링 시스템 개발하는 경우 

 

  • 모니터링 시스템과 개발 시스템은 엮이지 않음
    • app에 에이전트나 코드 추가 없이 쿠버네티스에 개별적으로 띄울 수 있음
  • 개발 초기부터 바로 사용 가능
    • 쿠버네티스에 모니터링, 로깅 시스템 제품들 빠르게, 바로 띄울 수 있음
  • 항상 앱이 자동으로 반영되는 구조
    • 실행 중인 app이 자동으로 보임
    • app이 추가되어도 추가 동작 없이 자동화 되어 있음

 

쿠버네티스에 표준 아키텍쳐가 있고 모두가 이것을 지켜 만들었기 때문에 가능한 것이다.

따라서 쿠버네티스 표준으로 IT 인프라 구축이 편해진 것이다.

 

 

쿠버네티스 대표 기능

쿠버네티스의 대표 기능으로 아래 4가지가 있다.

  1. Traffic Routing
  2. Self Healing
  3. Auto Scaling
  4. Rolling Update

 

각각이 어떤 기능인지 살펴보자.

 

1. Traffic Routing

트래픽이 한 곳으로 몰리는 것이 아니라 골고루 여러 pod로 가는 것이다. 

쿠버네티스 자체에서 pod가 여러 개 있으면 트래픽을 골고루 보내준다.

이런 기능이 있기에 서비스의 고가용성 및 부하 분산을 보장할 수 있게 된다.

트래픽을 여러 pod에 분산 시켜 쉽게 다운되지 않고 병목 현상을 줄여 성능을 향상 시킬 수 있는 것이다.

 

2. Self Healing

쿠버네티스에 self healing 기능 덕분에 웬만한 상황에서도 서비스가 안정적으로 유지가 된다.

 

pod가 원인 모를 이유로 삭제 되어도 바로 새 pod가 만들어진다. (pod를 n개로 설정해 놓았다면 n개를 마추도록 생성이 된다)

pod가 삭제 되고 만들어지는 동안에 삭제된 pod로 트래픽이 가면 문제가 될 것이다.

하지만 쿠버네티스는 pod가 새로 만들어지고 기동되는 동안에 삭제된 pod에 트래픽 보내지 않는다.

그리고 새 pod 기동이 완료가 되면 트래픽을 다시 분배한다.

 

또 오류나 메모리가 너무 증가해 pod가 죽거나 문제가 생길 수 있다.

쿠버네티스는 app이 죽자마자 restart를 시킨다.

그리고 역시 살아있는 pod에게만 트래픽이 가도록 한다.

 

쿠버네티스가 pod 장애 상황에서 다시 살려주면서 서비스를 안정적으로 유지시켜 준다.

 

3. Auto Scaling

pod가 2개가 있는데 부하가 증가된다.

그러면 많은 트래픽을 받은 pod의 cpu 사용량이 올라간다.

이때 쿠버네티스가 설정한 cpu 사용량을 넘어가면 감지해 pod 개수를 자동으로 늘려준다.

추가된 pod가 기동되면 트래픽이 자동으로 분산이 된다.

시간이 지나 부하가 감소한다.

그러면 쿠버네티스는 자동으로 pod를 다시 2개로 감소 시킨다.

쿠버네티스는 부하 상황에서도 auto scaling 기능으로 서비스를 안정적으로 유지할 수 있게 해준다.

 

4. Rolling Update

app에 업데이트가 필요할 때가 있다.

따라서 app의 이미지 업데이트를 해보자.

 

이미지 업데이트하는 pod가 기동이 되고 이전 pod가 남아있는다.

따라서 업데이트 동안에도 트래픽은 끊기지 않는다.

업데이트 된 pod가 정상 동작하면 이전 pod를 제거해 트래픽이 끊기지 않는다.

 

업데이트를 했는데 업데이트에 문제가 생겨 새 이미지가 정상적으로 기동이 안 될 수 있다.

쿠버네티스는 새 이미지가 정상적으로 잘 기동 되는지 확인한다.

정상적으로 기동 되지 않으면 쿠버네티스가 해당 app을 계속 재시작 한다.

이처럼 쿠버네티스가 새 이미지가 잘 기동이 되는지 확인 후에 기존 이미지를 바꾸기 때문에 실수가 있어도 보완을 해준다.

 

쿠버네티스가 앱의 상태를 확인하고 업데이트하면서 서비스를 안정적으로 유지시킬 수 있다.

 

이러한 대표 기능들이 있어 쿠버네티스를 서비스 운영을 할 때에 굉장히 편하게 사용할 수 있다.

 

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

쿠버네티스를 사용하면 편리한 점이 또 있다.

기존 vm 환경과 쿠버네티스 환경에서 서비스 안정화를 어떻게 하는지 보며 어떻게 편해졌는지 보자.

두 환경 모두 아래와 같은 상태이다.

  • 웹 서버를 통해 트래픽이 라우팅 되어 들어오고 있다.
  • 모니터링 시스템도 연결되어 있다.

 

시스템 오픈 날을 상상해보자.

오픈 날에는 사용자도 평소보다 이것저것 화면을 더 눌러보기 때문에 성능 테스트때처럼 정상적인 케이스만 들어오지 않는다.

그래서 오픈 때에는 여유 자원을 할당해 놓고 늘릴 준비를 하게 된다.

이런 시스템 오픈 날에 각 환경에서 부하가 심해질 때 어떻게 되는지 보자.

 

기존 VM 환경

  1. 부하가 심해져 증설해야 한다고 판단된다.
  2. VM에 OS를 담당하는 사람이 was, jdk, ... (그림의 1번) 등의 설정들을 미리 해 놓는다.
  3. 웹 서버 담당하는 사람이 ip 설정해야 한다.
  4. 이런 설정들을 변경하면 기존 시스템에 영향 주거나 문제가 되는 경우가 많다.
  5. 따라서 부하 심할 때 간헐적으로 에러가 나지만 야간에 작업을 한다.
  6. 다음날 모니터링 담당자가 추가된 app이 보이도록 작업을 한다.

기존 VM 환경에서는 담당자가 3명이 필요하고 야근까지 해야 한다.

각자 맡은 부분에 어려운 설정들을 해야 한다.

또 문제가 생길 수 있어 에러가 나는 상황에서도 묵인하고 야간에 작업을 해야 한다.

이것이 기존 VM 환경에서 오픈 날 일어나는 흔한 패턴이다.

 

쿠버네티스 환경

  1. 부하가 심해져 증설해야 한다고 판단된다.
  2. 쿠버네티스 엔지니어가 버튼 하나 눌러 pod를 늘린다.
  3. 쿠버네티스가 pod 생성과 동시에 기존 VM 환경에서 했던 작업들 자동으로 적용해준다.
    1. pod의 환경 설정
    2. 웹 서버와의 ip 설정
    3. 모니터링 시스템 설정

 

개발 기간 동안 쿠버네티스의 자동화된 동작들에는 문제 없다는 것을 계속 보고 검증하기에 걱정하고 문제가 될 것이 없다.

또 pod 안에 설정이 다 들어 있어 pod 하나 추가하는데 기존 pod들과 다르게 설정에 실수 생기는 일 발생하기 어렵다.

그래서 쿠버네티스 환경이 관리자 입장에서 빠른 의사 결정과 실행을 할 수 있게 해준다.

 

쿠버네티스 기능으로 편해진 인프라 환경 관리 코드화

쿠버네티스가 편한 이유가 하나 더 남아 있다.

바로 쿠버네티스 관리 환경의 코드화이다.

인프라 설정을 수동으로 하는 것과 pod에 인프라 설정이 코드로 들어가서 자동으로 되는 것은 엄청난 차이이다.

이 차이가 인프라 환경 관리를 정말 편하게 해준다.

 

어떻게 코드화를 하고 어떤 장점이 있는지를 보자.

  1. Dockerfile로 컨테이너 빌드를 코드화 가능
    1. Dockerfile로 컨테이너가 만들어진다.
    2. 그래서 이 파일만 있다면 늘 같은 컨테이너를 만들 수 있다.
  2. 인프라에 대한 history 관리가 편해짐
    1. 기존 VM 환경에서는 컨테이너 만드는 이런 작업한 내용이 기록으로 관리되지 않는다.
    2. 작업 절차 문서를 만든다고 해도 실제 작업 내용과 차이가 생길 수 있다.
    3. 코드로 환경을 관리하고 변경하기 때문에 배포하려면 이렇게 작업 이력 (commit)을 남길 수 밖에 없다.
    4. 그래서 개발과 똑같이 인프라도 변경 관리의 대상이 될 수 있다.
  3. 쿠버네티스의 pod 관리도 yaml 파일로 한다.
    1. pod 몇 개 띄울 것인지, 자원 얼마나 줄 것인지 등 yaml 파일로 다 설정한다.
    2. 따라서 yaml 파일로 쉽게 코드화 해 관리할 수 있다.
  4. 인프라 작업 추적 가능
    1. 이렇게 코드로 관리해 누가 무슨 작업을 했는지도 추적이 가능하다.
    2. 인프라 이슈가 생겼을 때 누가 실수한건 아닌지 서버 로그를 보는데 프로젝트를 하다보면 admin id도 돌려쓰기 때문에 누가 그런 것인지 찾기 힘들다.
    3. 하지만 쿠버네티스에서는 yaml 파일로 관리하고 작업 이력 남기기에 추적 가능하고 확실해진다.
  5. 환경별로 배포 파일 나눠 만들 수 있다.
    1. 사전에 작업해야하는 dependency 없이 미리 환경 구성해 놓을 수 있다.
      1. 보통 개발 → 검증 → 운영 순으로 인프라를 구성한다.
      2. 실제 장비가 들어오고 네트워크 설정이나 보안 등 사전 작업이 다 끝나야 내가 들어가 환경을 설정할 수 있다.
      3. 그래서 보통 운영 환경을 구성할 때쯤에 운영 환경 구성, 기존의 개발, 검증 환경에서 나오는 이슈 처리 등 바쁘다.
      4. 그런데 이렇게 파일로 관리하면 사전에 작업해야 하는 dependency 없이 미리 구성해 놓을 수 있다.
    2. 인프라 환경들을 코드들로 만들어 추후에 또 만들 때 복사해 만든다.
      1. 기존 vm 환경에서는 세팅할 내용이 많으면 하나씩 빼먹기도 한다.
      2. 또 서버 수마다 반복해야 하는 작업이라 반복 작업이다.
      3. 쿠버네티스는 파일을 복사해서 코드만 수정하면 된다.
      4. 앱이 늘어나도 인프라 설치 일정이 더 걸리지 않고 설정이 누락되지도 않는다.
      5. 단순 반복 작업이 줄어들고 인프라 환경의 질을 높일까를 고민할 수 있다.
      6. 다른 프로젝트에 가도 경험만 가지고 가는 것이 아니라 실제 경험 녹아있는 코드도 들고가니 다음 프로젝트는 더 쉬워진다.

 

정리

이렇듯 많은 이유로 쿠버네티스를 사용하면 굉장히 편해진다.

다시 한번 쿠버네티스가 왜 편한지 정리해보자.

 

  1. 쿠버네티스 기반 it 생태계가 매우 커지고 쿠버네티스가 굉장히 빠르게 확산되고 있다.
  2. 쿠버네티스에 표준 아키텍쳐가 있고 모두가 이것을 지켜 만들었기 때문에 쿠버네티스 표준으로 IT 인프라 구축이 편해진다.
  3. 쿠버네티스의 4가지 대표 기능들로 서비스 운영을 할 때에 굉장히 편하게 사용할 수 있다.
  4. 쿠버네티스로 시스템 오픈 날, 부하가 커질 때 적은 인력으로 간단하게 서비스 안정화 할 수 있다.
  5. 쿠버네티스로 인프라 환경을 코드화 해서 쉽고 편하게 관리할 수 있다.

 

출처

https://inf.run/k7mF

 

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런

일프로 | , ✅ 광범위한 쿠버네티스 기술을 A~Z까지 넓고 얇게 훑기보다 하나의 개념을 배우더라도 왜 사용하는지 부터 실무에서 어떻게 사용되는지 까지를 다루는 강의✅ 시작은 초급자지만강

www.inflearn.com