본문으로 건너뛰기

Pod·컨테이너 관리

서비스가 배포되면 워크로드를 직접 관리해야 할 때가 있습니다. 문제가 발생한 Pod/컨테이너를 재시작하거나, 트래픽 증가에 대응하여 스케일을 조정하는 등의 작업이 필요합니다.

런타임에 따라 화면과 용어가 다릅니다

이 기능은 런타임 종류에 따라 탭 이름과 제공 기능이 다릅니다. 본인의 런타임에 해당하는 섹션을 참고하세요.

  • Kubernetes: 운영 모달의 [파드 목록] 탭. 스케일링·HPA·일괄 삭제 지원.
  • Docker · Podman: 운영 모달의 [컨테이너 목록] 탭. 재시작만 지원(스케일링·HPA 없음).

운영 탭 - 파드 목록 (Kubernetes)

왜 Container 관리가 중요할까요?

Container는 애플리케이션이 실행되는 "집"입니다. 집에 문제가 생기면 거주자(애플리케이션)도 영향을 받습니다. Container를 잘 관리하면 서비스 안정성을 높일 수 있습니다.

기능 개요​

Kubernetes와 Docker/Podman에서 사용할 수 있는 기능이 다릅니다.

  • 목록 조회: Kubernetes에서는 Pod 목록을, Docker/Podman에서는 Container 목록을 확인합니다.
  • 상태 확인: Kubernetes는 Running/Pending/Failed 등으로 표시되며 UI에서는 running만 강조 색상으로 표시됩니다. Docker/Podman은 up/exited 등으로 표시됩니다.
  • 재시작: Kubernetes에서는 Pod 삭제로 재시작 효과를 얻습니다(Deployment가 새 Pod 생성). Docker/Podman에서는 "재시작" 액션만 제공합니다.
  • 시작/중지: 운영 모달의 컨테이너 목록 탭에는 Start/Stop/Remove 액션이 없습니다.
  • 스케일링: Kubernetes에서는 Deployment 레플리카를 조절합니다(Pod 개수 적용 / 모든 Pod 제거). Docker/Podman에서는 지원하지 않습니다.
  • 자동 스케일링: Kubernetes에서는 HPA(CPU 기반)를 사용합니다. Docker/Podman에서는 지원하지 않습니다.
  • 연결 방식: 운영 모달 상단의 연결 방식 표시 옆 접속 방식 변경 버튼으로 VPN/SSH 직접/자동 연결을 선택할 수 있습니다.
Kubernetes의 특별한 점

Kubernetes에서는 Pod를 삭제해도 Deployment가 자동으로 새 Pod를 생성합니다. 이것이 "자가 치유(Self-healing)" 기능입니다.

Kubernetes Pod 관리​

Pod 목록 조회​

  1. Operate → 파드 목록 탭
  2. 현재 배포된 Pod 목록 확인

Pod 정보 테이블​

실제 컬럼은 다음과 같습니다.

  • 상태: Running, Pending, Failed 등
  • Pod 이름: Deployment-XXXXX-XXXXX 형식
  • CPU: CPU 사용량 (Metrics Server 필요)
  • 메모리: 메모리 사용량 (Metrics Server 필요)
  • 이미지: 현재 사용 중인 컨테이너 이미지
  • 작업: 재시작 등 액션 버튼

"생성 시간"과 "재시작 횟수" 컬럼은 표시되지 않습니다.

Pod 상태 이해​

UI에서는 running 상태는 파란색, pending 상태는 주황색, failed/error 상태는 빨간색, 그 외 상태는 회색으로 표시됩니다.

  • Running: 정상 실행 중입니다.
  • Pending: 스케줄링 대기 상태입니다. 일반적으로 리소스 부족이나 이미지 풀링 중일 때 발생합니다.
  • Failed: 실행이 실패했습니다.
  • CrashLoopBackOff: 반복적으로 실패하고 있습니다.
  • ImagePullBackOff: 이미지 풀이 실패했습니다.
  • Terminating: 종료 중입니다. 별도 색상 매핑이 없으므로 다른 미지정 상태와 동일하게 회색으로 표시됩니다.

Pod 상세 expand 영역​

expand 아이콘(원인 보기)은 Pending 상태의 Pod에서만 표시되며, 이 행을 펼치면 다음 정보를 확인할 수 있습니다.

  • 원인 분석: Pending 상태의 가능한 원인(리소스 부족, nodeSelector/affinity, PVC 바인딩, Taints/Tolerations 등)을 안내합니다.
  • 이벤트: Pod 관련 K8s 이벤트 목록
  • 강제 삭제: 일반 삭제로 종료되지 않는 Pending Pod에 대한 강제 삭제 버튼

ImagePullBackOff, CrashLoopBackOff, Error 등 그 외 상태의 Pod는 행을 펼칠 수 없습니다. 해당 상태의 원인은 로그와 이벤트로 확인합니다. 별도의 "로그 보기"/"상세 정보" 액션은 제공되지 않으며, 로그는 로그 조회 탭에서 확인합니다.

Pod 액션​

행의 작업 영역에서는 재시작 액션만 제공됩니다. Pod 삭제 방식으로 동작하며, Deployment가 자동으로 새 Pod를 생성합니다.

Pod 재시작 == Pod 삭제

Kubernetes에서 Deployment로 관리되는 Pod를 삭제하면, Deployment가 자동으로 새 Pod를 생성합니다.

Pending Pod 일괄 삭제​

Pending 상태의 Pod가 있고 K8s 재시작 권한이 있을 때에만 Pending Pod 일괄 삭제 버튼이 노출됩니다.

  1. 버튼을 클릭합니다.
  2. 확인 다이얼로그에서 승인합니다.
  3. Pending 상태의 모든 Pod가 삭제됩니다.

스케일링 (Kubernetes)​

수동 스케일​

  1. 파드 목록 탭에서 Deployment를 선택합니다.

  2. Pod 개수를 입력합니다.

  3. 두 가지 액션 중 하나를 수행합니다.

    • Pod 개수 적용: 입력한 개수로 replicas를 설정합니다.
    • 모든 Pod 제거: replicas를 0으로 설정해 모든 Pod를 제거합니다.

HPA가 활성화되어 있는 동안에는 수동 스케일링이 잠겨 있습니다. 백엔드에서도 kubectl scale 호출이 차단됩니다.

HPA (Horizontal Pod Autoscaler)​

HPA는 CPU 사용량에 따라 Pod 수를 자동으로 조절하는 기능입니다.

왜 HPA를 사용해야 할까요?

수동 스케일링은 시간이 걸리고 실수할 수 있습니다. HPA를 설정하면 자동으로 트래픽에 대응할 수 있습니다.

HPA 생성​

  1. 파드 목록 탭의 HPA 섹션으로 이동합니다.
  2. HPA 생성 버튼을 클릭합니다.
  3. 아래 설정을 입력합니다.

HPA 설정 항목:

  • minReplicas (기본값 1, 권장 2): 항상 유지할 최소 Pod 수입니다.
  • maxReplicas (기본값 10): 확장 가능한 최대 Pod 수입니다.
  • targetCPU(%) (기본값 80): 이 사용률을 초과하면 Pod가 추가됩니다.
  1. 생성 버튼을 클릭합니다.

실제 KIOPS의 HPA는 CPU 기반 자동 스케일링만 지원하며, 내부적으로 kubectl autoscale --cpu-percent 명령으로 생성됩니다. 이미 HPA가 존재하는 경우 기존 HPA를 삭제하고 재생성합니다. 메모리 기반 자동 스케일링, 다중 메트릭, 커스텀 메트릭, 스케일 안정화 윈도우, 스케일링 정책은 지원하지 않습니다.

Metrics Server 필요

HPA를 사용하려면 클러스터에 Metrics Server가 설치되어 있어야 합니다. 메트릭 서버 설치 가이드를 참고하세요.

HPA 동작 원리 (CPU 기반)​

현재 CPU 85% → 목표 80%
→ 레플리카 증가 필요
→ 자동 Scale Up
→ CPU 부하 분산

HPA 카드 정보​

HPA가 생성되면 카드 형태로 다음 정보가 표시됩니다.

  • HPA 이름
  • 대상 Deployment
  • 최소/최대 Pod
  • 목표 CPU(%)
  • 현재 실행 Pod 개수
  • 삭제 버튼

삭제 버튼을 누르면 HPA가 제거되고 수동 스케일링으로 다시 전환됩니다.

Metrics Server​

Metrics Server 필요

HPA와 리소스 모니터링을 위해 Metrics Server가 필요합니다.

Metrics Server 상태 확인​

파드 목록 탭의 Metrics Server 상태 섹션에서 현재 상태를 확인할 수 있습니다.

  • 정상 동작 / 설치 중 / 미설치 / 오류 상태를 표시합니다.
  • 이벤트 및 Pod 로그를 통한 진단 도구가 제공됩니다.

Metrics Server 설치/재설치 및 이미지 캐시 정리​

  • 설치 / 재설치: 미설치 상태이거나 비정상 동작 중인 경우 버튼이 노출됩니다.
  • 이미지 캐시 정리: 이미지 풀 실패가 의심되는 경우 캐시를 정리할 수 있습니다.

Docker · Podman 컨테이너 관리​

Docker와 Podman은 운영 화면과 기능이 동일하게 동작합니다.

컨테이너 목록 조회​

  1. Operate → 컨테이너 목록 탭
  2. 현재 컨테이너 목록 확인

컨테이너 정보 테이블​

실제 컬럼은 다음과 같습니다.

  • ID
  • 이름
  • 이미지
  • 상태
  • CPU
  • 메모리
  • 네트워크
  • 포트
  • 작업: 재시작 액션

"생성 시간" 컬럼은 표시되지 않습니다.

자동 갱신 및 통계​

  • 자동 갱신 토글: 활성화하면 30초 간격으로 컨테이너 목록과 통계가 갱신됩니다.
  • 통계 버튼: CPU/메모리/네트워크 사용량을 확인할 수 있습니다.

컨테이너 제어​

운영 모달의 컨테이너 목록 탭에서 제공되는 액션은 재시작 하나입니다. Start/Stop/Remove 버튼은 제공되지 않습니다.

  1. 재시작할 컨테이너 행에서 액션 버튼 클릭
  2. 확인 다이얼로그 승인
  3. 작업 완료 확인
추가 제어가 필요한 경우

세부 제어(Start/Stop/Remove, 이미지 변경 등)는 명령 실행 탭에서 docker/podman 명령을 사용하거나, 배포 관리 탭에서 재배포를 수행하세요.

실제 사용 시나리오​

실제 상황에서 어떻게 Container를 관리하는지 알아보겠습니다.

시나리오 1: 트래픽 급증 대응 (K8s)​

갑자기 사용자가 몰려서 서버가 느려졌을 때의 대응 방법입니다.

  1. 파드 목록 탭에서 현재 상태를 확인합니다.
  2. CPU 사용량이 높으면 스케일링이 필요합니다.
  3. Pod 개수를 3 → 5로 입력하고 Pod 개수 적용을 클릭합니다.
  4. 새 Pod가 생성되는 것을 확인합니다.
  5. 부하가 분산되어 응답 속도가 개선됩니다.
미리 대비하세요

트래픽 급증이 예상되는 이벤트 전에 미리 Pod 개수를 늘려두는 것이 좋습니다.

시나리오 2: HPA로 자동화하기​

수동 스케일링이 번거롭다면 HPA를 설정하세요.

  1. 수동 스케일링이 자주 필요한 서비스를 확인합니다.
  2. HPA 생성 버튼을 클릭합니다.
  3. minReplicas 2, maxReplicas 10, targetCPU 70%를 설정합니다.
  4. 생성을 완료합니다.
  5. 이후 CPU 사용률에 따라 자동으로 스케일링됩니다.

시나리오 3: 문제 있는 Pod 재시작​

Pod가 계속 재시작되는 CrashLoopBackOff 상태를 해결하는 방법입니다.

  1. CrashLoopBackOff 상태의 Pod를 발견합니다.
  2. 로그 조회 탭에서 문제 원인을 파악합니다.
  3. 파드 목록의 expand 행에서 에러 타입별 분석과 이벤트를 함께 확인합니다.
  4. 문제를 수정합니다 (설정, 코드 등)
  5. Pod를 재시작(삭제)합니다. 일반 삭제로 종료되지 않으면 강제 삭제를 사용합니다.
  6. 새 Pod가 정상 Running 상태인지 확인합니다.

문제 해결​

Kubernetes​

  • Pod가 Pending 지속: 리소스 부족입니다. 노드 추가 또는 리소스 요청을 감소하세요.
  • Scale이 안됨: Deployment가 없거나 HPA가 활성화되어 잠겨 있습니다. HPA 활성화 여부와 Deployment 상태를 확인하세요.
  • HPA가 동작 안함: Metrics Server가 없습니다. Metrics Server를 설치하세요.

Docker · Podman​

  • 재시작 실패: 포트 충돌 또는 볼륨 문제일 수 있습니다. 로그 조회 또는 명령 실행으로 원인을 확인하세요.
  • 연결 안됨: 서버에 접근할 수 없습니다. 운영 모달 상단의 연결 방식 표시 옆 접속 방식 변경 버튼(VPN/SSH 직접/자동)을 확인하세요.

관련 가이드​