컨테이너 인프라 환경

컨테이너를 운영한다는 것은 이미지를 만들어 실행하는 것에서 끝나지 않는다. 실행할 장소를 정하고, 새 버전을 배포하고, 장애를 발견해 복구하는 과정까지 필요하다. 메모에 적어 둔 도구들은 이 과정의 서로 다른 단계를 맡는다.

flowchart LR
    A[소스 코드] --> B[Jenkins 등 CI: 빌드·테스트]
    B --> C[컨테이너 이미지와 레지스트리]
    C --> D[Kubernetes: 배포·실행 상태 관리]
    D --> E[컨테이너 런타임: 실제 실행]
    D --> F[Prometheus: 지표 수집]
    F --> G[Grafana: 대시보드]

이 그림에서 빌드 도구가 컨테이너를 직접 계속 관리하는 것은 아니다. 배포된 애플리케이션의 원하는 상태를 유지하는 일은 오케스트레이터가 맡고, 수집된 지표를 사람이 살피는 데는 별도의 모니터링 도구가 쓰인다.

도구별 역할

도커(Docker): 이미지를 만들고 로컬에서 컨테이너를 실행·관리하는 도구다. 이미지에 애플리케이션과 의존성을 묶으면 환경 차이를 줄일 수 있다. 다만 호스트 커널과 CPU 아키텍처 등의 차이까지 사라지는 것은 아니다. Kubernetes 노드에서는 Docker 자체가 필수 조건이 아니라 호환되는 컨테이너 런타임이 필요하다. Kubernetes 구성 요소 문서에서 런타임의 위치를 볼 수 있다.
쿠버네티스(Kubernetes): 여러 노드에 컨테이너화된 작업을 배치하고 원하는 복제 수를 유지한다. Deployment로 버전을 갱신하고 Service로 Pod에 접근할 수 있게 한다. 장애 시 다시 실행할 수 있지만 애플리케이션 내부 오류를 자동으로 해결한다는 뜻은 아니다.
젠킨스(Jenkins): CI/CD 파이프라인을 구성할 때 쓰는 자동화 서버다. 예를 들어 코드 변경 → 테스트 → 이미지 빌드 → 배포 승인 과정을 정의할 수 있다. 배포 권한과 비밀 값은 파이프라인에 직접 적지 않고 적절한 자격 증명 관리 기능으로 다룬다.
프로메테우스(Prometheus)와 그라파나(Grafana): Prometheus는 시계열 지표를 수집·질의하고, Grafana는 지표를 대시보드로 보여준다. 지표가 수집된다는 사실만으로 장애를 알 수 있는 것은 아니므로, 중요한 실패율·지연 시간 등에 경보 기준을 정해야 한다.

한 서비스가 배포되는 과정

웹 서버를 예로 들면, 개발자는 코드를 바꾸고 CI가 테스트를 수행한다. 통과한 버전의 이미지를 레지스트리에 올리고, 배포 설정에서 그 이미지 버전을 지정한다. 쿠버네티스는 새 Pod를 실행하고 상태를 확인하면서 이전 Pod를 교체한다. 이후 요청 오류율이나 지연 시간이 올라가는지 모니터링한다.

단계	확인할 질문
빌드	테스트를 통과한 코드로 이미지를 만들었는가?
배포	배포한 이미지 버전과 원하는 복제 수가 명시되어 있는가?
실행	Pod가 준비 상태인가, 요청을 처리하는가?
관찰	실패율·지연 시간·자원 사용량에 이상이 없는가?

이렇게 나누어 보면 “컨테이너가 실행 중이다”와 “서비스가 정상이다”가 다른 판단이라는 점이 보인다. 장애가 나면 먼저 빌드 산출물, 배포 상태, 애플리케이션 지표 중 어느 단계에서 문제가 시작됐는지 좁혀 간다.

배포 파이프라인에 필요한 경계

CI가 만든 이미지에 latest만 붙여 배포하면 나중에 어떤 코드가 실행됐는지 추적하기 어렵다. 테스트한 커밋과 이미지 다이제스트를 연결해 저장하고, 배포 설정에는 검증된 버전을 사용한다. 이미지 빌드 성공과 서비스 정상은 서로 다른 사건이다. 레지스트리에 푸시한 뒤 새 Deployment가 준비되고 실제 HTTP 요청이 통과하는지까지 확인해야 한다.

flowchart LR
  C[커밋] --> T[단위·통합 테스트]
  T --> B[이미지 빌드와 검사]
  B --> R[레지스트리 게시]
  R --> K[Kubernetes 배포]
  K --> P[준비 상태·서비스 요청 확인]
  P --> M[오류율·지연·자원 관찰]

예를 들어 web:1.4.0을 배포한 직후 Pod 세 개 중 한 개만 준비됐다면, 빌드 단계가 아니라 실행 준비 단계에서 막힌 것이다. kubectl rollout status deployment/web과 kubectl describe pod로 이미지 다운로드, 설정, probe 실패를 확인한다. 새 버전의 오류율만 높아졌다면 애플리케이션 로그와 의존 서비스 지표를 함께 본다. 필요하면 이전에 검증한 이미지로 롤백한다. 롤백을 할 수 있으려면 이전 이미지가 레지스트리에 남아 있고 설정·데이터 스키마가 역호환 가능한지도 고려해야 한다.

실패 위치	확인할 증거	대표 조치
CI 테스트	테스트 로그·실패 커밋	코드 또는 테스트 환경 수정
이미지 빌드	빌드 로그·베이스 이미지	의존성, 플랫폼, Dockerfile 확인
Pod 생성	이벤트·이미지 pull 결과	레지스트리 인증, 리소스 할당 확인
준비 상태	probe 결과·애플리케이션 로그	시작 시간, 포트, 의존 서비스 확인
운영 품질	요청 실패율·지연·포화 지표	문제 버전 롤백 또는 용량·코드 수정

Prometheus의 지표만으로 사용자에게 나타난 증상을 모두 알 수는 없다. 요청 경로를 연결하려면 애플리케이션 로그와 분산 추적도 함께 설계할 수 있다. Grafana 대시보드는 관측된 값의 해석 도구이고, 장애를 조기에 알아채려면 목표 서비스 수준과 연결된 경보 규칙이 필요하다. 스케일 아웃도 자동 만능 해결책이 아니다. 데이터베이스가 병목이라면 웹 Pod만 늘려 오히려 연결을 더 많이 만들 수 있다.

참고: Kubernetes Deployment, Pod 디버깅, Prometheus 개요, Grafana 문서.