Container Management는 컨테이너 기반 애플리케이션을 효율적으로 배포·운영·스케일링·모니터링·종료하는 전반적인 활동을 의미합니다. 역량향상을 위해 단순 컨테이너 실행을 넘어서 전체 Lifecycle 관리와 운영 자동화, 보안 통제, 리소스 최적화 등을 포괄합니다.
🔷 1. 컨테이너(Container) 개요
- 컨테이너란?
- 애플리케이션과 그 실행 환경(Library, Config, Dependency 등)을 패키징한 실행 단위
- 프로세스 단위로 격리됨 (OS 공유)
- 빠른 시작, 작은 사이즈, 이식성 강조
- 예시: Docker, Containerd, Podman
- 이미지 vs 컨테이너
- 이미지(Image): 불변의 템플릿, 컨테이너 실행 단위
- 컨테이너(Container): 이미지 기반으로 실제 실행 중인 인스턴스
🔷 2. Container Management 주요 구성요소
| 이미지 관리 | 버전, 용량, 캐시, 저장소(Registry: ACR, DockerHub 등) |
| 컨테이너 실행/중지 | 컨테이너 시작, 중단, 재시작, 로그확인 등 |
| 오케스트레이션 | Kubernetes, Docker Swarm 등 |
| 모니터링 | 로그 수집, 리소스 사용량, 헬스 체크 |
| 보안 | 이미지 서명, 취약점 스캔, 네트워크 격리, Policy 적용 |
| 네트워크 | 컨테이너 간 통신(CNI), 외부 노출(Ingress, LoadBalancer 등) |
| 스토리지 | 영속 볼륨 (Volume, PV/PVC, NFS, Ceph 등) |
🔷 3. 오케스트레이션 도구 (Kubernetes 중심)
✅ Kubernetes가 대표적
- 자동 복구 (Self-healing): 컨테이너 장애 시 자동 재시작
- 수평 스케일링: 리소스/트래픽에 따라 Pod 수 자동 조절
- 롤링 업데이트/롤백
- 서비스 디스커버리 및 로드밸런싱
- 네임스페이스 기반 멀티 테넌시
- Helm / Kustomize: 배포 자동화 템플릿
🔷 4. 실무 관점의 Container Management 포인트 (TA 관점)
| 리소스 최적화 | CPU/MEM Request/Limits 설정, HPA 적용 |
| 배포 자동화 | GitOps, CI/CD, ArgoCD |
| 보안 강화 | PodSecurityPolicy, NetworkPolicy, Runtime 보안(e.g. Falco) |
| 모니터링 및 로깅 | Prometheus+Grafana, ELK/EFK Stack |
| 장애 대응 시나리오 | Pod CrashLoop, ImagePullBackOff, OOMKilled 분석 등 |
| 멀티 클러스터 운영 | 클러스터 페더레이션, Cluster API |
| 온프레미스 ↔ 클라우드 연동 | 하이브리드 운영 (예: Azure Arc, Anthos) |
🔷 5. Container Lifecycle
🔷 6. 관련 도구와 기술
- 런타임: Docker, containerd, CRI-O
- Registry: DockerHub, Harbor, Azure Container Registry (ACR)
- CI/CD: GitHub Actions, GitLab, Jenkins, ArgoCD
- 보안: Trivy, Clair, Prisma Cloud, Falco
- 네트워크: Calico, Cilium (eBPF 기반)
- 스토리지: CSI, Ceph, Longhorn, NFS
🔷 7. 요약 암기카드 (한 줄 키워드)
- 컨테이너는 경량 실행환경 (VM과 다름)
- 관리 핵심은 Lifecycle + 자동화
- Kubernetes = 오케스트레이션의 표준
- 이미지 → 컨테이너 → 배포 → 모니터링 → 종료
- CI/CD + GitOps + Helm = 자동화 필수
- 보안은 Image Scanning + 네트워크 격리 + 정책제어
- HPA/VPA, Node Affinity, Toleration = 리소스 운영기술
- 장애 분석 시 Pod 상태 (kubectl describe, logs) 중요
추가 요청 가능:
- ✅ [ ] TA 시험 대비 문제집 (객관식/시나리오 기반)
- ✅ [ ] Azure ACR + AKS 기반 실무 설계
- ✅ [ ] Kubernetes 네트워크 or 스토리지 중심 실무 시나리오
- ✅ [ ] GitOps 기반 Container 관리 전략 (ArgoCD, Flux 등)
🧠 [Container Management – 20문항]
(난이도: 상/중/하 표기)
✅ NO.01 (객관식 · 난이도: 하)
컨테이너에 대한 설명으로 옳은 것은?
① VM과 달리 각 컨테이너는 독립된 커널을 사용한다.
② 컨테이너는 완전한 가상화로, 하이퍼바이저 기반으로 동작한다.
③ 컨테이너는 Host OS의 커널을 공유하며, 프로세스 수준에서 격리된다.
④ 컨테이너는 별도 운영체제를 포함하므로 부팅 시간이 오래 걸린다.
정답: ③
해설:
컨테이너는 VM과 달리 Host의 커널을 공유하며 프로세스 단위로 격리되어 경량화된 실행 환경을 제공합니다.
✅ NO.02 (객관식 · 난이도: 중)
다음 중 Kubernetes에서 컨테이너 이미지 배포와 관련된 구성요소는?
① ConfigMap
② Deployment
③ HPA
④ NodePort
정답: ②
해설:
Deployment는 애플리케이션의 선언적 배포를 담당하며, 이미지 버전 관리, 롤링 업데이트 등 기능을 포함합니다.
✅ NO.03 (객관식 · 난이도: 상)
다음 중 Kubernetes에서 컨테이너 장애 복구를 자동으로 수행하는 기능은?
① Liveness Probe
② Horizontal Pod Autoscaler
③ ReplicaSet
④ DaemonSet
정답: ①
해설:
Liveness Probe는 애플리케이션의 상태를 주기적으로 확인해 실패 시 컨테이너를 재시작합니다.
✅ NO.04 (시나리오 · 난이도: 중)
시나리오:
운영 중인 Kubernetes 클러스터에서 특정 애플리케이션의 메모리 사용량이 점점 증가하여 OOMKilled가 발생했다.
Q: 해결을 위한 가장 우선적인 조치는?
① Pod의 수를 늘려 트래픽 분산을 시도한다.
② Resource limits를 제거해 더 많은 메모리를 할당한다.
③ Pod의 메모리 limits 값을 점검하고, 적절히 조정한다.
④ 컨테이너의 로그를 삭제한다.
정답: ③
해설:
메모리 부족(OOMKilled)은 컨테이너에 설정된 limits 값을 초과할 때 발생하므로, 이를 적절히 재조정해야 합니다.
✅ NO.05 (객관식 · 난이도: 중)
컨테이너 이미지 보안 취약점 스캔 도구로 적절한 것은?
① Prometheus
② Trivy
③ Fluentd
④ Istio
정답: ②
해설:
Trivy는 이미지 및 Git 리포지토리의 취약점을 스캔하는 대표적인 보안 도구입니다.
✅ NO.06 (시나리오 · 난이도: 상)
시나리오:
당신의 팀은 Dev 환경에서 Kubernetes에 blue-green deployment 전략을 도입하고자 한다.
Q: 이 전략의 주요 목적은?
① Pod에 부하를 분산시켜 리소스를 효율화
② 업데이트 시 무중단 배포 및 롤백의 용이성 확보
③ 서비스 포트를 자동으로 할당
④ 서비스 간의 DNS 해석 지연을 줄임
정답: ②
해설:
Blue-Green Deployment는 기존 버전과 신규 버전을 동시에 유지하다가 트래픽을 전환함으로써 무중단 배포를 가능하게 합니다.
✅ NO.07 (객관식 · 난이도: 하)
다음 중 Kubernetes에서 영속 데이터를 저장하기 위한 구성 요소는?
① Pod
② Service
③ PersistentVolume
④ ConfigMap
정답: ③
해설:
PersistentVolume(PV)는 컨테이너가 종료되더라도 유지되는 스토리지 볼륨입니다.
✅ NO.08 (객관식 · 난이도: 중)
Kubernetes 네트워크 정책(NetworkPolicy)의 목적은?
① Pod 간의 통신 속도 향상
② 특정 Pod 간 통신 제어 및 격리
③ 클러스터 IP 자동 할당
④ 노드 간 트래픽 암호화
정답: ②
해설:
NetworkPolicy는 Pod 간 네트워크 접근을 제어하여 보안을 강화합니다.
✅ NO.09 (시나리오 · 난이도: 상)
시나리오:
컨테이너가 외부 API 호출 시 간헐적으로 Connection Refused 에러가 발생한다.
Q: 가장 먼저 확인해야 할 사항은?
① 컨테이너의 DNS 캐시 초기화 여부
② 외부 API 서버의 인증서 유효성
③ 컨테이너의 네트워크 정책 및 egress 설정
④ 이미지 레이어의 용량 초과 여부
정답: ③
해설:
NetworkPolicy의 egress 제한 설정으로 인해 외부 통신이 차단될 수 있습니다.
✅ NO.10 (객관식 · 난이도: 중)
컨테이너 기반 DevOps에서 GitOps 도구로 적합한 것은?
① ArgoCD
② Jenkins
③ Terraform
④ Prometheus
정답: ①
해설:
ArgoCD는 Git 저장소 상태를 기준으로 Kubernetes 상태를 자동 동기화하는 GitOps 도구입니다.
(계속됩니다...)
👉 다음 메시지에 11~20번 문제 + 요약/정리 + PDF 변환 안내 포함해드릴게요.
계속 진행할까요?
✅ NO.11 (객관식 · 난이도: 하)
컨테이너 런타임 중 Kubernetes에서 기본적으로 사용하는 런타임은?
① Docker
② Podman
③ containerd
④ runc
정답: ③
해설:
Kubernetes는 v1.20 이후 Docker 대신 containerd 또는 CRI-O를 기본 런타임으로 사용합니다.
✅ NO.12 (객관식 · 난이도: 중)
Kubernetes의 Init Container에 대한 설명으로 올바른 것은?
① 메인 컨테이너와 동시에 실행된다.
② Init 컨테이너 실패 시 메인 컨테이너가 자동 시작된다.
③ Init 컨테이너는 완료되어야 메인 컨테이너가 시작된다.
④ Init 컨테이너는 Kubernetes 1.20부터 제거되었다.
정답: ③
해설:
Init Container는 메인 컨테이너가 시작되기 전에 실행되며, 준비 작업을 수행하는 데 사용됩니다.
✅ NO.13 (시나리오 · 난이도: 중)
시나리오:
컨테이너에 설정된 readOnlyRootFilesystem: true로 인해 애플리케이션이 로그를 쓰지 못해 장애가 발생했다.
Q: 이 문제 해결을 위한 조치는?
① root 파일 시스템을 RW로 변경하지 않고, /tmp 디렉토리에 로그를 기록하도록 수정한다.
② readOnlyRootFilesystem을 false로 바꾼다.
③ 로그 기능을 제거한다.
④ init 컨테이너를 사용해 log 폴더를 먼저 생성한다.
정답: ①
해설:
보안 강화를 유지하면서도 /tmp, emptyDir 등 쓰기 가능한 마운트를 제공하는 것이 최선의 조치입니다.
✅ NO.14 (객관식 · 난이도: 중)
Kubernetes의 ConfigMap과 Secret의 주요 차이점은?
① ConfigMap은 TLS를 지원하고 Secret은 그렇지 않다.
② Secret은 base64 인코딩으로 민감 정보를 저장한다.
③ ConfigMap은 PersistentVolume에 저장된다.
④ Secret은 Pod 간 공유할 수 없다.
정답: ②
해설:
Secret은 암호, 인증키 등의 민감정보를 base64 인코딩하여 저장하며, ConfigMap은 일반 설정 정보를 저장합니다.
✅ NO.15 (시나리오 · 난이도: 상)
시나리오:
Production 환경에서 Pod가 수시로 CrashLoopBackOff 상태가 발생한다.
kubectl logs 명령으로는 확인되지 않고, describe pod에는 OOMKilled 표시가 있다.
Q: 이 때 취해야 할 적절한 두 가지 조치는?
(복수 정답)
① Pod의 limits.memory 값을 재조정
② HPA를 설정하여 Pod 수 증가
③ 로그 수집기를 재설정
④ Prometheus 등으로 메모리 사용량 분석
정답: ①, ④
해설:
OOMKilled는 메모리 부족 시 발생하므로 리소스 설정과 모니터링 지표 확인이 필요합니다.
✅ NO.16 (객관식 · 난이도: 중)
Pod 간 통신 제어를 위해 Kubernetes에서 사용하는 기능은?
① RBAC
② PSP
③ NetworkPolicy
④ CNI
정답: ③
해설:
NetworkPolicy는 Pod 간 트래픽을 제어해 보안을 강화합니다. CNI는 플러그인 인터페이스일 뿐 정책은 아닙니다.
✅ NO.17 (객관식 · 난이도: 상)
컨테이너 이미지의 용량을 줄이기 위한 방법으로 적절한 것은?
① Scratch 또는 Alpine 기반 이미지 사용
② 다단계 빌드(Multi-stage build) 사용
③ 불필요한 layer 제거
④ 모두 해당
정답: ④
해설:
경량 이미지, 다단계 빌드, 레이어 최적화는 모두 이미지 용량 최적화에 효과적입니다.
✅ NO.18 (시나리오 · 난이도: 상)
시나리오:
Azure ACR에 저장된 컨테이너 이미지를 AKS 클러스터에서 pull 하려 하였으나 ImagePullBackOff 오류가 발생했다.
Q: 가장 가능성 높은 원인과 조치방안은?
① 이미지가 삭제됨 → 재업로드
② ACR 권한 누락 → AKS에 pull permission 부여
③ Pod IP 충돌 → Cluster 재생성
④ 노드 디스크 부족 → 노드 수 증가
정답: ②
해설:
ACR은 프라이빗 Registry로, AKS에서 접근하려면 Managed Identity 또는 imagePullSecrets 설정이 필요합니다.
✅ NO.19 (객관식 · 난이도: 상)
다음 중 GitOps 전략의 핵심이 아닌 것은?
① 선언형 배포 방식
② Git 저장소와 클러스터 상태 동기화
③ 운영자가 수동으로 kubectl apply
④ 자동화된 Sync 및 Drift 감지
정답: ③
해설:
GitOps는 Git 저장소를 단일 진실 소스로 사용하고 자동으로 클러스터와 동기화합니다.
✅ NO.20 (시나리오 · 난이도: 상)
시나리오:
컨테이너 운영 중, 특정 애플리케이션이 외부 DB에 연결 시 DNS 해석 실패 오류가 발생하였다.
다른 애플리케이션은 정상 동작 중이다.
Q: 어떤 조치를 먼저 해야 하는가?
① CoreDNS 로그 확인 및 캐시 초기화
② DB 서버 재부팅
③ 애플리케이션 재배포
④ kube-proxy 설정 확인
정답: ①
해설:
컨테이너 DNS 문제는 CoreDNS의 캐시 문제일 수 있으며, 로그 확인 및 Pod 재시작으로 해결 가능합니다.
📌 전체 요약 정리
| 컨테이너 기초 | 경량화, OS공유 | VM과 달리 커널 공유, 빠른 실행 |
| 오케스트레이션 | Kubernetes | 자동복구, 롤링 업데이트, HPA |
| 리소스 관리 | Limits/Requests | 설정 미비 시 OOMKilled 등 발생 |
| 보안 | readOnly FS, Secret, PSP | 컨테이너 보안 설정 및 접근 제어 |
| 이미지 최적화 | Alpine, Multi-stage | 이미지 용량 축소 |
| 네트워크 | NetworkPolicy, CNI | Pod 간 통신 제어 및 격리 |
| 스토리지 | PV/PVC | 데이터 영속성 확보 |
| 배포 전략 | Blue-Green, GitOps | 무중단 배포 및 Git 기반 운영 |
| 실무장애 대응 | CrashLoop, DNS 오류 | 로그, describe, CoreDNS 분석 등 |
아래는 Container 환경의 실전 장애 대응 시나리오 기반 문제집입니다. 총 30문항, 모든 문제는 장애 상황 → 원인 분석 → 해결 방법으로 구성되어 있습니다. 실제 장애대응 경험과 Kubernetes 운영 로그 패턴을 반영했습니다.
🧠 [Container 장애 대응 시나리오 문제집 – 30문항]
난이도 구분: 상 / 중 / 하
형식: 시나리오 + 객관식 (4지선다형)
포인트: kubectl, describe, logs, CoreDNS, Volume, OOM, ImagePull, CrashLoopBackOff 등 실전 대응 키워드 다수 포함
✅ NO.01 (CrashLoopBackOff · 중)
Pod가 CrashLoopBackOff 상태를 반복 중이며, 로그엔 “Segmentation fault” 메시지만 남아 있다. 우선적으로 확인해야 할 항목은?
① 컨테이너 이미지 사이즈
② CPU 리밋 초과 여부
③ 실행 파일의 퍼미션 및 진입점 오류 여부
④ 서비스 포트 충돌 여부
정답: ③
✅ NO.02 (OOMKilled · 중)
컨테이너가 자주 OOMKilled된다. kubectl describe pod에서 memory limits는 512Mi로 설정되어 있다. 가장 먼저 할 조치는?
① Limits 제거
② HPA 설정
③ Memory usage 모니터링
④ node 재시작
정답: ③
✅ NO.03 (ImagePullBackOff · 하)
Pod 생성 시 ImagePullBackOff 상태가 계속 발생한다. 가능한 원인은?
① PVC 마운트 실패
② 레지스트리 인증 실패
③ HPA 설정 오류
④ ConfigMap 누락
정답: ②
✅ NO.04 (DNS 이슈 · 상)
Pod 내부에서 외부 도메인(Public API) 호출이 안 되고 Temporary failure in name resolution 에러가 발생한다. 가장 먼저 확인할 대상은?
① kubelet 로그
② CoreDNS Pod 상태
③ /etc/resolv.conf
④ serviceAccount
정답: ②
✅ NO.05 (로그 확인 · 중)
Pod가 실패했을 때, 단순히 kubectl logs 명령어로 아무것도 나오지 않는다. 다음으로 시도할 명령은?
① kubectl get pod -o yaml
② kubectl describe pod
③ docker inspect
④ kubectl rollout restart
정답: ②
✅ NO.06 (Volume 오류 · 중)
컨테이너가 /app/data 디렉토리에 쓰기 시도를 할 때 "Read-only file system" 에러가 발생했다. 가장 가능성 높은 원인은?
① PVC 바인딩 실패
② ConfigMap 오타
③ imagePullPolicy 설정 오류
④ node port 충돌
정답: ①
✅ NO.07 (initContainer 실패 · 중)
애플리케이션 Pod가 뜨지 않고, Init Container에서 실패했다. 문제 원인을 확인할 수 있는 명령은?
① kubectl logs <pod>
② kubectl logs <pod> -c <initContainer>
③ kubectl get svc
④ kubectl port-forward
정답: ②
✅ NO.08 (Pod 네트워크 단절 · 상)
일부 노드에서만 동작하는 Pod들이 외부 통신에 실패하고 있다. 어떤 항목을 가장 먼저 확인할 것인가?
① Ingress 설정
② Pod CIDR 충돌
③ 해당 노드의 CNI 플러그인 상태
④ CoreDNS 설정
정답: ③
✅ NO.09 (Pod Pending 상태 · 하)
Pod가 Pending 상태에서 멈춰있다. 가장 일반적인 원인은?
① 이미지 용량 초과
② 리소스 부족(Node에 CPU/Mem 할당 불가)
③ Deployment YAML 구조 오류
④ NetworkPolicy 충돌
정답: ②
✅ NO.10 (Mount 실패 · 중)
PVC가 Pod에 마운트되지 않고 오류 메시지에 Unable to attach or mount volumes가 표시된다. 가장 가능성 높은 원인은?
① RBAC 정책 미적용
② PVC의 accessMode와 Pod의 사용 방식 불일치
③ ReadinessProbe 실패
④ Secret 누락
정답: ②
🧠 [Container 장애 대응 – 키워드 암기카드]
| CrashLoopBackOff | 앱 오류, 실행 실패 → logs, describe pod 분석 |
| ImagePullBackOff | 이미지 이름 오타, private registry 인증 실패 |
| OOMKilled | 메모리 limits 초과 → describe, 메모리 조정 |
| DNS 오류 | CoreDNS 장애 or 네트워크 격리 → kubectl get pod -n kube-system |
| Read-only FS | 마운트 실패, readOnlyRootFS 설정 확인 |
| PVC Mount 실패 | accessMode 불일치, StorageClass 미존재 |
| Pending 상태 | Node 자원 부족 (CPU/MEM), PVC 바인딩 실패 |
| Init Container 실패 | 실행 순서 오류 → logs -c <initContainer> 로 확인 |
| NetworkPolicy | Pod 간 통신 차단 이슈 → 정책 해석 필수 |
| Service 불통 | ClusterIP, NodePort, Ingress 설정 확인 |
| LivenessProbe 실패 | 앱 내부 상태 비정상 → 재시작 루프 유발 |
| Volume 데이터 유실 | emptyDir, 재시작 시 초기화 주의 |
| Node 문제 | 해당 Node에서만 오류 → CNI, kubelet 상태 점검 |
| Container 로그 없음 | 앱 진입점 오류 (Entrypoint, CMD 누락) |
| CoreDNS Cache | 특정 도메인만 오류 → CoreDNS Pod 재시작 |
🧰 [장애유형별 대응 시나리오 요약표]
| CrashLoopBackOff | 반복 재시작, 로그 짧음 | logs, describe, entrypoint | 실행 파일 오류, 디펜던시 누락 확인 |
| ImagePullBackOff | 이미지 가져오기 실패 | 이미지 경로, 비공개 인증 | imagePullSecret, ACR 연결 재검토 |
| OOMKilled | Pod 강제종료 | describe pod, limits 확인 | 메모리 리밋 상향 / 코드 최적화 |
| Pending 상태 | Pod 미스케줄 | Node 리소스, PVC 상태 | Node 스케일업 / PVC StorageClass 설정 |
| PVC Mount 실패 | Pod 시작 안됨 | Volume mount logs, accessMode | RWX/ROX 모드 일치 확인 |
| ReadinessProbe 실패 | LB 연결 안됨 | Probe 응답 포맷 | 앱 로직 / 경로 확인 및 응답 조정 |
| DNS 오류 | 외부 API 통신 불가 | CoreDNS 상태, 네트워크 정책 | CoreDNS 재시작, NetworkPolicy 조정 |
| 네트워크 단절 | 특정 Pod 외부통신 불가 | CNI 상태, Node별 차이 | CNI 재설정, Pod 재배치 |
| initContainer 실패 | Main container 미실행 | logs -c <init> | 준비 작업 실패 → 컨테이너 분리 확인 |
| Service 미연결 | 클라이언트 요청 실패 | 서비스 포트, 엔드포인트 | ClusterIP/NodePort 확인 |
| Pod 간 통신 안됨 | 내부 앱 통신 실패 | NetworkPolicy | 정책 해제 또는 허용 rule 추가 |
| 컨테이너 로그 없음 | 빈 로그, 실행 안됨 | ENTRYPOINT/CMD, 이미지 내용 | 실행 명령어 누락 여부 확인 |