Kubernetes 주니어 배포·운영 기술면접
새 면접Q. Kubernetes에서 Rolling Update를 진행하던 중 새 버전의 Pod에서 에러가 발생했습니다. 자동으로 롤백이 되지 않고 계속 재시작을 반복하고 있습니다. 이런 상황을 방지하기 위해 Deployment 설정에서 어떤 필드들을 어떻게 구성해야 하나요?
Pod의 헬스체크와 업데이트 진행 조건을 제어하는 설정들을 생각해보세요.
이 상황을 방지하려면 먼저 minReadySeconds를 설정하여 Pod가 Ready 상태가 된 후 일정 시간 대기하도록 해야 합니다. progressDeadlineSeconds를 설정하여 지정된 시간 내에 업데이트가 진행되지 않으면 실패로 간주하도록 합니다. maxUnavailable과 maxSurge를 적절히 조절하여 한 번에 업데이트되는 Pod 수를 제한합니다. 가장 중요한 것은 readinessProbe를 정확히 설정하여 애플리케이션이 실제로 준비되었을 때만 트래픽을 받도록 하는 것입니다. 또한 revisionHistoryLimit을 설정하여 롤백 가능한 버전을 유지하고, 필요시 kubectl rollout undo 명령으로 즉시 이전 버전으로 복구할 수 있도록 준비해야 합니다.
- • minReadySeconds로 Pod 안정화 대기 시간 설정
- • progressDeadlineSeconds로 업데이트 타임아웃 설정
- • readinessProbe로 트래픽 유입 조건 명확히 정의
- • maxUnavailable/maxSurge로 업데이트 속도 제어
프로덕션 환경에서 새 버전 배포 시 장애를 조기에 감지하고 자동으로 배포를 중단하여 서비스 안정성을 유지합니다.
readinessProbe와 livenessProbe의 차이점과 각각을 어떤 상황에서 사용해야 하는지 설명해주세요.
Q. GitLab CI 또는 GitHub Actions를 사용하여 Kubernetes 배포 파이프라인을 구성할 때, 컨테이너 이미지 빌드부터 클러스터 배포까지의 전체 스테이지를 어떻게 구성하시겠습니까? 각 스테이지에서 수행해야 할 주요 작업을 설명해주세요.
이미지 빌드, 레지스트리 푸시, 매니페스트 업데이트, 배포 순서를 생각해보세요.
CI/CD 파이프라인은 크게 4단계로 구성합니다. 첫 번째 Build 스테이지에서는 소스코드를 체크아웃하고 Docker 이미지를 빌드하며, 이미지 태그는 커밋 해시나 빌드 번호를 사용합니다. 두 번째 Test 스테이지에서는 빌드된 이미지로 컨테이너를 실행하여 기본적인 헬스체크나 통합 테스트를 수행합니다. 세 번째 Push 스테이지에서는 테스트를 통과한 이미지를 Docker Hub나 ECR 같은 컨테이너 레지스트리에 푸시합니다. 마지막 Deploy 스테이지에서는 kubectl 또는 Helm을 사용하여 Kubernetes 클러스터에 배포하며, 이때 kubeconfig 인증 정보는 CI/CD 시크릿으로 안전하게 관리합니다. 배포 후에는 rollout status 명령으로 배포 성공 여부를 확인하고, 실패 시 파이프라인을 중단시킵니다.
- • Build-Test-Push-Deploy 4단계 스테이지 구성
- • 이미지 태그는 커밋 해시나 빌드 번호로 버전 관리
- • 레지스트리 푸시 전 테스트 스테이지로 품질 검증
- • kubeconfig는 CI/CD 시크릿으로 안전하게 관리
- • 배포 후 rollout status로 성공 여부 확인
코드 커밋 후 자동으로 빌드, 테스트, 배포가 진행되어 수동 작업 없이 안전하게 프로덕션에 반영됩니다.
개발, 스테이징, 프로덕션 환경별로 다른 설정값을 적용하려면 파이프라인을 어떻게 구성해야 하나요?
Q. Kubernetes 클러스터에 배포된 애플리케이션의 로그를 확인하고 문제를 진단하기 위해 kubectl 명령어를 어떻게 활용할 수 있나요? 실시간 로그 확인, 이전 Pod의 로그 확인, 특정 컨테이너 로그 확인 방법을 포함하여 설명해주세요.
kubectl logs 명령어의 다양한 옵션들을 생각해보세요.
기본적으로 kubectl logs 명령으로 Pod의 로그를 확인할 수 있으며, -f 옵션을 추가하면 실시간으로 로그를 스트리밍할 수 있습니다. Pod가 재시작된 경우 --previous 옵션을 사용하면 이전에 실행되었던 컨테이너의 로그를 확인할 수 있어 크래시 원인을 파악하는 데 유용합니다. 하나의 Pod에 여러 컨테이너가 있는 경우 -c 옵션으로 특정 컨테이너를 지정해야 합니다. --tail 옵션으로 최근 N개의 로그만 조회하거나, --since 옵션으로 특정 시간 이후의 로그만 필터링할 수 있습니다. Deployment나 StatefulSet의 모든 Pod 로그를 한번에 보려면 -l 옵션으로 레이블 셀렉터를 사용하면 됩니다.
- • kubectl logs -f로 실시간 로그 스트리밍
- • --previous 옵션으로 재시작 전 로그 확인
- • -c 옵션으로 멀티 컨테이너 Pod에서 특정 컨테이너 지정
- • --tail, --since로 로그 범위 제한
- • -l 옵션으로 레이블 기반 다중 Pod 로그 조회
프로덕션 환경에서 장애 발생 시 빠르게 로그를 확인하여 원인을 파악하고 대응하는 데 필수적입니다.
kubectl logs만으로는 부족한 상황에서 중앙 집중식 로깅 시스템을 구축하려면 어떤 도구들을 사용할 수 있나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!