infra

로컬 쿠버네티스 실습 ②: ConfigMap과 리소스 설정으로 운영 구조 만들기

mirabo01 2026. 2. 14. 09:56

로컬 쿠버네티스 실습 ② 운영에 가까운 형태로 확장해보기

지난 글에서는
Deployment와 Service만으로 가장 기본적인 배포 흐름을 따라가봤다.
이번에는 그 구조를 조금만 확장해서,
운영 환경에서 실제로 쓰이는 형태에 더 가깝게 만들어본다.

이번 실습의 핵심은 다음 세 가지다.

  • 설정을 이미지에서 분리한다
  • 리소스 사용 범위를 명확히 한다
  • 배포가 어떻게 교체되는지 직접 확인한다

이번 실습에서 추가할 요소들

이전 실습 대비 추가되는 요소는 다음이다.

  • ConfigMap으로 설정 분리
  • requests / limits 설정
  • 롤링 업데이트 과정 확인

여전히 예제 애플리케이션은 단순하지만,
쿠버네티스를 쓰는 이유가 드러나는 지점을 직접 확인하는 게 목표다.

1. 설정을 이미지에서 분리해야 하는 이유

이전 실습에서는
애플리케이션 설정이 이미지 안에 있다고 가정했다.

하지만 운영 환경에서는 다음 문제가 생긴다.

  • 환경(dev/prod)마다 이미지 재빌드 필요
  • 설정 하나 바꾸려면 배포 전체 재수행
  • 설정 변경 이력 관리가 어렵다

그래서 쿠버네티스에서는
설정은 ConfigMap으로 분리하는 것이 기본 패턴이다.

2. ConfigMap 추가하기

ConfigMap에는 보통 이런 값들이 들어간다.

  • 서버 포트
  • 환경 이름
  • 기능 플래그
  • 외부 API 주소

이제 Deployment에서는
이미지 자체가 아니라 외부 설정을 참조하게 된다.

실제로 써보면 이 시점부터
“아, 이미지와 설정이 분리됐구나”라는 느낌이 든다.

3. ConfigMap 변경 후 무엇이 달라질까

중요한 포인트가 하나 있다.

  • ConfigMap을 수정해도
  • 이미 실행 중인 Pod에는 자동 반영되지 않는 경우가 많다

그래서 보통은 다음 중 하나를 선택한다.

  • Pod 재시작
  • Deployment 재배포

이 동작을 직접 해보면,
“왜 설정 변경 시 재배포가 필요한지”가 자연스럽게 이해된다.

4. requests와 limits 추가하기

이제 리소스 설정을 추가해본다.

이전 실습에서는
Pod가 얼마나 리소스를 써도 되는지 정의하지 않았다.

운영 환경에서는 이 상태가 가장 위험하다.

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

이 설정 하나로 다음이 명확해진다.

  • 최소 보장 리소스
  • 최대 사용 가능 범위
  • 스케줄링 기준

실제로 적용해보면
Pod가 배치되는 Node가 달라질 수도 있다.

5. 리소스 설정 후 확인해볼 것들

설정 후에는 꼭 다음을 확인해본다.

kubectl describe pod <pod-name>

여기서 확인할 포인트는 다음이다.

  • requests / limits 값이 제대로 반영됐는지
  • OOMKilled 같은 이벤트가 발생하지 않는지

이 과정을 통해
“리소스 설정은 선언이지 희망사항이 아니다”라는 걸 체감하게 된다.

6. 이미지 버전 변경으로 롤링 업데이트 체험하기

이제 Deployment의 이미지 태그를 변경해본다.

이 작업 하나로
쿠버네티스는 자동으로 다음을 수행한다.

  • 기존 Pod를 하나씩 종료
  • 새 이미지로 Pod 생성
  • 지정된 전략에 따라 교체

중요한 건,
이 과정에서 Service는 계속 살아 있다는 점이다.

7. 롤링 업데이트 중에 확인하면 좋은 것들

업데이트 중에는 다음을 함께 보면 좋다.

kubectl get pod -w
  • Pod가 하나씩 교체되는지
  • 동시에 모두 내려가지는 않는지
  • 새 Pod가 정상 상태가 된 후 기존 Pod가 내려가는지

이 장면을 직접 보면,
무중단 배포라는 말이 추상적이지 않게 느껴진다.

8. 문제가 생기면 어떻게 될까

만약 새 이미지에 문제가 있다면,

  • 새 Pod가 정상 상태가 되지 못하고
  • 이전 Pod가 계속 유지되거나
  • 롤백이 필요해진다

이 흐름을 이해하고 있으면,
실제 운영에서 배포가 멈췄을 때도
당황하지 않고 상황을 해석할 수 있다.

실제로 해보면 느끼는 변화

이번 실습까지 해보면
이전과 비교해 인식이 달라진다.

  • 단순 실행 → 운영 구조
  • 컨테이너 실행 → 상태 관리
  • 배포 → 교체 전략

쿠버네티스가 왜 복잡해 보이는지,
그리고 왜 그 복잡함이 필요한지도 함께 보이기 시작한다.

정리하며

이번 글에서는
이전 실습을 기반으로 운영에 가까운 형태로 구조를 확장해봤다.

  • ConfigMap으로 설정 분리
  • requests / limits로 리소스 통제
  • Deployment의 롤링 업데이트 체험

이 단계까지 직접 해봤다면,
쿠버네티스의 기본적인 사용 흐름은
“알고 있다”가 아니라 “써봤다”에 가까워진다.

다음 글에서는
이 실습 환경에 Ingress를 추가해서 외부 접근 구조를 만들고,
도메인 기반 라우팅 흐름을 한 번 더 정리해볼 예정이다.