Docker 미드레벨 기술면접
새 면접Q. Docker의 컨테이너 런타임 계층 구조에서 dockerd, containerd, runc의 역할과 관계를 설명하고, 이러한 구조로 분리된 이유와 각 컴포넌트가 담당하는 책임을 설명해주세요.
dockerd는 Docker 데몬으로 REST API를 제공하고 이미지 관리, 네트워크, 볼륨 등을 담당합니다. containerd는 컨테이너 라이프사이클 관리(생성, 실행, 중지)를 담당하는 고수준 런타임입니다. runc는 OCI 스펙을 구현한 저수준 런타임으로 실제 컨테이너 프로세스를 생성합니다. 이렇게 분리된 이유는 관심사의 분리, 표준화(OCI 준수), 그리고 다른 오케스트레이터(Kubernetes 등)가 containerd를 직접 사용할 수 있도록 하기 위함입니다.
- • dockerd는 API와 이미지/네트워크 관리 담당
- • containerd는 컨테이너 라이프사이클 관리
- • runc는 OCI 스펙 구현 및 실제 컨테이너 생성
- • 계층 분리로 표준화와 재사용성 확보
Kubernetes가 Docker 대신 containerd를 직접 사용하는 CRI(Container Runtime Interface) 방식으로 전환한 이유와 그 장점은 무엇인가요?
Q. Docker 컨테이너의 I/O 성능을 최적화하기 위한 스토리지 드라이버 선택 전략을 설명하고, overlay2, aufs, devicemapper의 차이점과 각각의 성능 특성을 비교해주세요. 또한 프로덕션 환경에서 권장되는 스토리지 드라이버와 그 이유를 설명해주세요.
overlay2는 현재 권장되는 스토리지 드라이버로 커널 4.0 이상에서 사용 가능하며, 파일 시스템 레벨에서 동작하여 빠른 읽기/쓰기 성능을 제공합니다. aufs는 오래된 드라이버로 많은 레이어에서 성능 저하가 발생합니다. devicemapper는 블록 레벨에서 동작하지만 direct-lvm 모드가 아니면 성능이 떨어집니다. 프로덕션에서는 overlay2를 권장하는데, 메모리 효율성이 좋고, 페이지 캐시를 공유하며, inode 소비가 적고, 커널에서 네이티브로 지원되어 안정적이기 때문입니다.
- • overlay2는 파일 시스템 레벨, 빠른 성능, 커널 네이티브 지원
- • devicemapper는 블록 레벨, direct-lvm 필요
- • aufs는 레거시, 많은 레이어에서 성능 저하
- • overlay2가 페이지 캐시 공유와 inode 효율성으로 프로덕션 권장
대용량 데이터를 다루는 컨테이너에서 스토리지 드라이버의 성능 문제를 우회하기 위한 볼륨 사용 전략은 무엇인가요?
Q. Docker 컨테이너 간 통신이 정상적으로 이루어지지 않을 때 수행해야 할 네트워크 진단 절차를 단계별로 설명하고, iptables 규칙, DNS 설정, 네트워크 드라이버 문제를 확인하는 구체적인 명령어와 방법을 제시해주세요.
먼저 docker network inspect로 컨테이너가 같은 네트워크에 있는지 확인합니다. docker exec로 컨테이너 내부에서 ping, curl, nslookup을 실행하여 연결성과 DNS 해석을 테스트합니다. iptables -L -n -v로 방화벽 규칙을 확인하고, DOCKER-USER 체인에 차단 규칙이 있는지 검토합니다. docker network ls와 docker inspect로 네트워크 드라이버 설정을 확인하고, 필요시 docker network create로 새 네트워크를 생성하여 테스트합니다. 마지막으로 dockerd 로그와 journalctl -u docker를 확인하여 시스템 레벨 오류를 파악합니다.
- • docker network inspect로 네트워크 연결 확인
- • 컨테이너 내부에서 ping/curl/nslookup으로 연결성 테스트
- • iptables 규칙과 DOCKER-USER 체인 검토
- • dockerd 로그로 시스템 레벨 오류 확인
호스트와 컨테이너 간 포트 포워딩이 작동하지 않을 때, NAT 규칙을 확인하고 수정하는 방법은 무엇인가요?
Q. 마이크로서비스 환경에서 사이드카 패턴을 Docker Compose로 구현할 때의 설계 원칙을 설명하고, 로깅, 모니터링, 서비스 메시 프록시 등의 사이드카 컨테이너를 메인 애플리케이션 컨테이너와 함께 배포할 때 고려해야 할 네트워크, 볼륨 공유, 라이프사이클 관리 전략을 제시해주세요.
사이드카 패턴에서는 메인 컨테이너와 사이드카 컨테이너가 동일한 네트워크 네임스페이스를 공유하도록 network_mode: service:main 또는 같은 네트워크에 배치합니다. 볼륨은 named volume이나 tmpfs를 통해 로그 파일이나 소켓 파일을 공유합니다. depends_on과 healthcheck를 활용하여 메인 컨테이너가 준비된 후 사이드카가 시작되도록 순서를 제어합니다. restart 정책을 통일하여 장애 시 함께 재시작되도록 하고, 리소스 제한을 적절히 설정하여 사이드카가 메인 애플리케이션의 리소스를 과도하게 사용하지 않도록 합니다.
- • 같은 네트워크에 배치하여 localhost 통신 가능하게 설정
- • 볼륨 공유로 로그/소켓 파일 교환
- • depends_on과 healthcheck로 시작 순서 제어
- • restart 정책과 리소스 제한 통일
Kubernetes의 Pod 개념과 Docker Compose의 사이드카 패턴 구현의 차이점과 각각의 장단점은 무엇인가요?
Q. 팀원이 작성한 Dockerfile에서 ENTRYPOINT와 CMD를 동시에 사용하는 경우를 발견했습니다. ENTRYPOINT와 CMD의 차이점, 두 명령어를 함께 사용하는 이유와 사용 패턴, 그리고 exec form과 shell form의 차이가 신호 처리(signal handling)에 미치는 영향을 설명해주세요.
ENTRYPOINT는 컨테이너가 실행될 때 항상 실행되는 기본 명령어를 정의하고, CMD는 ENTRYPOINT에 전달될 기본 인자를 정의합니다. 함께 사용하면 ENTRYPOINT는 고정하고 CMD로 기본 인자를 제공하되, 런타임에 인자를 오버라이드할 수 있습니다. exec form(JSON 배열)은 쉘 없이 직접 실행되어 PID 1로 동작하므로 SIGTERM 등의 신호를 올바르게 받을 수 있지만, shell form은 /bin/sh -c로 래핑되어 신호가 쉘에 전달되고 자식 프로세스에는 전달되지 않아 graceful shutdown이 불가능합니다. 프로덕션에서는 exec form 사용을 권장합니다.
- • ENTRYPOINT는 고정 명령어, CMD는 기본 인자 제공
- • 함께 사용 시 유연한 인자 오버라이드 가능
- • exec form은 PID 1로 직접 실행, 신호 처리 가능
- • shell form은 쉘이 래핑하여 신호 전달 불가, graceful shutdown 문제
PID 1 문제를 해결하기 위해 tini나 dumb-init 같은 init 시스템을 컨테이너에 추가하는 이유와 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!